Friday Oct 04, 2013

Top Tip: Managing Solaris 11 IDRs

Here's a Top Tip from my colleague, IPS Guru, and all-round good guy, Pete Dennis:

Background

If the issue(s) addressed by a Solaris 11 IDR (Interim Diagnostics / Relief) are fixed in a subsequent SRU (Support Repository Update), the SRU is said to "supersede" the IDR. 

As mentioned in previous posts, in Solaris 11 the IDR is automatically superseded when the system is updated to the relevant SRU (or any later SRU).  That is, unlike in Solaris 10, there's no need to manually remove the IDR before updating*.  We provide "terminal packages" for superseded IDRs in the Support Repo, enabling IPS (Image Packaging System) to automatically handle the IDRs for you.

Several weeks before a planned maintenance update, it's a good idea to check whether all the IDRs in use are superseded by the SRU to which you are planning to update.

If any of them aren't superseded, and the relevant packages they touch are updated in the SRU, you'll need to raise an SR (Service Request) with Oracle Support to get new IDRs generated for the relevant BugIDs at that SRU level.  So please ensure you provide enough time for these to be generated.  Note, if the Bugs are already fixed in a later SRU, you'll be told to update to that SRU.

Question:

Is there a simple way for a customer to find out which of their IDRs will be superseded by updating to a given SRU ?

Answer:

All superseded IDRs are tagged in the Support Repository and on the incremental ISO images available from MOS (My Oracle Support).

The following command will list the superseded IDRs in the Support Repository, so you can then examine the ones of interest. 

I'm assuming here that you're maintaining a local Repo behind your firewall which is, at a minimum, up to date with the SRU to which you are planning to update:

pkg list -g http://<url of local repo> -af idr* 

For example:

pkg contents -g http://<url of local repo> -m idr679

set name=pkg.fmri value=pkg://solaris/idr679@3,5.11:20130905T193900Z
set name=pkg.description value="Terminal package"
set name=pkg.renamed value=true
depend fmri=pkg:/consolidation/osnet/osnet-incorporation@0.5.11,5.11-0.175.1.11.0.4.2 type=require

You do need to be able to interpret FMRI strings correctly (see previous posts). For example, 5.11-0.175.1.11.0.4.2 is Solaris 11.1 SRU 11.4 or, to give it its official Marketing name, Solaris 11.1.11.4.0.

So that tells us that idr679 is superseded by Solaris 11.1 SRU 11.4 (Solaris 11.1.11.4.0).

We'll look to make this more transparent by adding a text field with the human readable translation of the FMRI string to the metadata.

If you wish to restrict updates to selected SRUs which you have "qualified" in your environment, for example, a "Golden Image", Bart's blog posting may also be of interest.

Best Wishes,

Gerry.

* There's more work required to make this happen seamlessly in Solaris 11 Zones.

Friday Apr 12, 2013

Solaris 11 SRU naming convention change

We're tweaking the naming convention used by Oracle Solaris SRUs (Support Repository Updates) to use a 5-digit taxonomy.

For example, Oracle Solaris 11.1.6.4.0

The digits represent Release.Update.SRU.Build.Respin

For the above example, the old name would have been Oracle Solaris 11.1 SRU 6.4. 

As with Oracle Solaris 10 and below, all bug fixes are putback to the tip of the source tree for Solaris 11, which is currently Solaris 11.1.x.y.z. 

Therefore, these same SRUs are also the way to get fixes for systems installed with Oracle Solaris 11 11/11, in exactly the same way that Solaris 10 Kernel patches included code from all preceding Solaris 10 Updates.

As discussed in previously postings, systems should be updated to a later SRU, for example from Oracle Solaris 11 11/11 SRU13.4  to Oracle Solaris 11.1.6.4.0.

If you maintain a local Solaris Repository behind your firewall, both Solaris 11.1 and whichever subsequent SRUs you are interested in should be added to your Repo.  This is because SRUs only contain the change delta relative to the preceding Solaris Update.

Solaris's long standing Binary Compatibility Guarantee coupled with the technical benefits of Image Packaging System (IPS) help to ensure a smooth update experience.

About

This blog is to inform customers about Solaris 11 maintenance best practice, feature enhancements, and key issues. The views expressed on this blog are my own and do not necessarily reflect the views of Oracle. The Documents contained within this site may include statements about Oracle's product development plans. Many factors can materially affect these plans and the nature and timing of future product releases. Accordingly, this Information is provided to you solely for information only, is not a commitment to deliver any material code, or functionality, and SHOULD NOT BE RELIED UPON IN MAKING PURCHASING DECISIONS. The development, release, and timing of any features or functionality described remains at the sole discretion of Oracle. THIS INFORMATION MAY NOT BE INCORPORATED INTO ANY CONTRACTUAL AGREEMENT WITH ORACLE OR ITS SUBSIDIARIES OR AFFILIATES. ORACLE SPECIFICALLY DISCLAIMS ANY LIABILITY WITH RESPECT TO THIS INFORMATION. Gerry Haskins, Director, Software Lifecycle Engineering

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today