Deferred Activation Patching

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.


Hi Gerry,

Long time reader, first time commenter.

I recently had a nasty problem when we tried to apply 137137-09 on to a system running VxVM with root disk encapsulation and the nologging option set in vfstab. This was required due to a specific bug in VxVM. Each time we applied the patch where zones were involved we would end up with a corrupted / FS. After 3 weeks of debugging our friendly Sun Services contact told us that this is a known bug (6660374) and has been around since the first DAP patch 120011-14. The bug tells us that DAP does not work if you have UFS logging disabled. The work around was simple, enable logging for the period of the patchadd. It would be so useful if Sun would be so kind as to do at least one of the following:

1) Make the bug public viewable
2) Document it in a README for the DAP patches
3) Tell the world DAP does not work with without UFS logging on a bigadmin or some other place.

Any of the above would have saved us 3 weeks of our lives.



Posted by Stephen Myles on August 17, 2009 at 07:51 AM IST #

So as of veritas Vm 4.2 loggign is supported.
please see

which provide list of patches for pre 4.2 that fix this issue, at which point logging should be enabled and left enabled.

running with ufs logging disabled is strongly discouraged, as you have seen it provides a lot more reliability.

I will add a note to the DAP patches that ufs logging disabled is not supported in a system that has non-global zones.

Posted by Enda O'Connor on August 20, 2009 at 09:15 AM IST #

Post a Comment:
  • HTML Syntax: NOT allowed

This blog is to inform customers about patching best practice, feature enhancements, and key issues. The views expressed on this blog are my own and do not necessarily reflect the views of Oracle. The Documents contained within this site may include statements about Oracle's product development plans. Many factors can materially affect these plans and the nature and timing of future product releases. Accordingly, this Information is provided to you solely for information only, is not a commitment to deliver any material code, or functionality, and SHOULD NOT BE RELIED UPON IN MAKING PURCHASING DECISIONS. The development, release, and timing of any features or functionality described remains at the sole discretion of Oracle. THIS INFORMATION MAY NOT BE INCORPORATED INTO ANY CONTRACTUAL AGREEMENT WITH ORACLE OR ITS SUBSIDIARIES OR AFFILIATES. ORACLE SPECIFICALLY DISCLAIMS ANY LIABILITY WITH RESPECT TO THIS INFORMATION. ~~~~~~~~~~~~ Gerry Haskins, Director, Software Lifecycle Engineer


« June 2016