Patching Solaris 10
By Gerry Haskins on Jan 04, 2008
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.