Thursday Jan 13, 2011

List of new and up'rev'd packages in each Solaris 10 Update

Here are lists in .pdf (SPARC / x86) of new and up'rev'd packages in each Solaris 10 Update release.

As you may know from my previous blog postings, Oracle Sun recommends customers to install or upgrade to the latest Solaris 10 Update in major maintenance windows. Based on a request from customers whose change control policies prevent them from upgrading, we've been producing Solaris Update Patch Bundles which bring pre-existing packages up to the same software level as the corresponding Solaris Update.  The difference is that the Patch Bundles don't provide new or up'rev'd packages introduced in the corresponding Solaris Update.

For customers considering use of the Solaris Update Patch Bundles, that raises the obvious question as to which packages are introduced or up'rev'd in each Solaris Update release.  The lists above answer that question.

Aside: As discussed in previous blog postings, all core Solaris OS packages are updated via patches.  The up'rev'd packages above refer to some 3rd party and community based apps included in Solaris (e.g. Mozilla Firefox, Thunderbird, etc.) which are updated via package updates (i.e. where one package version is removed and replaced with a later version).  This is to tie in better with the release strategy for such apps.

Many thanks to my colleague, Roisin Doran, for all her work in putting this together.

I'll ask Roisin to work with the Technical Writers to include updated versions of these lists in future Solaris 10 Update release documentation.

Friday Oct 15, 2010

Solaris Updates and Patch Bundles in the picture

A colleague of mine, Ken Brucker, has drawn this picture showing the composition of Solaris Updates which you may find useful to visualize the process.  

See the relevant slides from the presentation on for more detailed information.

Tuesday Nov 24, 2009

Do not apply packages from one Update onto a system installed with a different Update

I'd just like to make the following clear to customers:

Customers who install packages from one Update release (e.g. S10U6) on a system installed with another release (e.g. S10U3) risk corrupting their system.

You must not install packages from one Update release onto a system installed with any other Update release.

The reason for this is that all available patches are pre-applied into all packages for each Update release.   Patches and packages have a many-to-many relationship.  That is, one patch can patch many packages.   One package can be patched by many patches.

If you install a package from an Update release onto a system installed with a different Update release, you completely compromise future patch dependency checking as you've introduced patch metadata from a later Update release.   This is likely to lead to system corruption as further patches are applied.

'patchadd' checks that dependencies are satisfied when installing a patch.  If 'patchadd' finds any installed package patched with a patch which satisfies the dependency, it assumes the patch is applied to all packages.  This is done for performance reasons.  Hence, if a package from a later release is installed on the system, it's pre-applied patches may fool subsequent 'patchadd' invocations into thinking that a hard code dependency has been satisfied for all packages on the system when this is not the case.   The patch application will be allowed to continue, potentially corrupting the system.

The converse is also true.   If a package from an earlier Update is applied to a system, the patch delta from that Update to the Update installed on the system plus any additional patches installed on the system would need to be applied to the package to avoid a mismatch in software levels between the packages on this system, which could lead to incorrect patch dependency resolution and hence to system corruption.  Since this is difficult to get right, adding packages from a different Update release onto an installed system is, in general, unsupported. 

There are two exceptions to the above rules, for Live Upgrade and encryption packages.

  • Live Upgrade: If you are upgrading from Solaris 8 or Solaris 9 to Solaris 10, you need to apply the Live Upgrade packages from the Solaris 10 system to your Solaris 8 or Solaris 9 system.  See document 1004881.1 on My Oracle Support (MOS),, for details.
  • SUNWcry\* encryption packages: These weren't included in the Solaris distribution prior to Solaris 10 8/07 (Update 4).  For pre-Update4 systems, the recommended way to get these packages is to upgrade to a later Update release.  For the reasons outlined above, while not recommended, a possible alternative is to download the packages from OTN, install them, and then re-apply any patches that patch the SUNWcry\* packages which you have already applied to the system (\*\*). Also, for the reasons outlined above, it is not recommended to apply the packages from the media of a later Update release, as you would need to ensure that all the other packages installed on the system are patched to the same or higher patch level  (e.g. by installing the appropriate Solaris Update Patch Bundle available from My Oracle Support, to avoid completely compromising future patch dependency checking on the system.

\*\* A way to check which patches need to be re-applied in this scenario is as follows:

cd /var/sadm/patch
egrep -i "PKG=SUNWcryr|PKG=SUNWcry" \*/log|cut -f1 -d /|sort -u

as in:

# cd /var/sadm/patch
# egrep -i "PKG=SUNWcryr|PKG=SUNWcry" \*/log|cut -f1 -d /|sort -u

The above example is on a system installed with Soalris 10 11/06 (Update 3).  The user would need to re-apply the patches listed above and be extremely careful to ensure they are applied in the correct dependency order as 'patchadd' will not be able to ensure the correct dependency order as it's dependency checking remains compromised until the added packages are brought up to the same patch level.

Please note that if a package from the same Update is applied to a system, then any additional patches already installed on the system that patch the added package must be re-applied to bring that package up to the same software level as the rest of the system.  This is called "incremental patching".   This is supported, but care must be taken.  The easiest way to do this is to reapply all patches installed on the system (as listed by 'patchadd -p').  This will bring the added package(s) up to the same software level as the rest of the system.  Again, you need to be extremely careful to ensure they are applied in the correct dependency order as 'patchadd' will not be able to ensure the correct dependency order as it's dependency checking remains compromised until the added packages are brought up to the same patch level as the rest of the system.

Best Wishes,

Gerry Haskins,
Director, Software Patch Services

Friday Jan 04, 2008

Solaris Patches

The following applies to core Solaris packages and patches.  It does not necessarily apply to some applications embedded in Solaris, such as StarOffice.

