Patch Corner: Patch news and best practice

I'm delighted to announce the availability of 10 new free online patch training modules.

This is the result of a lot of work from those nice people in Sun Learning Services, the Install Revenue Product Engineering (RPE, a.k.a. Sustaining) team, and my own folk.

The modules concentrate on using Live Upgrade for patching, as well as providing background on Deferred Activation Patching, Kernel patches, and other useful information.

You can access the modules as follows:

• Direct link to the course: Book 3-10: Solaris Patching Best Practices: https://learning.sun.com/solc/tblocontainer/1179270477

• MyLearning: https://learning.sun.com/display/Courses/WS-2700-S10+Solaris+10+Patching+Best+Practices
  

• Link to the Sun Online Learning Center (SOLC): https://learning.sun.com/solc/smartstart

I think even experienced Sys Admins will find the modules useful in clarifying patching best practices and providing context and background information on the evolution of patching technology and best practices in Solaris 10.

If you don't like the online course format, or if you want a reference document to refer back to after taking the course, please see the attached .pdf.

Enjoy!

Best Wishes,

Gerry Haskins,

Director, Software Patch Services

I'm delighted to announce that the Solaris 10 10/09 (Update 8) Patch Bundle is now available for download by customers with a Solaris support contract.

Each Solaris Update Patch Bundle contains the equivalent set of patches which are pre-applied into the corresponding Solaris Update release image.

It is provided to enable customers who cannot upgrade for whatever reason to be able to patch systems up to the same patch level as the Update release.

Each Solaris Update is intensely tested as a unit by myriad QA teams across Sun.  Therefore, Solaris Updates and their corresponding Solaris Update Patch Bundles provide good quality "baselines" on which customers can standardize their deployments.

Standardizing deployments on such "baselines" also provides customers with a "safety in numbers" effect, as any pervasive issues are likely to be found and fixed quickly, so each customer benefits from the experience of others.

The Solaris Update Patch Bundle brings all existing packages up to the same software level as the Update release.   Any features which are entirely contained in pre-existing packages, such as Zones and ZFS functionality, are entirely available in patches and hence applying the Solaris Update Patch Bundle brings them up to the same functional level as the Update release.

However, installing the Patch Bundle is not completely equivalent to upgrading to the corresponding Solaris Update as the Patch Bundles do not include any new packages introduced in the Solaris Update release image.  Therefore, any new features which are dependent upon new packages will not be available by applying the Solaris Update Patch Bundle.

Here's a summary of the new packages in Solaris 10 10/09 (Update 8) which are not available in the Solaris 10 10/09 Patch Bundle:

SUNWhxge: SUN 10Gb hxge Ethernet Network Adapter Driver
SUNWio-tools: Administrative tools to modify the pci/pcie fabric
SUNWmrsas: LSI MegaRAID SAS2.0 HBA driver
SUNWpixman: Pixman Library
SUNWntp4r: NTPv4 (root)
SUNWntp4u: NTPv4 (usr)
SUNWntp4S: NTPv4 (source)
SUNWmptsas: LSI MPT SAS2.0 HBA driver

Please remember to apply the latest Sun Alert Cluster on top of the Solaris Update Patch Bundle in order to get all Solaris OS security, data corruption, and system availability fixes released since the final build of the Update release.

Please see previous blog entries for further details on Solaris Update Patch Bundles.

Top Tip: If you are installing in a zones environment, make sure you have the latest patch utility patches installed and Zones Parallel Patching configured before you apply a Solaris Update Patch Bundle as Zones Parallel Patching will improve non-global zone patching performance by ~300%.   See this blog entry for details.

BTW: There is no need to take any action to enable "Turbo-Charging SVR4 Package Installation" as the necessary patches are installed early on when installing the Solaris 10 10/09 Patch Bundle and will be automatically enabled for subsequent patch application when the bundle is applied to the live boot environment.  While "Turbo-Charging" has little affect when installing most patches, it does significantly speed up the application of a small number of older patches with non-optimized deletes file processing install scripts and so does speed up the Solaris 10 10/09 Patch Bundle installation somewhat.

Best Wishes,

Gerry.

I'm delighted to announce the release of the 2nd phase of our PatchFinder tool enhancements, which include:

• The ability to see the "Entitlement Classes" of patches and get information on the support contracts necessary to access and use them.  

• A "Patch Basket", into which you can add selected patches from multiple search results.

• When you click on the "Go To Patch Basket" link, the patch dependencies for all the patches you have in your Patch Basket will be dynamically resolved, including filtering out redundant dependencies.   This saves you having to manually transfer patch dependency trees!   If you already have some of these installed, you can de-select them.
  

• You can then click the "Download Selected" button to download a 'wget' script and instructions which you can use to download all of the selected patches from SunSolve.   Once you make sure you install the latest version of the patch utilities patch first, you can then use "patchadd -M" to install all the patches in the correct order on your target system.
  

Sample Searches

Let's assume you applied the Solaris 10 SPARC Recommended Patch Cluster on August 15th 2009.  So what Solaris 10 SPARC Recommended Cluster patches have been released since then ?   To find out, for "OS Release" select "Solaris 10", for "Architecture" select SPARC", select "Recommended Only", and select August 15th 2009 from the calendar beside the "Released After" box.   (Select view 50, 100, or 200 to see the entire list in one page.)   You can then decide if you want to download some of all of these patches to add to your system.  Coupled with the dynamic dependency resolution and 'wget' download capability, this effectively enables you to create customized patch clusters for yourself with just the patches you need, rather than having to download the entire Recommended Cluster each time.

Or you could bookmark a search to show you all the patches released in the last day: Simply enter the number "1" into the "Released After" box and select any other selection criteria you are interested in and click "Search".  Depending on timezone differences with respect to California and your local time of day, you may need to enter the number "2" in the "Released After" box.

