Deferred Activation Patching
By Gerry Haskins-Oracle on Jan 04, 2008
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.