Each marketing release of Solaris has it's own set of patches.

That is, there's one set of patches for Solaris 8, a separate set of patches for Solaris 9, and another set of patches for Solaris 10.

But the same set of patches will apply to all update releases of a Solaris marketing release.

Taking Solaris 10 as an example, the same Solaris 10 patches will apply to the original Solaris 10 03/05 release, Solaris 10 HW1, Solaris 10 HW2, Solaris 10 1/06 (Update 1), Solaris 10 6/06 (Update 2), Solaris 10 11/06 (Update 3), and Solaris 10 8/07 (Update 4).

The package version of core Solaris packages remains unchanged throughout the supported life of a Solaris marketing release. 

For example, the package version of SUNWcsr is the same in the original Solaris 10 03/05, the latest Solaris 10 8/07 releases, and all releases in between.  Looking at the relevant entries /var/sadm/pkg/SUNWcsr/pkginfo on an installed Solaris 10 x86 system, we see:

   NAME=Core Solaris, (Root)

Effectively, there's a single customer-visible code branch for each Solaris marketing release.

This means that new code changes, including new bug fixes, are made to the tip of the source tree for each Solaris marketing release.

All changes to pre-existing packages for each Solaris marketing release, whether bug fixes, feature enhancements, or new features, must therefore be delivered as patches.

The advantage of this approach is that it allows Sun to provide long-term, high quality support for each Solaris marketing release at a reasonable cost.  It also has the advantage that customers can apply the same set of patches to all their systems to bring them to the same patch level, irrespective of which update releases of a Solaris marketing release are installed on them.

To get a new bug fix made to the tip of the source tree, implies that customers will also be getting any preceding code changes to the same area of code.

[The above is a simplification.  Within Sun, there are temporary multiple source code branches to protect the stability of the source tree from new, potentially immature, feature code.]

For example, if a bug fix is made today to, it will be on top of all preceding changes to, irrespective of whether those changes were due to other bug fixes or feature enhancements.  Therefore, the resultant patch which contains the latest bug fix will contain a mixture of bug fix and feature code.  In the current Solaris source control model, it is not possible to get one without the other.

Some features may be entirely contained in patches - e.g. ZFS.  This means that customers on early releases of Solaris 10, such as Solaris 10 03/05 can install a set of patches to get the ZFS feature.  (ZFS was first shipped as part of Solaris 10 6/06 (Update 2). Obviously, it's also contained in all subsequent Solaris 10 update releases, as update releases are cumulative.)

Other new features may also introduce new packages.  These new packages are typically only available by installing or upgrading to the appropriate Solaris Update release, e.g. Solaris 10 8/07.

All available Solaris patches are included in the next Solaris Update release.  These are pre-applied to the Solaris install image in a process called "freshbitting".  This ensures that each Solaris Update release has all the bug fixes which were available at the time the Update was built, thus increasing the quality of each successive Solaris Update release.  Pre-applying the patches into the Solaris Update release image saves customers, who have installed or upgraded to that Solaris Update release, the time and expense of applying such patches using the Solaris patchadd utility. 

Note, new patches may become available after a Solaris Update release was finalized, so customers should check for applicable critical new patches - see the appropriate Recommended Patch Cluster or Sun Alert Patch Cluster on the SunSolve "Patches and Updates" page, which are available to customers with a valid Solaris Subscription or Sun System Service Plan. Such pre-applied patches will be listed as normal by the 'patchadd -p' and 'showrev -p' commands on an installed system.  The only difference is that since such patches are pre-applied, they cannot be removed (i.e. backed out).

Also, as noted in the A Bug's Lifecycle presentation mentioned previously, each bug fix and feature is first made to the current marketing release of Solaris under development (i.e. the next Solaris marketing release after Solaris 10, codenamed "Nevada" ).  Including all bug fixes in the next Solaris marketing release ensures that each successive marketing release of Solaris is of higher quality than the last release.  Only after the code change has successfully completed testing in the next Solaris marketing release, is it permitted to be back-ported to the currently shipping Solaris marketing releases where the code change is again tested before it is released.  This process of "soak-testing" code changes in the next marketing release under development prior to allowing them to be back-ported helps protect the quality and stability of the Solaris marketing releases which are currently shipping by ensuring code changes are test prior to being putback to the source code base.  Additional, Pre-Integration Testing is also performed to ensure the code changes don't regress functionality.

Solaris 8, 9, and 10 are the currently supported Solaris marketing releases.

Only the latest marketing release, Solaris 10, will have further periodic Update releases, the last such being Solaris 10 8/07 (Update 4).  The Solaris Updates facilitate the release of cool new features such as NewBoot (GRUB), ZFS, Trusted Solaris Extensions, Secure By Default, etc.

No further Update releases are planned for Solaris 8 or Solaris 9.  These releases are now in pure sustaining mode - i.e. bug fixes and very limited enhancements only.  These older releases can be advantageous from a risk minimization perspective, as they are subject to less code change than the current release, which is taking in new features as well as bug fixes.  The downside of remaining on these older releases is that do not contain Solaris 10's cool new software features,  significant performance enhancements, and support for (quite literally) cool new hardware.

To get the latest bug fixes, customers can either apply patches, or Install or Upgrade to the latest Solaris Update release which, as mentioned previously, contains all the bug fixes which were available at the time it was built.  I'll explore later why installing or upgrading to the latest Solaris Update release can be beneficial from a risk minimization perspective, especially on Solaris 10.

For customers who are already on the latest Solaris 8 or Solaris 9 Update Release, the only way to get new bug fixes is through applying patches as no more Update Releases are planned for these marketing releases.


This blog is to inform customers about patching 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 Engineer


« July 2016