You can also use PatchFinder to see what Solaris 8 Vintage patches Sun has released since Solaris 8 entered End-Of-Service-Life (EOSL) Phase 2 on April 1, 2009.   Simply select "Solaris 8" for "OS Release", select "OS Patches Only" and click "Search".  Since the patches are listed in date order, most of the patches with a release date after April 1, 2009, including patches delivering security fixes, will have the "Solaris8VintageSoftwareUpdate" Entitlement Class associated with them if you mouse-over the red padlock symbol shown for them (assuming you don't have a Solaris 8 Vintage Patch Service Plan associated with your Sun Online Account).   You will see a couple of non-Vintage patches released after April 1, 2009.  This is a transition phase and these patches address issues escalated by customers prior to April 1, 2009.

Some other sample searches to satisfy your curiosity:

Ever wondered how many patches Sun has ever released ?   To find out, simply select "Show Obsolete" and then click "Search".

How many current "active" patches does Sun have ?   De-select "Show Obsolete" and then click "Search".

How many patches can be installed on Solaris 10, including application product patches ?   For "OS Release" select "Solaris 10" (and optionally "Show Obsolete" ) and then click "Search".

How many current "active" Solaris 10 OS patches there are for SPARC ?  For "OS Release" select "Solaris 10", for "Architecture" select "SPARC" and then select "OS Patches Only" and then click "Search".

Patch Access Entitlement Classes

When you look at the list of patches returned from a search, the letter-P-in-a-circle symbol shows which patches are "Public" and can be accessed and used without a support contract.  A green open padlock symbol shows the patches you have access to thanks to the support contracts which you currently have associated with your Sun Online Account (SOA).  A red closed padlock shows the patches which you are not currently entitled to access or use with the support contracts you currently have associated with your Sun Online Aaccout.  

You can mouse-over these symbols for any patch and it will show you the "Entitlement Classes" associated with the patch. 

Read the "What is it?" help link and the SunSolve "How Entitlement Works" wiki to find out about the support contracts which you need to buy in order to access and use these patches.

Feedback

I hope you'll find the new PatchFinder enhancements useful.

We are really interested in your feedback as to what further enhancements you would like to see, so feel free to post your comments here or else use the feedback link on the PatchFinder page.

Many thanks to Brian Kidney and Julien Colomb for all their work on this - nice work guys!

I've updated the Solaris 10 Kernel PatchID sequence table in http://blogs.sun.com/patch/entry/solaris_10_kernel_patchid_progression with the latest Kernel PatchIDs for Solaris 10 10/09 (Update 8) and Solaris 10 Update 9.

The new Patching Pre-flight Checks ('ppc') tool is now available to all customers who have a support contract.

The idea for this tool comes directly from customer feedback.  

The customer wanted to reduce the cost of patching Solaris systems by enabling more junior Sys Admins to successfully patch Solaris 10 zones systems.   Their concern was that potential zones patching issues in versions of Solaris prior to Solaris 10 8/07 (Update 4) meant that they needed to assign senior System Administrators to patch such systems to identify and resolve potential issues.  

Furthermore, the customer was concerned that such issues had the potential to derail planned maintenance windows - for example, if during the patching session an unexpected issue was encountered and the patching session couldn't be completed as planned.

To address these concerns, my colleague, Ronan O'Connor, has written the Patching Pre-flight Checks tool, 'ppc'.  It can be run prior to a planned patching session to check that the target system is in a clean state ready for patching.

It's important to understand the scope of the tool.  It checks a target system (and a patch set, if supplied) for a variety of inconsistencies which could cause problems.

It looks for left over lock files from previously aborted patching or packaging operations, inconsistencies in the contents database, IDRs installed on the target system, zones "mountability", space issues, etc.  Some of these issues can occur on early versions of Solaris 10, particularly in a Zones environment.  Many of the underlying causes of such issues are fixed in the latest versions of the patch utility patches (119254 SPARC / 119255 x86), which is why we always recommend you apply the latest patch utility patches before applying other patches.

If you have a directory of patches to be applied, 'ppc' checks the integrity of those patches, and cross-checks whether any of the patches patch pkgs which have been locked down by any IDRs on the system and warns if there is a conflict.

The 'ppc' Release Notes provide information to help interpret the messages produced.

The idea is that 'ppc' can be run by a junior Sys Admin prior to a planned patching session, and any potential issues uncovered can then be analyzed by a more experienced Sys Admin.  This helps avoid nasty surprises during patches sessions and also helps to reduce the level of expertise required to patch Solaris systems, leading to cost savings for customers.

It is outside the scope of the 'ppc' tool to do root cause analysis of why the inconsistency arose or what actions may be needed, if any, to correct the situation.

If 'ppc' returns without noting any problems, you can be pretty confident that the patching session will succeed.  If 'ppc' notes potential issues, they can be investigated prior to the planned maintenance window.

The next version of 'ppc' will include a Zones consistency check to check that all zones are at a consistent patch level.   It will also contain a more sophisticated space checking algorithm.  There's no planned release date yet for Version "2.0" yet as we're awaiting feedback on Version 1.0.x first.

Some of the ideas in 'ppc' may find their way back into 'patchadd', although it's probably appropriate to keep 'ppc' as a separate tool.

To download the Patching Pre-flight Checks tool, 'ppc', go to the 'ppc' thread on the Customer Patch Forum.  If you have not accessed the Customer Patch Forum before, please see my blog entry on the initial "secret-handshake" login. 

The Patching Pre-flight Checks tool, 'ppc', and the Customer Patch Forum are only available to customers with a support contract.

We're very interested in your feedback as to the usefulness of this tool and how you'd like to see 'ppc' develop going forward.

Many thanks to Ronan O'Connor for all his work on the tool!

Best Wishes,

Gerry Haskins
Director, Software Patch Services

I am delighted to announce that Casper Dik's "Turbo-Charging SVR4 Package Install" feature enhancement is now available by downloading and installing the following patches:

119254-70 (SPARC) / 119255-70 (x86): Patch utilites patch
121428-13 (SPARC) / 121429-13 (x86): Live Upgrade Zones Support Patch
121430-40 (SPARC) / 121431-41 (x86): Live Upgrade Patch
124630-28 (SPARC) / 124631-29 (x86): System Administration Applications, Network, and Core Libraries Patch

It is important to apply 119254-70 (SPARC) / 119255-70 (x86) and 121428-13 (SPARC) / 121428-13 (x86) if the system is running non-global zones.  Otherwise booting newly installed zones will fail until the pkgserv daemon exits, about 5 minutes after zoneadm install finished.  Zones which were already installed can be booted as expected.

"Turbo Packaging" is designed to dramatically improve the performance of install, upgrade, Live Upgrade, and zone creation on Solaris 10.  It delivers only a small improvement for patching performance.   (See my Zones Parallel Patching blog entry for information on dramatic patching performance improvements.)

For background reading on the "Turbo Packaging" feature, please see
http://www.opensolaris.org/jive/thread.jspa?messageID=358081 and http://arc.opensolaris.org/caselog/PSARC/2009/173/. 

The "Turbo-charging SVR4 Package Install" feature will also be included in the forthcoming Solaris 10 Update 8 release and will be documented in the Release Notes for that release.

Great work, Casper - well done!

My colleague, Ed Clark, has made significant improvements to the Solaris 10 Recommended and Sun Alert patch clusters.  These improvements have just been released and are in the current clusters available to contract customers from the Patch Cluster & Patch Bundle Downloads on SunSolve.

Ed's improvements include:

• Filtering out "false negatives" from the patch utility return codes, so that if the cluster install script returns "1", you know you've got a real problem which needs investigating.   As you may know, the Solaris patch utility, 'patchadd', can return errors for some acceptable situations - for example, if the patch is already applied to the system, or a later revision of the patch or a patch which obsoletes it is already applied to the system, or none of the packages in the patch are on the target system (e.g. because a reduced Install Metacluster was used to install it or the system has been security hardened by package removal), etc.   Such conditions are acceptable "errors" which do not usually require further investigation by the user.  By filtering these conditions out, if the 'installcluster' script returns "1", you know it isn't because of one of these acceptable "errors", and therefore you need to look at the logfiles to find out what's gone wrong.  For further information, please see the cluster README and Analyzing a patchadd or patchrm Failure in the Solaris OS.

• The new 'installcluster' script will exit as soon as it encounters an unexpected failure - i.e. not one of the acceptable "errors" mentioned above.  This prevents potentially compounding issues by attempting to apply further patches.
  

• The new 'installcluster' script includes context intelligence for patching operations.   It informs the user when zones need to be halted, and it provides phased installation to handle patches which absolutely require an immediate reboot before further patches can be applied.  Such interim reboots are only needed when patching a live boot environment on a system below Kernel patch 118833-36 (SPARC) / 118855-36 (x86) and well as the earlier interim reboot required on x86 related to 'libc.so' patches and Kernel patch 118844-14.  On systems below these patch levels, the 'installcluster' will stop at the appropriate point when patching the live boot environment, and inform the user to reboot and re-invoke the 'installcluster' script.  (In the old cluster install script, it simply tried to carry on blindly past such interim reboots, spewing out error messages, although code in the relevant patches prevented any harm from being done).  These interim reboots, when required, are dealt with relatively early in the cluster install sequence so that once completed, the Sys Admin can leave the rest of the installation to finish unattended and move onto other systems.

• The new 'installcluster' script provides better integration with Solaris Live Upgrade as the user can now specify the Live Upgrade alternate boot environment to patch by name.

• The new 'installcluster' script performs space checking prior to installing each patch, and will halt if it believes there is insufficient space to complete the installation successfully.  For example, this helps avoid non-global zones getting out of sync regarding patch levels with respect to the global zone.  This is an important enhancement as running out of space during patching can potentially leave the system in an inconsistent state and is to be avoided.  Even removing a patch requires space, so immediate removal of a patch which has failed to apply correctly due to space issues should be avoided until sufficient space is freed up and potential issues caused by its partial installation investigated - for example, was the undo.Z file successfully created to enable backout ? (Tip: It may be better to retry the patch installation once space has been freed up rather than patch removal in such circumstances.  Contact Sun Support for instructions if you encounter such issues.).   The space checking enhancements in the 'installcluster' script are designed to prevent such problems occurring.
  

• The messages and log files produced by the 'installcluster' script are clear and well structured.  For example, a "failed" log is created if a patch fails to apply.  See the Cluster README for further information.
  

• The 'patch_order' places patches in an optimal order for installation to avoid known issues - for example, the patch utilities patches are installed as early in the sequence as possible to avoid hitting patch installation bugs which are fixed in the patch utility patches, and the Kernel patch procedural script override patch, 125555 (SPARC) / 125556 (x86), is ordered prior to 137137-09 (SPARC) / 137138-09 (x86) to resolve some known issues.  When patching an alternate boot environment (which is recommended), a small sub-set of pre-requisite patches, primarily the patch utility patches, need to be applied to the live boot environment to ensure correct patching operation.  The 'installcluster' script will check for these pre-requisite patches are halt installation if they are not present, advising the user of the 'installcluster' script option to use to install these pre-requisite patches.   Further patches may need to be installed on the live boot environment to support Live Upgrade.  See the cluster README for further information.
  

• The patches have been moved to a 'patches' sub-directory, to de-clutter the top level directory of the unzipped cluster.
  

• Please see the cluster README file for further information.  Customers should read the cluster README file and look at the Special Install Instructions in the patches within the cluster prior to installation.
  

I really want to thank Ed Clark for the enormous amount of thought and effort he has put into improving the cluster installation experience.   The work he's done on the Solaris 10 Recommended and Sun Alert patch cluster is a continuation of his previous work on the Solaris Update Patch Bundles and the Solaris 10 Live Upgrade Zones Starter Patch Bundle.  Nice work, Ed!

While the 'installcluster' script is copyrighted, I am happy for customers to use it, and the 'patch_order' file, as a starting point for their own customized patch bundles, so long as it is for their own use and is not to be given to a 3rd party or used for commercial gain (e.g. by a 3rd party maintainer or 3rd party commercial automation tool).

We have also made significant improvements to the back end processes to ensure higher and more consistent cluster quality. 

Originally, the clusters were created by the Patch Operations and Distribution (POD) team after patch release.  The POD Cluster QA process left a lot to be desired, resulting in inconsistent cluster quality.   To plug this gap, my Patch System Test team have been testing the clusters for several years, but the old process only allowed us to test them in parallel with their release, which meant that we found issues at the same time that early downloaders of the cluster encountered them.  Although we ensured such issues were fixed as quickly as possible, it still obviously compromised our customers' experience.

In the new process, the clusters are routed to Patch System Test (PST) prior to release.  PST run a transformation script on them to optimize the patch installation order, etc.  The clusters will only be released once they have passed PST testing.  This should ensure higher and more consistent quality for customers.  Work is continuing to move the entire patch cluster generation process to PST, although these future backend enhancements in this regard should be invisible to customers.

Sun Learning Services are in the process of creating a number of patch related training lessons.

They've launched a blog, which contains the initial introductory videos.

Future lessons will be much more detailed, concentrating for example on Live Upgrade.   These lessons will be available on the Sun Open Learning Center (SOLC) website: https://learning.sun.com/solc/smartstart.

I'd like to give you a heads-up on a couple of Kernel patch installation issues:

1. There was a bug (since fixed) in the Deferred Activation Patching functionality in a ZFS Root environment on x86 only.  See Sun Alert 263928.  An error message to the effect that a Class Action Script has failed to complete and failure to set up environment for Deferred Activation Patching may be seen.   The relevant CR is 6850329: "KU 139556-08 fails to apply on x86 systems that have ZFS root filesystems and corrupts the OS".    SPARC systems are similarly affected.  The following error message is returned:

mv: cannot rename /var/run/.patchSafeMode/root/lib/libc.so.1.20102 to /lib/libc.so.1: Device busy
ERROR: Move of /var/run/.patchSafeMode/root/lib/libc.so.1.20102 to dstActual failed
usage: puttext [-r rmarg] [-l lmarg] string
pkgadd: ERROR: class action script did not complete successfully

Installation of <SUNWcslr> failed.

This issue is fixed in patch in the Patch Utilities patch 119255-70 or later revision.

BTW: The principal reason ZFS Root support was implemented in Live Upgrade is so that patch application like this to the live boot environment would not be necessary.   With ZFS Root, creating a clone Boot Environment is so easy that there's no good reason not to.   This avoids the need to use technologies such as Deferred Activation Patching which attempt to make it safer to apply arbitrary change to a live boot environment, which is an inherently risky process.

2. There are reproducible issues using jumpstart finish scripts and other scenarios to install Kernel patch 137137-09 followed by Kernel patch 139555-08.   Here's the gist of the issue which I've pulled from an engineering email thread on the subject:

Issue 1: I have a customer whose system is not booting after applying the patch cluster with Live Upgrade (LU).

Solution 1: If using 'luupgrade -t', then you must ensure that latest version of LU patch is installed first, currently 121430-36 is currently the latest revision on SPARC, 121431-37 on x86. Once these patches are installed, LU will automatically handle the build of the boot archive when 'luactivate' is called, thus avoiding the problem.

Issue 2: There are other ways to get oneself into situations where a boot archive is out of sync: e.g. If using jumpstart finish scripts to apply patches that include 137137-09.  Basically any operation that involves patching to an ABE outside of 'luupgrade' will involve a manual build of boot-archive.

Solution 2: One must manually rebuild the boot-archive on the /a partition after applying the patches.  Otherwise once the system boots, the boot-archive will be out of sync.

Here's some more detail on the jumpstart finish script version of this: 

We've seen the same panic a few times when the latest patch cluster is applied via a finish script to a boot environment prior to  s10u6 via a jumpstart installation. It appears that the boot archive is out of sync with the kernel on the system. The boot archive was created from the 137137-09 patch and not updated after the 139555-08 kernel was applied, therefore the mismatch between the kernel and the boot archive.

In these instances updating the boot archive allows the system to boot successfully. Boot failsafe (ok boot -F failsafe) will detect an out of sync boot archive.  Execute the automated update then reboot.  This will now boot from the later kernel (139555-08) which successfully installed from the finish script.

I reproduced the problem in a jumpstart installation environment applying the latest 10_Recommended patch cluster from a finish script. The initial installation was S10U5 which is deployed from a miniroot that has no knowledge of a boot archive (my theory anyway).  This is similar to a live upgrade environment if the boot environment doing the patching is also boot archive unaware (meaning the kernel is pre 137137-09).

In the jumpstart scenario the immediate problem was solved by updating the boot archive by booting failsafe as previously described.  The Solution was to update the boot archive from the finish script after the patch cluster installation completed.  BTW, all patches in the patch cluster installed successfully per the /var/sadm/system/logs.finish.log.

In a standard jumpstart the boot device (install target) is mounted to /a, therefore adding the following entry to the finish script solved the problem:

/a/boot/solaris/bin/create_ramdisk -R /a

Depending on the finish script configuration, and variables the following would also work:

$ROOTDIR/boot/solaris/bin/create_ramdisk -R $ROOTDIR

Issue 3: This above issues are sometimes mis-diagnosed as CR 6850202: "bootadm fails to build bootarchive in certain configurations leading to unbootable system".

But CR 6850202 will only be encountered in very specific circumstances, all of which must occur in order to hit this specific bug, namely:

1. Install u6 SUNWCreq - there's  no mkisofs so we build ufs boot archive

2. Limit /tmp to 512M - thus forcing the ufs build to happen in /var/run

3. Have a separate /var - bootadm.c only lofs nosub mounts "/" when creating the alt root for DAP patching build of boot archive

4. Install 139555-08

You must have all 4 of above in order to hit this, i.e. step 4 must be installing a DAP patch such as a Kernel patch associated with a Solaris 10 Update such as 139555-08. 

Solution 3: Removing the 512MB limit (or whatever limit has been imposed) to /tmp in /etc/vfstab and/or adding SUNWmkcd (and probably SUNWmkcdS) so that mkisofs is available on the system is sufficient to avoid the code path that fails this way.

Booting failsafe and recreating the boot archive will successfully recreate the boot archive.

Here's further input from one of my senior engineers, Enda O'Connor:

If using Live Upgrade (LU), and LU on the live partition is up to date in terms of latest revision of the LU patch, 121430 (SPARC) and 121431 (x86), the boot-archive will be built automatically once users runs shutdown ( after luactivate to activate the new BE ).  This is done from a kill script in rcd.0.

If using a jumpstart finish script, or jumpstart profile to patch a pre-U6 image with latest kernel patches, then you need to run create_ramdisk from the finish script after all patching/packaging operations have been finished.  Alternatively, you can patch your pre-U6 miniroot to the U6 SPARC NewBoot level (137137-09), at which point the modified miniroot will handle the build of the boot_archive after the finish script has run.

If patching U6 and upwards from jumpstart, the boot_archive will get built automatically after finish script has run, so there's no issue in this scenario.

If using any home grown technology to patch or install/modify software on an Alternate Boot Environment ( ABE ), such as ufsrestore/cpio/tar for example, you must always run create_ramdisk manually before booting to said ABE.

Best Wishes,

Gerry.

The Zones Parallel Patching enhancement for the Solaris 10 patch utilities was released this week giving customers a choice of how to improve zones patching performance.

In the Zones "Update On Attach" section of a previous blog posting, I mentioned that the Zones "Update On Attach" feature could also be used to improve Zones patching perfomance.

Zones Parallel Patching is a true patching solution utilizing the 'patchadd' utility.  

Whereas Zones "Update On Attach" uses zones functionality similar to that used during zones creation to provide a pseudo-patching solution that does not utilize 'patchadd'. 

So which one to choose ?

Let's look at the two options in more detail:

Zones Parallel Patching

Zones Parallel Patching is an enhancement to the standard Solaris 10 patch utilities and is delivered in the patch utilities patch, 119254-66 (SPARC) and 119255-66 (x86).

Simply install this patch, set the maximum number of non-global zones to be patched in parallel in the config file /etc/patch/pdo.conf, and away you go.

It works for all Solaris 10 systems. 

It also works well in conjunction with higher level patch automation tools such as xVM Ops Center. 

It can dramatically improve zones patching performance by patching non-global zones in parallel.  The global zone is still patched first.

While the performance gain is dependent on a number of factors, including the number of non-global zones, the number of on-line CPUs, the speed of the system, the I/O configuration of the system, etc., a performance gain of ca. 300% can typically be expected for patching the non-global zones - e.g. On a T2000 with 5 sparse root non-global zones.

See my previous Zones Parallel Patching blog entry for further information.

Since it's a pure enhancement to 'patchadd', it's normal 'patchadd' functionality.  You can subsequently remove patches using 'patchrm', etc.  Nothing has changed except that it's now much faster to patch non global Zones with Zones Parallel Patching invoked.

Zones "Update On Attach"

The primary purpose of Zones "Update on Attach" is Zones migration from one server to another.  

For example, a database instance in a non-global zone hosted on a server has grown to the extent that the Sys Admin wants to transfer it to a better spec'd server which can better handle the workload.   The Sys Admin can detach it from the old server (e.g. a Sun4u) and reattach it to the new server (e.g. a Sun4v) using Zones "Update On Attach".   This will bring the OS Software level on the non-global zone up to the same level as the new server's global zone.

Zones "Update On Attach" can certainly be used for patching but there are limitations you need to be aware of as outlined below.

For example, detach the non-global zones from a system, apply a bunch of patches to the global zone, reattach the non-global zones using "Update On Attach" and viola, the non-global zones will be brought up to the same software level as the global zone (for OS type packages), effectively patching the non-global zones without using 'patchadd' at all.   This is typically even faster than using Zones Parallel Patching.  But there are limitations to this approach which users must be aware of (see below).

My senior engineer, Enda O'Connor, has just published an interesting article on The Zones Update on Attach Feature and Patching in the Solaris 10 OS. 

Zones "Update On Attach" limitations as a patching aid

Zones "Update On Attach" only works for packages which are SUNW_PKG_ALLZONES=true - i.e. typically OS level packages, and not application packages.

So when to use Zones Parallel Patching in 'patchadd' and when to use Zones "Update On Attach" ?

Here's what my senior engineer, Enda O'Connor, says:

"The Zones Update on Attach Feature and Patching in the Solaris 10 OS document may help customers understand how the technology works, applying a cluster via patching and via zones Update On Attach is not quite the same really.

It really depends on the patches being applied, i.e. applying a firefox patch via Update On Attach would not work if you wanted it to apply to the global zone and all non-global zones as well.

One has to understand how Update On Attach works and then apply that to the list of patches to see if it gets them to a desirable state.

There is no black or white answer here.

I'd recommend Zones Parallel Patching using 'patchadd' as it has a known outcome all the time, whereas Update On Attach makes it's own internal determination based on a number of things, that can vary from system to system ( e.g. inherited directories ).

But if time to patch is critical then if the customer does proper testing to validate things, and are happy with the results, then by all means use Update On Attach.

But using Update On Attach without:

1. Understanding how it determines what packages to update

2. Not inspecting the patches being applied.

...will most likely lead to grief at some point."

And my other senior engineer, Ed Clark, says:

"In terms of giving guidance on which technology to use, there are a number of considerations -- two of these considerations are:

1. Using Update On Attach to update sparse zones can require significantly more disk storage space than would be needed by applying patches with 'patchadd' (3-4 times as much space would not be uncommon i think), due to Update On Attach copying fully populated global zone 'undo' files into the non-global zones, as opposed to having patchadd build sparsely populated 'undo' files in the non-global zones.

2. If a customer is really concerned about the ability to back out patches reliably, then 'patchadd' is a lower risk option than Update On Attach -- 'patchrm' of a patch from a non-global zone that has a copy of the global zones 'undo' pkg data (as is the case after Update On Attach) may potentially have unexpected side effects." [although we have yet to see any actual cases of negative results from this.]

Conclusion

In general, we recommend using the Zones Parallel Patching enhancement in the patch utilities rather than the Zones "Update On Attach" feature as Zones Parallel Patching is standard patching functionality, only faster, whereas Zones "Update On Attach" is really designed for migrating zones from one server as another and was not primarily designed to speed up patching.  

Because Zones "Update On Attach" uses Zones functionality similar to the zone creation functionality, rather than 'patchadd' functionality, limitations exist on what will be patched (typically the OS but not applications) and there's the potential for anomalies around things like the "undo" files which would be used by 'patchrm' if patches applied using Zones "Update On Attach" were subsequently removed from the non-global zones using 'patchrm' (although we have yet to see any actual cases of serious issues resulting from this).

So in patching situations where time is absolutely critical, Zones "Update On Attach" may provide a good option, as long as it's well tested in the customer environment prior to deployment on production systems.

Remember too, Live Upgrade is also your friend in such situations, enabling you to patch an inactive boot environment while the system is still in production.   So a combination of Live Upgrade and Zones Parallel Patching would be ideal.

I hope you find this helpful!

Best Wishes,

Gerry.

The Solaris 10 5/09 (Update 7) patch bundle is now available for download from the SunSolve Patch Cluster & Patch Bundle Download Page.  Click on the "Solaris Update Patch Bundles" link.

As with previous patch bundles, it contains the patches which are included in the corresponding Solaris Update, in this case Solaris 10 5/09 (Update 7).

This is useful for Sys Admins who wish to bring all their systems up to the same patch level as the Solaris Update without wanting to upgrade to the release - for example, due to change control policy restrictions in their organizations.

See previous blog entries for previous Solaris Update patch bundles for further information.

Solaris 10 5/09 (Update 7) and subsequent Kernel PatchIDs 

The Kernel patch included in Solaris 10 5/09 (Update 7) has now been released to SunSolve.  The PatchIDs are 139555-08 (SPARC) and 139556-08 (x86).  The rest of the patches included in Solaris 10 5/09 are either released or in the process of being released over the next week or so. 

I've updated the Solaris Kernel PatchID sequence listed in http://blogs.sun.com/patch/date/20080416 to reflect this, including the PatchIDs of the post Solaris 10 5/09 (Update 7) sustaining Kernel PatchID and the Solaris 10 Update 8 Kernel PatchID.

We will be releasing a patch bundle containing the set of patches included in Solaris 10 5/09 in the next couple of weeks.  This will be available from the "Solaris Updates Patch Bundle" section on the new look SunSolve Patch Cluster and Patch Bundle page, http://sunsolve.sun.com/show.do?target=patches/patch-access, which now includes a description of the purpose, contents, and update frequency of each patch cluster and bundle.

As always, customers need to have a valid support contract in order to download Solaris patch clusters and bundles.

New PatchFinder tool coming

We plan to release a new PatchFinder tool on SunSolve at the end of May.   This leverages the patch metadata in our release database to provide a much richer customer experience to search for patches.  Further enhancements are planned after the initial deployment.  The old PatchFinder tool will remain available for a transition period.

Zones Parallel Patching Performance Enhancement

The Zones Parallel Patching performance enhancement continues on schedule.  It has been successfully beta tested by a number of key customers who confirm a 3x performance improvement patching zones.   It is on schedule to be released in a revision of the patch utilities patch (119254 SPARC / 119255 x86) in June.

Solaris 10 "Recommended" and Sun Alert Patch Clusters

Improvements to the Solaris 10 "Recommended" and Sun Alert Patch Clusters are on schedule to be deployed before the end of June.  The improvements include an improved install_cluster script (currently available in the Solaris 10 Live Upgrade Zones Starter Patch Bundle and the Solaris 10 Updates Patch Bundles) and other process improvements designed to improve quality.

Solaris 8 Vintage Patch Support Program

The Solaris 8 Vintage Patch Support Program is now up and running.  The first Vintage Solaris 8 patches have been released.

Patches which fix SunAlerts which were issued prior to the April 1 start date of the Solaris 8 Vintage Patch Support program will be released as "normal" (i.e. non-vintage) Solaris 8 patches. 

But all other Solaris 8 patches created after April 1, including patches which fix security issues, require customers to have a Solaris 8 Vintage Patch Support contract to use them.

See http://www.sun.com/bigadmin/topics/vintagepatch/  for further information.

A software glitch caused a number of empty patches to be accidentally released last week.   The PatchIDs are:

• 139555, revisions -01 to -07: Solaris 10: Kernel Patch
• 139556, revisions -01 to -07: Solaris 10_x86: Kernel Patch
• 139981-01: Solaris 10_x86: md patch

The above patches have been removed from SunSolve.   All of these patches were empty (i.e. they contained no payload packages), so they are incapable of being installed or causing any problems on a customer system.   This notice is simply to clear up any confusion.

The correct Kernel patch revisions are now available.  These are:

• 139555-08, which is the Solaris 10 Kernel patch included in Solaris 10 5/09 (Update 7)
• 139556-08, which is the Solaris 10 Kernel patch included in Solaris 10_x86 5/09 (Update 7)

The correct "md" patch revision will be released shortly.  This is:

• 139981-03: Solaris 10_x86: md patch

On behalf of Sun, I apologize most sincerely for any confusion or inconvenience caused. 

Here's a Solaris patch presentation (updated July 28th 2009) which I hope will be of use to customers, partners, and field engineers.

It distills much of the information contained in this blog, including the recommended patching strategy, best practices, news on patching enhancements, background information on Solaris and the bug fix process, etc.

Patching isn't a one-size-fits-all operation, but I hope you find the information provided a useful guideline.

A fix to the unzip utility is available in recent patch utility patch revisions.  This fix is required in order to be able to successfully unzip very large files such as the Solaris 10 Recommended and Sun Alert Patch Clusters.

Please download the latest revision of the patch utilities patch first and install it, before attempting to unzip the Solaris 10 Recommended or Sun Alert Patch Clusters.

The fix was incorporated in the putback to CRs 6344676 and 6464056.

The following are the earliest revisions of the patch utilities containing the fix:

• Solaris 10 SPARC: 119254-46 or above
• Solaris 10 x86:        119255-46 or above
• Solaris 9 SPARC:   112951-14 or above
  
• Solaris 9 x86:          114194-11 or above
  
• Solaris 8 SPARC:   108987-19 or above
  
• Solaris 8 x86:          108988-19 or above
  

Without the fix to unzip provided by the above patches, the following error will be seen when attempting to unzip the Solaris 10 Patch Clusters:

# unzip -q 10_Recommended.zip

note:  didn't find end-of-central-dir signature at end of central dir.
  (please check that you have transferred or created the zipfile in the
  appropriate BINARY mode and that you have compiled UnZip properly) 

In addition, do not unzip Solaris patch clusters on Windows. Solaris patch clusters, and solaris patches more generally, can contain case-sensitive file names. Consequently clusters and patches must be unzipped on a case-sensitive filesystem (corruption can occur if unzipping on filesystems that are not case-sensitive). 

The above information is now published in Infodoc http://sunsolve.sun.com/search/document.do?assetkey=1-62-252447-1

I've been asked to post a clarification: 

You cannot patch Solaris 10 from Solaris 8 or 9 as the version of 'patchadd' in Solaris 8 and 9 is totally unaware of how to handle Zones and other Solaris 10 specific features.

If using Live Upgrade to upgrade an inactive boot environment from Solaris 8 or 9 to Solaris 10, you must activate and boot into the Solaris 10 boot environment before patching it.  For example, activate and boot into the Solaris 10 boot environment, and either patch the live boot environment or create another inactive boot environment, and then apply patches to the inactive boot environment.

See http://www.sun.com/bigadmin/features/articles/live_upgrade_patch.jsp for further information.

Thanks to my colleague Enda O'Connor, who has made p7zip available for Solaris 8 SPARC, it's now possible to upgrade directly from Solaris 8 SPARC to the latest Solaris 10 Update releases such as Solaris 10 5/08 and Solaris 10 10/08.  See http://sunsolve.sun.com/search/document.do?assetkey=1-9-250526-1 and http://sunsolve.sun.com/search/document.do?assetkey=1-61-72099-1 for details.

Previously, due to the lack of p7zip on Solaris 8, customers needed to perform an interim upgrade to Solaris 9 or an earlier Solaris 10 release before upgrading to the latest Solaris 10 release.

The following is now published as Infodoc 208057:

To whom it may concern,

Over time, customers may experience space issues in /var as patch "undo" and "obsolete" data, which is stored for use during patch backout, builds up as more patches are applied to the system.

It is best to plan for this expansion of /var in advance,  and allocate plenty of free space to this partition. 

How much space to allocate to /var depends on a number of variables, such as how many patches are likely to be applied to the system, which is dependent on frequency of patching, strategy of which patches will be applied (all, sun alert, security only, etc.), products patched; whether the system has zones which implies 'pspool' space requirements, etc.  A figure of 10Gb to 20Gb or even more is not unreasonable.   In my Patch System Test lab, we currently have Solaris 10 systems with >7GB used in /var and this will continue to grow over the lifetime of Solaris 10.

If you have insufficient space in /var of an existing system, the recommended solution is to extend the size of the /var partition.  This can be accomplished by backing up /var, creating a bigger /var partition on another disk, restoring the /var backup onto that partition and then updating the /var entry in the /etc/vfstab file.  If /var is part of the "/" (root) partition, then relocating /var to a separate partition would be a good solution.  The relocation process is documented in Infodoc 215988.

Sun strongly discourages manual modifications to the /var/sadm/pkg directory and its file structure.  That directory structure should only be modified by the Solaris[TM] patching and packaging utilities.  Corruption in this directory structure will prevent any future packaging or patching operations.

Below is information on how to free up space in /var by deleting certain patch related files.  This should only be used when there are no other ways of gaining space in /var.

Having a full and current backup of the OS is highly recommended before deleting files from /var.

On behalf of Sun Microsystems, I hereby confirm that unneeded "obsolete" and "undo" files may be removed from the /var/sadm/pkg/<pkgname>/save/<PatchID> and "undo" files from the /var/sadm/pkg/<pkgname>/save/pspool/<pkgname>/save/<PatchID> directories in order to free up space in /var.

This will not invalidate support contracts.

The "undo" files are used during the patch removal process. Removing the "undo" files associated with a patch means that it will no longer be possible to uninstall the patch.

Once a later revision of a patch is applied, or a patch which obsoletes a patch is applied, the "undo" files in /var/sadm/pkg/<pkgname>/save/<PatchID> are renamed "obsolete".  These "obsolete" files may also be removed.

It is strongly recommended to only remove the "obsolete" and "undo" files for patches which the customer is confident will not need to be backed out - for example rejuvenated Kernel patches associated with Solaris 10 Update releases such as 118833-36 (SPARC) / 118855-36 (x86), 120011-14 (SPARC) / 120012-14 (x86), etc. and other older Kernel patch revisions.  See the sequence of Solaris 10 Kernel PatchIDs listed on http://blogs.sun.com/patch/date/20080416

As patches containing subsequent fixes to the objects contained in these rejuvenated patches will have a SUNW_REQUIRES dependency on the these rejuvenated patches, it's extremely unlikely that older versions of these rejuventated Kernel patches will ever be backed out.   Therefore, their "undo" files are prime candidates for removal to free up space in /var if required and it's not possible to extend /var.

All the "undo" or "obsolete" files for a particular patch should be removed from the /var/sadm/pkg/<pkgname>/save/<PatchID> directories. For example:

rm /var/sadm/pkg/*/save/118833-36/undo*

The system also keeps a copy of "undo" files for use during creation of new non-global zones. These may also be removed if the customer is confident that the patches will not need to be backed out. For example:

rm /var/sadm/pkg/*/save/pspool/*/save/118833-36/undo*

The "undo" files in the pspool directory are not renamed to "obsolete" when a later revision is installed.

Further Information:

1. The "undo" files are specific to the zone of the system on which they were created during application of a patch by patchadd. Therefore, do not copy the "undo" file from one zone to another or from one system to another.

2. One could potentially archive the "undo" files for each zone of a system and restore it to that zone if desired.

Best Wishes,

Gerry Haskins
Director, Software Patch Services

This blog entry expands on a previous blog entry regarding Solaris patch entitlement.  

The Solaris patch entitlement policy is available on http://sunsolve.sun.com/search/document.do?assetkey=1-61-203648-1. "Entitlement" refers to patches which require you to have a valid support contract to access them.

Solaris changed its business model a few years ago from selling Solaris and providing patches for free to a model of giving away the Solaris releases for free and charging for patches.

The Solaris patch entitlement policy applies to all Solaris Operating System patches.  It does not necessarily apply to middleware or application layer product patches which may be installed on top of Solaris, such as SunStudio, Java, etc.

The Solaris patch entitlement policy is that the following Solaris OS patches will remain available irrespective of whether or not you have a valid support contract:

• the specific patch revisions which introduce all new security fixes
• the specific patch revisions which introduce certain hardware support
• all revisions of Solaris patch utility, smpatch, and Update Manager patches to ensure correct patch application
  
• the specific pre-requisite patch revisions for Live Upgrade
  
• the specific pre-requisite patch revisions for certain Sun software application products
• all revisions of patches which patch products which are both bundled as part of Solaris and also released as separate products which don't enforce patch entitlement
  
• a small number of other specific patch revisons at the discretion of Sun
• any patch revision explicitly required by any of the above patches
  

Other Solaris OS patches require that you have a valid support contract to access them.

All fixes will all be available for free in the next Solaris 10 Update release, so if you are not willing to pay for a support contract, you can still get the fixes by installing or upgrading to the next Solaris 10 Update release.  You'll just need to wait for it to be released.

The key point is that if you may need timely access to a patch which fixes a critical non-security issue, then you need to have a valid support contract for each system you may wish to patch.  You also need to have a valid support contract in order to get telephone support or fixes coded for any issues which are unique to your environment.

So it's highly advisable for you to have a valid support contract in place for each production system.

If you are a home user for example, and don't want to go to the expense of buying a support contract, using OpenSolaris or waiting for the next Solaris 10 Update release are valid options.

This policy is not changing.

What is changing is the implementation of patch entitlement to ensure it matches the policy.  Currently, circa 60% of Solaris OS patches are available without a support contract, including most of the key patches.  Under the new entitlement implementation, 18% of Solaris OS patches will remain available without a support contract.  The rest will require a valid support contract to access. 

Any of the following support contracts will provide you with access to all Solaris OS patches and patch clusters: a Solaris subscription, a Software Support Contract, a Sun System Service Plan for Solaris, a Sun Spectrum Storage Plan, or a Sun Spectrum Enterprise Service Plan.  Since the names of the support contracts change from time-to-time, this list may change.

If you are running Solaris on Sun Hardware, I suggest you consider purchasing a SunSpectrum System Plan.  This will cover both your HW and OS with one simple support contract.

If you are running Solaris on non-Sun hardware, you should consider a Solaris Subscription Support Plan, which is available on-line from just $324 per year.

Remember, you need a support contract for each system you wish to patch, so if you need more of a site-wide support plan, Solaris Everywhere is a good choice. 

BTW: It's important to remember that hardware warranties do not cover software support or access to Solaris patches.

The new implementation will roll out in phases, starting this week.

You should check that you have valid support contracts in place for each system you may need to patch.  Please do not wait until you need a patch to put the support contract in place. There is a latency of several days between subscribing for a support contract and patch access being granted.  Support for your production Operating System really isn't something you should play "chicken" with.

The new Solaris OS patch entitlement implementation roll-out should be completely transparent if you have a valid support contract for each system you wish to patch.

A PodCast talking about the above and the Solaris 8 Vintage program which commences April 1, 2009 is available here

The Solaris 10 Live Upgrade Zones Starter Patch Bundle has been released.  It is designed to make it simpler for customers running on systems below Solaris 10 5/08 (Update 5) to apply the pre-requisite patch level needed to be able to utilize basic Live Upgrade functionality in a Zones environment.  These patches need to be applied to the live boot environment to enable Live Upgrade to work correctly in a Zones environment.

Aside: Customers with systems running Solaris 10 5/08 (Update 5) or later already have all the  pre-requisite patches pre-installed on the live boot environment and hence do not need to apply this patch bundle.

After this, Live Upgrade itself can be used to create an inactive boot environment and apply any additional patches referenced in SunSolve document 206844 'Solaris[TM] Live Upgrade Software: Minimum Patch Requirements' (formerly Infodoc 72099) to provide advanced Live Upgrade functionality such as support for ZFS Root. The document is available from: http://sunsolve.sun.com/search/document.do?assetkey=1-61-206844-1

The Solaris 10 Live Upgrade Patch Bundle is available from the normal patch cluster download center on SunSolve.  To download the patch bundle, login to SunSolve, http://sunsolve.sun.com , click on the Patches and Updates link, click on Recommended Patch Clusters, and scroll down the window under the heading "Recommended Solaris Patch Clusters, J2SE and Java Enterprise System Clusters" to find the "Solaris 10 SPARC Live Upgrade Zones Starter Patch Bundle" or "Solaris 10 x86 Live Upgrade Zones Starter Patch Bundle".  As always, you need a valid support contract to access patch clusters.  See previous postings for further information on support contracts.

My colleague, Enda O'Connor, has written another useful article on Big Admin about patching using Live Upgrade, restrictions, and how-to use Live Ugrade to upgrade/patch from Solaris 8 or Solaris 9 to Solaris 10.  See http://www.sun.com/bigadmin/features/articles/live_upgrade_patch.jsp

Last week, the Solaris 10 05/08 (Update 5) Patch Bundle was released on SunSolve.  The patch bundle provides another option to customers when deciding their patching strategy to maintain their Solaris systems.

What is the Solaris 10 05/08 Patch Bundle ?

The Solaris 10 05/08 Patch Bundle contains the equivalent set of patches contained in the Solaris 10 05/08 (Update 5) release image.

Why use the Solaris 10 05/08 Patch Bundle ?

The Solaris 10 05/08 Patch Bundle was created as a result of direct customer feedback after the Solaris 10 08/07 (Update 4) release.  New hardware may require a specific minimum Solaris 10 Update release such as the Solaris 10 05/08 (Update 5) release.  Some customers may wish to bring their other existing Solaris 10 systems up to the same patch level as the new hardware running Solaris 10 05/08.  The recommended way to do this is to upgrade the existing systems to the Solaris 10 05/08 release using either regular Solaris Upgrade or Solaris Live Upgrade.  But some customers may have policies in place which make it difficult to upgrade but OK to patch a system.  The Solaris 10 05/08 Patch Bundle facilitates such customers to bring their existing systems up to the equivalent patch level to the Solaris 10 05/08 (Update 5) Release.  In theory, this should mean that pre-existing functionality on all of the customers' systems should react the same, warts and all. This makes for a more homogeneous environment which may help lower support costs.

The Solaris 10 Update releases are very intensely tested by a wide variety of QA teams within Sun.  Therefore, the functionality contained in the patches within the Solaris 10 05/08 Patch Bundle have been intensely tested as a unit through the testing performed on the Solaris 10 05/08 (Update 5) release image.  Additional testing of the Solaris 10 05/08 Patch Bundle has also been performed by the Patch System Test team.  Therefore, the Solaris 10 05/08 Patch Bundle provides a well tested "baseline" option on which to standardize systems.

So while the patch bundle may deliver more change than some other patching strategies, that change has been well tested as a unit and hence may actually reduce the risk of introducing regressions when compared to "dim sum" patching (i.e. choosing an arbitrary combination of patches).  Note that intensive processes are also in place to ensure "dim sum" patching works, and it's rare to encounter a problem caused by "dim sum" patching.

How does the Patch Bundle differ from the Solaris 10 05/08 (Update 5) release image ?

The Solaris 10 05/08 (Update 5) release is a complete Solaris release image.  It contains new packages to support new features in the Solaris 10 05/08 (Update 5) release as well as all Solaris patches which were available when the Update was built.  The patches are pre-applied into the Solaris 10 05/08 release image.  This means that one doesn't have to spend time adding the patches using 'patchadd'.  On the flipside, since the patches are pre-applied into the release image, they cannot be backed out using 'patchrm'.  This isn't generally a problem as the Solaris Update release images are very intensely tested.  One can do a fresh install of the Solaris 10 05/08 (Update 5) release, or upgrade to it from an earlier Solaris release.

The Solaris 10 05/08 Patch Bundle contains the equivalent set of patches to the Solaris 10 05/08 (Update 5) release. The patch bundle does not include the new packages contained in the Solaris 10 05/08 (Update 5) release.  Therefore, new features in Update 5 which depend upon new packages introduced in that release will not be available in the patch bundle.  However, as discussed in a previous blog entry, any change to pre-existing code is delivered in a patch.  This includes features as well as bug fixes.  Therefore some feature enhancements will be available in the patch bundle.  ZFS, for example, is typically self-contained in patches and hence ZFS enhancements will typically be available via the patch bundle as well as via the Update release image. So will most Zones enhancements.  The patch bundle is simply a collection of patches with an install order file (patch_order) and an install script wrapper (installbundle.sh) around 'patchadd'.  Patches in the patch bundle can be backed out using 'patchrm', so long as the '-d' (no save) option wasn't used when applying the patch bundle.

There are a number of "special" or "script" patches included in each Solaris Update release.  These patches are used to correct issues in how patches are pre-applied into the Solaris Update release image and have no purpose whatsoever outside of the Solaris Update release process.  Therefore, these "special" or "script" patches are not released to SunSolve and are not included in the patch bundle.  See the Solaris 10 05/08 Patch Bundle README file for further information on these and other minor differences between the patch set pre-applied in the Solaris 10 05/08 release image and the patch set included in the Solaris 10 05/08 Patch Bundle.

Access 

The Solaris 10 05/08 Patch Bundle is available from the usual patch cluster location. 

Log onto Sunsolve, click on Patches and Updates, then Recommended Patch Clusters and scroll down the box under "Recommended Solaris Patch Clusters, J2SE and Java Enterprise System Clusters" to the Solaris 10 SPARC 05/08 Patch Bundle and Solaris 10 x86 05/08 Patch Bundle entries.  

The cluster is chunked to aid download.  There are 2 chunks for x86 and 3 chunks for SPARC. 

Follow the download instructions to the right of the scroll-down box or read the README file for any chunk.

As with all patch clusters, you need a valid support contract to download the cluster.   The following support contracts include access entitlement to Solaris patches and Patch Clusters (BTW: Software Update = patch), plus a wide range of additional support services:  Solaris Subscriptions, which includes Basic, Standard, Premium, and Solaris Everywhere Service Plans (compare here); Sun Software Service Plans, including Basic, Standard, Premium, and Premium Plus; Sun System Service Plans for Solaris, which includes Bronze, Silver, Gold, or Platinum options (compare here); or a Sun Spectrum Enterprise Service Plan.  See also http://www.sun.com/servicelist/ for country specific details.

Installation

Read the Patch Bundle README file for full installation instructions.

The patch bundle can be installed either on the active boot environment (i.e. the live system) or an inactive boot environment. 

Patching an inactive boot environment is recommended as, depending on the starting patch level of the target system, it may involve less system downtime as only a single reboot is required at the end to activate the boot environment. 

If you patch the active boot environment (i.e. the live system), then depending on the starting patch level of the target system, you may need to reboot an x86 system up to three times (twice at specific points during the installation process and once at the end) and a SPARC system up to two times (once after installing Kernel patch 118833-36 and once at the end).  See the patch bundle README for details.

The Solaris 10 05/08 Patch Bundle includes a new install script, installbundle.sh, which guides users through the installation process. 

The patches are ordered in such a way as to process any reboots required when patching an active boot environment as near the start of the installation process as possible.  This is to facilitate System Administrators by allowing them to get over the interim reboots early in the process and kick off the final patching sequence and let the process complete. 

The screen output and logfiles produced are also designed to be as clear and self-explanatory as possible, providing both overview and drill-down capabilities.

Approximate Installation Time 

How long it will take to install the Solaris 10 05/08 Patch Bundle will depend upon a number of factors:

• The speed of the hardware and its I/O.
  

• Which Solaris 10 release is installed on the target system and what patch level the system is at.  The higher the Solaris 10 Update release or patch level, the quicker the patch bundle will apply.

• Whether Zones are installed on the system and which type of Zone.  Currently, the time to apply the cluster to each whole root non-global Zone will be approximately linear - i.e. multiple the install time by the number of whole root non-global Zones on the system.  Sparse root non-global Zones will be a little faster. (BTW: Sparse root non-global Zones is the recommended option when creating non-global Zones.)  As mentioned in a previous blog posting, there is a project in development to improve Zones patching performance.
  

For example, I installed the Solaris 10 x86 05/08 Patch Bundle on a v65x running the original Solaris 10 3/05 "FCS" (First Customer Shipment) release with no additional patch applied (worst case) and no non-global Zones.  I applied the patch bundle to the active boot environment.  Installation took a total of 3 hours and 58 minutes plus 3 reboots (see the Patch Bundle README for an explanation of the reboots when patching an active boot environment).

Conclusion

The Solaris 10 05/08 Patch Bundle will not suit everyone.  It is a large collection of patches and hence is slow to download and install.

As described in a previous blog posting, the Sun Alert patch clusters (available from the same location on SunSolve - see above) provide the minimum amount of change to address the most critical Solaris issues.  The Sun Alert cluster contains all available Solaris patch fixes for Security, Data Corruption, and System Availability issues. New versions of the Sun Alert cluster are posted whenever a new patch to fix a Sun Alert issue becomes available.  Customers should try to keep as current as possible with the contents of the Sun Alert clusters.

For customers who want to bring all their systems to the Solaris 10 05/08 (Update 5) release patch level, installing or upgrading to the Solaris 10 05/08 (Update 5) Release image remains the recommended option where feasible.  The Solaris 10 05/08 Patch Bundle was simply created in response to a demand from customers for an alternative option where upgrading was not feasible due to internal customer policies.

Since Solaris Update releases are intensely tested, the patch bundle provides a good quality patch "baseline" on which to standardize systems.

From customer feedback to date, the next Patch Bundle for the equivalent set of patches for Update 6 is likely to also be a complete set of patches from Solaris 10 3/05 "FCS" (First Customer Shipment - i.e. the original Solaris 10 release) and not an incremental bundle just containing the patch set delta between Updates 5 and 6 as I had previously suggested.  Feel free to post a comment with your preference.

Enjoy!

Please see the Patch Management Best Practices guide which my colleague, Enda O'Connor, has published on the BigAdmin Patching Hub.  I hope you'll find it useful.

Enda is a senior engineer in Patch System Test and he is far more technical than I am.

Enda has more practical experience of patching Solaris 10 Zones environments than anyone else in Sun.

Enjoy!

Patch Rejuvenation

When a patch becomes complex and unwieldy, it is "Rejuvenated".   That is, no more revisions of the patch are created.  Instead, further code changes to objects contained in the patch are delivered in a series of smaller, simpler, new child PatchIDs, each of which declares a dependency upon (i.e. requires) the parent Patch.

This process is known as Patch Rejuvenation and is typically performed on the Kernel patches associated with Solaris Update releases.

Customers still need to install the large parent Patch once, but subsequent bug fixes are delivered in smaller, simpler patches.

The parent patches effectively provide "stepping-stones" to reach certain key functionality levels, with rejuvenation enabling smaller incremental change in between Update releases.

If a child patch itself becomes complex and unwieldy over time, it too may be Rejuvenated, so we end up with a "family tree" of PatchIDs providing a lineage of bug fixes for particular code areas such as the Kernel.

See http://sunsolve.sun.com/search/document.do?assetkey=1-9-86481-1 for further information.

Effect of Solaris Update "SplitGate" process on PatchIDs

Starting in February 2007, a new, improved, source code "Gate" management process was introduced for core Solaris.  This is known as the "SplitGate" process.  This replaced the old "Feature Foldback" Gate management model. "SplitGate" provides much better separation during the development process between feature code destined for release as part of a Solaris Update release and sustaining (bug fix) patches.  This addresses the problem with earlier Solaris 10 Update releases where issues with features destined for an Update release was adversely impacting the releasability of sustaining (bug fix) patches for customers in production on earlier Solaris 10 releases.

Note, as described in earlier blog postings, any change to pre-existing packages, whether as the result of new feature code or bug fixes, is always delivered in a patch.  Therefore, the Kernel patches released at the end of each Update do contain a mixture of feature and bug fix code.  What "SplitGate" provides is better separation of the feature code from bug fix patches until the Update is ready for release.

The improvement in Solaris 10 Kernel patch releasability has been dramatic:

Releasable Solaris 10 Kernel Patches using “Feature Foldback” model:

    SPARC:      21 out of 66 = 32%    (from March 2005 to February 2007)
    x86:           12 out of 66 = 18%    (from March 2005 to February 2007)

Releasable Solaris 10 Kernel Patches using “SplitGate” model:

    SPARC:      36 out of 41 =  88%    (from February 2007 to current [May 8th, 2009])
    x86:            39 out of 41 =  95%    (from February 2007 to current [May 8th, 2009])

A side effect of the "SplitGate" process, is that each Solaris 10 Update release, starting with Solaris 10 8/07 (Update 4) introduces a new set of PatchIDs which accumulate and obsolete the preceding set of PatchIDs. 

So, for example, a single new Kernel PatchID revision will appear at the end of each Solaris 10 Update release. For instance, 120011-14 (SPARC) and 120012-14 (x86) is the Kernel PatchID associated with Solaris 10 8/07 (Update 4).  Revisions -01 to -13 of this patch are not released to customers as these are purely for the interim internal builds of the Update.  Therefore, 120011-14 (SPARC) and 120012-14 (x86) are the only revisions of these PatchIDs to be released to customers.  This Kernel patch associated with the Update release is then Rejuvenated, so subsequent bug fixes will appear in a new set of PatchIDs, each of which will depend upon (i.e. require) the parent PatchID from which they were rejuvenated.

Solaris 10 Kernel Patch Lineage 

The impact of Patch Rejuvenation and the "SplitGate" process results in the following sequence of Solaris 10 Kernel PatchIDs, starting with the youngest (newest) child PatchID.  The install order of Kernel patches is starting from the bottom of the table upwards:

Solaris 10 SPARC Kernel PatchIDs	Description	Solaris 10 x86 Kernel PatchIDs
142909-xx only	Solaris 10 Update 9 Kernel PatchID	142910-xx only
142900-01 to 142900-xx	Sustaining Bug Fixes post Solaris 10 10/09 (Update 8)	142901-01 to 142901-xx
141444-09 only	Solaris 10 10/09 (Update 8) Kernel PatchID	141445-09 only
141414-01 to 141414-10	Sustaining Bug Fixes post Solaris 10 5/09 (Update 7)	141415-01 to 141415-10
139555-08 only	Solaris 10 5/09 (Update 7) Kernel PatchID	139556-08 only
138888-01 to 138888-08	Sustaining Bug Fixes post Solaris 10 10/08 (Update 6)	138889-01 to 138889-08
137137-09 only	Solaris 10 10/08 (Update 6) Kernel PatchID	137138-09 only
137111-01 to 137111-08	Sustaining Bug Fixes post Solaris 10 5/08 (Update 5)	137112-01 to 137112-08
127127-11 only	Solaris 10 5/08 (Update 5) Kernel PatchID	127128-11 only
127111-01 to 127111-11	Sustaining Bug Fixes post Solaris 10 8/07 (Update 4)	127112-01 to 127112-11
120011-14 only	Solaris 10 8/07 (Update 4) Kernel PatchID	120012-14 only
125100-04 to 125100-10	Sustaining Bug Fixes post Solaris 10 11/06 (Update 3)	125101-01 to 125101-10
118833-02 to 118833-36	118833-33 (SPARC) / 118855-33 (x86) is the Kernel patch included in Solaris 10 11/06 (Update 3) but these patches were not releasable as "standalone" patches to SunSolve. 118833-17 (SPARC) / 118855-14 (x86) is the Kernel patch included in Solaris 10 6/06 (Update 2). 118855-14 was not releasable as a "standalone" patch to SunSolve.	118855-01 to 118855-36
118822-01 to 118822-30	118822-25 (SPARC) / 118844-26 (x86) is the Kernel patch included in Solaris 10 1/06 (Update 1). 118844-26 was not releasable as a "standalone" patch to SunSolve.	118844-01 to 118844-30

As mentioned in previous blog postings, when applying patches to a live boot environment, the Solaris 'patchadd' utility may end up invoking objects which it has just patched during the installation of the remainder of the patch or patches.  This can cause the system to get into an inconsistent state during patching, as the new objects may be incompatible with objects already loaded in memory.  This is especially true in a Zones environment, where 'patchadd' calls the Zones utilties in order to patch the non-global Zone(s) after patching the Global Zone.

This wasn't a problem in Solaris 8 or Solaris 9, as the amount of code change delivered in patches was limited.  But due to the large features included in Solaris 10 Updates, this became a problem for Solaris 10.

For example, a new library may be invoked which makes a system call and passes 5 arguments, but the old Kernel is still running, not the newly applied Kernel, and if the old Kernel only expects to receive 3 arguments for the system call, problems are likely to result.

Deferred Activation Patching addresses this issue for new patches (see previous postings below), but customers must follow the Special Install Instructions listed in the patch READMEs of some older Solaris 10 patches to avoid such problems as it is not possible to retrofit Deferred Activation Patching into previously released patches.

118844 (x86) Library compatibility

When patching a Solaris 10 x86 live boot environment, Kernel patch 118844-19 or higher must be active to ensure compatibility with library changes provided in subsequent patches.

Therefore, if you are patching an old Solaris 10 x86 system which is below this Kernel patch level, you will need to reboot the system after applying 118844-19 or higher. 

For example, 118844-20 is included in the Solaris 10 x86 Recommended and Sun Alert Clusters on SunSolve to fulfill this purpose.  See the CLUSTER_README files for further information.

118844 (x86) NewBoot (GRUB)

Solaris 10 x86 Kernel patch 118844-21includes the GNU GRand Unified Bootloader (GRUB) architecture.

Please follow the appropriate system specific instructions specified in SunAlert http://sunsolve.sun.com/search/document.do?assetkey=1-26-102087-1 . 

Failure to follow these instructions might result in the system failing to boot.

118833-36 (SPARC) / 118855-36 (x86)

118833-36 (SPARC) and 118855-36 (x86) are the Solaris 10 Kernel patches associated with the Solaris 10 11/06 (Update 3) release.  They contain significant amounts of code change.

To avoid the system getting into an inconsistent state during patching, lofs loopback mounts are used in the patch's scripts to mount the original objects over the newly installed objects.  This ensures that any objects invoked by the patch utilities during patch application will be the old versions and will be consistent with processes loaded in memory.  Upon reboot, the lofs mounts get torn down, exposing the patched objects for use.  As a safety precaution, code in the patch's scripts overlay mount the patch utilities with a no-op object to ensure the system is rebooted before further patches can be applied.  This is to prevent subsequent patches from potentially patching the lofs mounted objects rather than the underlying patched objects.

This concept of utilizing lofs loopback file system mounts was later formalized as Deferred Activation Patching, which is now implemented in the Solaris patch utilities patch.  Deferred Activation Patching is described in a previous posting below.  In the Deferred Activation Patching implementation, the solution has been enhanced to enable further patches to be applied without having to first reboot.  This is achieved by applying all subsequent patches affecting the same objects in implicit Deferred Activation Patching mode (i.e. they are also applied utilitizing loopback mounts).

Customers are strongly advised to read and follow the Special Install Instructions in the README files in patches 118833-36 (SPARC) and 118855-36 (x86).  These are the most complex patches which Sun has ever released.

When is an obsoleted patch not fully obsolete ? 

Answer: When removing it from a patch set would introduce a circular dependency between the remaining patches. 

A circular dependency is where Patch A requires Patch B to be installed first and Patch B requires Patch A to be installed first.  Catch 22.  Neither patch can be installed.

The situation is pretty obvious where only 2 patches are involved, but more typically the situation can potentially arise where 3 or more patches are involved as newer patches accumulate and obsolete older patches.

For example, if Patch B requires Patch C, and Patch A requires Patch B and Patch A also obsoletes patch C, then if all three patches are present, the following is a valid install order:

   Patch C

   Patch B

   Patch A

However, if Patch C is removed from the patch set because it has been obsoleted and therefore considered no longer needed (it has been accumulated by Patch A so all dependencies on Patch C would normally be resolved by installing Patch A), then there's no valid install order as Patch A requires Patch B to be installed first and Patch B requires Patch A to be installed first.

Unfortunately, the first thing almost any patch tool does when processing patches is to discard obsolete patches.  This is true of 'patchadd -M' and most higher level patch automation tools.

Normally, this isn't a problem, as audits are in place to catch such issues during the patch creation and test processes.  Typically, if such a patch relationship exists, Patches A and B would be accumulated together into a single patch.

However, in Solaris 10, this wasn't possible with Zones patch 122660-10 (SPARC) / 122661-08 (x86) as outlined below. 

While this situation has only occurred once, and every effort will be made to prevent recurrences, there's no guarantee that similar complex patch relationships won't arise in the future.  Therefore, patch automation tools and home-grown customer patching processes may need to cope with situations where "obsoleted" patches may still need to be installed.

Zones patch 122660-10 (SPARC) / 122661-08 (x86) 

Zones patch 122660-10 (SPARC) and 122661-08 (x86) must be applied before Kernel patch 120011-14 (SPARC) and 120012-14 (x86) can be applied due to CR 6471974 "zoneadm mount mishandles shared file systems".

CR 6471974 is fixed in 122660-10 (SPARC) / 122661-08 (x86).

Customers with Zones environments where non-global zones include a non-IPD entry that references a file system shared between two boot environments are affected by CR 6471974 unless they install 122660-10 (SPARC) / 122661-08 (x86).

Such customers cannot alt mount their zones.

On SPARC, 122660-10 is also obsoleted by 120011-14 and on x86, 122661-08 is obsoleted by 120012-14.

The problem is that we need the fix for CR 6471974 in place before Kernel patch 120011-14 (SPARC) / 120012-14 (x86) can be applied to such systems.

So we need the fix which is contained in the Kernel patch which has accumulated and obsoleted the zones patch before we can add the Kernel patch.  Catch 22. 

We could not fix the problem by checking for the presence of the Zones patch in the prepatch script of Kernel patch 120011-14 (SPARC) / 120012-14 (x86) as patchadd would fail to alt mount the zones, and therefore never get as far as running the Kernel prepatch script.

Also, we could not have the Kernel patch require the Zones patch 122660-10 / 122661-08 directly as it already accumulated it.

To fix the problem, we had to take the unusual step of creating a "zones indirection" patch, 125547-02 (SPARC) and 125548-02 (x86) , which includes a prepatch script to check that the Zones patch is installed on the target system and exit gracefully if it is not.  120011-14 (SPARC) / 120012-14 (x86) require the respective "zones indirection" patch, which in turn ensures Zones patch 122660-10 (SPARC) / 122661-08 (x86) is installed.

122660-10 (SPARC) and 122661-08 (x86) are included in the Solaris 10 SPARC and x86 Recommended and Sun Alert patch clusters available from SunSolve and are automatically installed by the cluster_install script.

However, if a customer is not using the patch clusters and instead provides a patch list including 122660-10 (SPARC) or 122661-08 (x86) to 'patchadd -M' to install, it will be discarded by patchadd during its patch install ordering process as it recognizes that these patches are obsolete and hence assumes they are no longer needed.

Many higher level patch automation tools are likely to make the same assumption.  A number of them have been modified to correctly handle this situation.

If a customer encounters this issue, simply install 122660-10 (SPARC) or 122661-08 (x86) separately, and then apply the rest of the patch set as normal.

The generic issue to be solved is the need to be able to patch safely across arbitrary change and is logged as CR 6486471.

The problems of patching a live Solaris 10 boot environment became most acute with the Kernel patch associated with the Solaris 10 11/06 (Update 3) release.

The problem when patching a live boot environment, is that some of the changes delivered in a patch, such as shared objects, may be invoked by processes as soon as they are applied to the live boot environment.   Other objects, such as genunix, will only be activated when the system is rebooted.   Problems can occur where the scope of the change applied is very large compared to that which is running on the live boot environment.  In such cases, the new objects which are invoked, e.g. zoneadmd, may be incompatible with the old objects running in memory, e.g. genunix.  This can cause the live boot environment to get into an inconsistent state during patching.  The problem is most acute on a system running Zones, since the patch utilities need to invoke the zones utilities during patching to patch the non-global Zones.

A solution using loopback file system mounts (lofs) was incorporated into Kernel patch 118833-36 (SPARC) and 118855-36 (x86).  This overlays the patched objects with the original versions which were present on the system, ensuring that the system remains in a consistent state during the application of the patch.  When applied to a live boot environment, these patches require a reboot before any further operation, including the application of any further patches can be performed.  This forced reboot requirement is not good from a system availability standpoint.

The solution was subsequently refined and formalized as Deferred Activation Patching.

Loopback mounts are used to overlay the original objects on top of the patched objects.  This keeps the live boot environment in a consistent state during patching, irrespective of how much change is delivered in the patches.  Once all patches have been applied, the system is rebooted to activate the changes delivered in the patches.  At all points in time, the live boot environment remains in a consistent state.  Patches specifying application in Deferred Activation Patching mode set the SAFEMODE flag in the pkginfo file(s) in their packages.  The Solaris patch utilities will automatically recognize if any subsequent patches applied prior to the reboot touch the same objects as the patch applied in Deferred Activation Patching mode and will automatically install such patches in Deferred Activation Patching mode too.  Patches which don't intersect with a patch specifying Deferred Activation Patching mode will continue to be installed as normal.

Deferred Activation Patching was initially delivered in the Solaris 10 patch utility patch 119254-42 (SPARC) and 119255-42 (x86).  It is recommended that customers use patch utility patch 119254-50 (SPARC) and 119255-50 (x86) or later revision as these address some bugs in Deferred Activation Patching.

The Kernel patch associated with the Solaris 10 8/07 (Update 4) release, 120011-14 (SPARC) and 120012-14 (x86), are the first patches to utilitize Deferred Activation Patching.

Deferred Activation Patching will only be specified in patches which require it.  This is likely to be the Kernel patches associated with future Solaris 10 Update releases. 

See the Deferred Activation Patching article on the BigAdmin Patching Hub for further information.

Originally (ca. 8+ years ago), no new features were allowed in Solaris Update releases.

But there was a pressing need to add driver support for new hardware.

So a decision was made to allow new driver support to ship in Solaris Update Releases.

But for Solaris to compete successfully against other Operating Systems, a gap of ca. 2 years between each Solaris Marketing Release was simply too long to wait for cool new software features, especially in fast developing areas such as the Desktop, Identity Management, etc.

So a decision was made to allow new features with a relatively low footprint in pre-existing code (i.e. with a low risk of introducing regressions in pre-existing functionality) to ship in Solaris Update Releases.  This is how Solaris 7, Solaris 8, and Solaris 9 Update Releases worked.

But pressure to release more significant cool feature enhancements such as ZFS, Containers (Zones), NewBoot (GRUB), LDoms (Hardware Vitualization for SPARC), etc., means that the scope of change in Solaris 10 Update releases is far higher than in preceding releases.

This has proved somewhat problematic from a patching perspective given that, as mentioned in my preceding posting, any change to pre-existing code, including feature changes, must be delivered as a patch, and that feature code and bug fix code to the same code area will be delivered in the same patch.

The inter-connectedness of cool new features such as Containers (Zones) and ZFS, and the pervasiveness of features such as NewBoot (GRUB), Trusted Extensions, and Secure By Default, have resulted in some complex Solaris 10 patch relationships and some large Kernel patches.

In particularly, patching a Zones environment on an early release of Solaris 10 can be problematic due to some deficiencies in the original Zones code and in the Solaris patch utilities.

For a customer on an early version of Solaris 10, such as Solaris 10 03/05, Solaris 10 1/06 (Update 1), or Solaris 10 6/06 (Update 2), there is a very significant amount of code change delivered, for example, in the current Kernel patch compared with the original Kernels delivered in these releases.

Patch dependencies, as explained in my earlier posting "Understanding Patches", ensure that the target system is in a consistent state once the patches have been successfully applied to the target system.

But on a Solaris 10 system where the scope of change from the current code level to the latest patch level is very large, the patch utilities struggled to keep the system in a consistent state during patching of a live boot environment.

A number of process and tool improvements, such as Solaris Live Upgrade and Deferred Activation Patching, have been implemented to address these issues which I'll cover in my next postings.