Solaris 11 SRU / Update relationship explained, and blackout period on delivery of new bug fixes eliminated

Relationship between SRUs and Update releases

As you may know, Support Repository Updates (SRUs) for Oracle Solaris 11 are released monthly and are available to customers with an appropriate support contract.  SRUs primarily deliver bug fixes.  They may also deliver low risk feature enhancements.

Solaris Updates are typically released once or twice a year, containing support for new hardware, new software feature enhancements, and all bug fixes available at the time the Update content was finalized.  They also contain a significant number of new bug fixes, for issues found internally in Oracle and complex customer bug fixes which  require significant "soak" time to ensure their efficacy prior to release.

Changes to SRU and Update Naming Conventions

We're changing the naming convention of Update releases from a date based format such as Oracle Solaris 10 8/11 to a simpler "dot" version numbering, e.g. Oracle Solaris 11.1. Oracle Solaris 11 11/11 (i.e. the initial Oracle Solaris 11 release) may be referred to as 11.0.

SRUs will simply be named as "" releases, e.g. Oracle Solaris 11.1.1, for SRU1 after Oracle Solaris 11.1.

Many Oracle products and infrastructure tools such as BugDB and MOS are tailored towards this "" style of release naming, so these name changes align Oracle Solaris with these conventions.

No Blackout Periods on Bug Fix Releases

The Oracle Solaris 11 release process has been enhanced to eliminate blackout periods on the delivery of new bug fixes to customers.

Previously, Oracle Solaris Updates were a superset of all preceding bug fix deliveries.  This made for a very simple update message - that which releases later is always a superset of that which was delivered previously.

However, it had a downside.  Once the contents of an Update release were frozen prior to release, the release of new bug fixes for customer issues was also frozen to maintain the Update's superset relationship.

Since the amount of change allowed into the final internal builds of an Update release is reduced to mitigate risk, this throttling back also impacted the release of new bug fixes to customers.

This meant that there was effectively a 6 to 9 week hiatus on the release of new bug fixes prior to the release of each Update.  That wasn't good for customers awaiting critical bug fixes.

We've eliminated this hiatus on the delivery of new bug fixes in Oracle Solaris 11 by allowing new bug fixes to continue to be released in SRUs even after the contents of the next Update release have been frozen.

The release of SRUs will remain contiguous, with the first SRU released after the Update release effectively being a superset of both the the Update release and all preceding SRUs*. 

That is, later SRUs are supersets of the content of previous SRUs.

Therefore, the progression path from the final SRUs prior to the Update release is to the first SRU after the Update release, rather than to the Update release itself.

The timeline / logical sequence of releases can be shown as follows:

Updates: 11.0                                                11.1                               11.2     etc.

                 \                                                         \                                    \

SRUs:       11.0.1, 11.0.2,...,11.0.12, 11.0.13, 11.1.1, 11.1.2,...,11.1.x, 11.2.1, etc.

For example, for systems with Oracle Solaris 11 11/11 SRU12.4 or later installed, the recommended update path is to Oracle Solaris 11.1.1 (i.e. SRU1 after Solaris 11.1) or later rather than to the Solaris 11.1 release itself.  This will ensure no bug fixes are "lost" during the update*.

If for any reason you do wish to update from SRU12.4 or later to the 11.1 release itself - for example to update a test system - the instructions to do so are in the SRU12.4 README,

For systems with Oracle Solaris 11 11/11 SRU11.4 or earlier installed, customers can update to either the 11.1 release or any 11.1 SRU as both will be supersets of their current version.  My colleague, Pete Dennis, explains the step-by-step process here.

Please do read the README of the SRU you are updating to, as it will contain important installation instructions which will save you time and effort.

*Nerdy details:

  • SRUs only contain the latest change delta relative to the Update on which they are based.  Their dependencies will, however, effectively pull in the Update content.  Customers maintaining a local Repo (e.g. behind their firewall), need to add both the 11.1 content and the relevant SRU content to their Repo, to enable the SRU's dependencies to be resolved.  Both will be available from the standard Support Repo and from MOS.  This is no different to existing SRUs for Oracle Solaris 11.0, whereby you may often get away with using just the SRU content to update, but the original 11.0 content may be needed in the Repo to resolve dependencies.
  • The following bug fixes in SRU12.4 are not in Oracle Solaris 11.1.  They'll be available in 11.1.1 (SRU1 for Oracle Solaris 11.1):
7166132 vim should be able to run its test suite
7190213 libibmad and associated files need to be delivered in an NGZ
7191495 mkisofs install is incomplete
7195687 Update fetchmail to version 6.3.22
7195704 Problem with utility/fetchmail
7196234 Problem with network/dns
7197223 vim shows high CPU usage when editing dtrace script with syntax
        highlighting enabled
7071362 tcp_icmp_source_quench and other tunables may no longer be field
7181137 sol_umad should allow userland MAD operations in NGZs
7196540 After 7174929 integration 0.9.0 is shown for first disk in
        secondRAID volume

Hello Gerry,

I noticed the SRU ISO images are getting bigger every month.

On a new local Solaris 11.1 IPS repo, do I have to apply all the SRU images to consider the repo to be up to date or can I just apply the latest ISO image and get all the bug fixes available since the first SRU for the OS release?

Thank you,

Posted by Leandro on March 25, 2014 at 09:14 AM PDT #

Hi Leandro,

SRUs are cumulative with respect to their base release (for example Solaris 11.1).

However, it is best practice to include all SRUs up to the level you want in your Repo. This is because the IPS Solver occasionally may need metadata contained in an intermediate SRU in order to resolve dependencies. For example, how to handle an IDR.

If you ever get 1,000s of lines of IPS "cannot resolve dependencies" type messages, it's typically because of missing intermediate SRUs in your Repo.

Therefore, best practice is to maintain a fully populated Repo rather than a sparsely populated one.

Best Wishes,


Posted by Gerry on April 17, 2014 at 06:19 AM PDT #

I've had a variety of issues if I have an image of a zone and I am installing it on a system that does not have the repository with the intermediate SRUs on it. It comes up will all sorts of errors. While the packages may be there, they don't seem to keep track of all the incorporations, so if you skip SRUs, you may be missing certain incorporation levels.

So if you have independent system that need to be kept in sync, you have to apply all the same SRUs in all locations. This makes things a pain because you would think you can build a repository from the base, then the lastest SRU. Nope, think again. There is nothing more fun than putting DVDs in all day long and updating your repository with redundant files just to get a specific incorporate (I'm looking at you oracle-rdbms-server-12-1-preinstall).

On 11.2 here.


Posted by Peter on June 16, 2015 at 03:16 PM PDT #

Hi Peter,

While you can often get away with having an incomplete repository when updating from one SRU to another, you are correct that having the intermediate Updates and SRUs in the Repo is necessary in certain circumstances to enable IPS to correctly calculate the required object updates.

For example, the target system needs to have access to a repository which contains the SRU incorporations (and associated packages) which match the level of that system. Without this, as you have correctly stated, you will not be able to update the incoming zone to match the level of the required system.

If you find this a PITA for Zone migration, you may wish to consider using Kernel Zones which may eliminate the need to update the target system, although there are restrictions as explained on

Best Wishes,


Posted by Gerry Haskins on June 18, 2015 at 06:47 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

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


« October 2016