Solaris 10 8/07: Deferred Activation Patching

Starting with patches 119254-41 and 119255-41, the patchadd and patchrm patch installation utilities have been modified to change the way in which certain patches delivering features are handled. This modification affects the installation of these patches on any Solaris 10 release. These deferred-activation patches better handle the large scope of change delivered in feature patches such as kernel patches associated with Solaris 10 releases after the Solaris 10 3/05 release.

Deferred-activation patching uses the loopback file system (lofs) to ensure the stability of the running system. When a patch is applied to the running system, the lofs preserves stability during the patching process. These large kernel patches have always required a reboot, but now the required reboot activates the changes made by the lofs. The patch README provides instructions on which patches require a reboot.

If you are running non-global zones or have lofs disabled, consider these points when installing or removing deferred-activation patches:

• All non-global zones must be halted for this patch operation. You must halt the non-global zone before applying the patch.

• Deferred-activation patching requires the loopback file system (lofs). Systems running Sun Cluster 3.1 or Sun Cluster 3.2 are likely to have lofs turned off because of restrictions on HA-NFS functionality when lofs is enabled. Therefore, before a deferred-activation patch is installed, you must re-enable the loopback file system by removing or commenting out the following line in the /etc/system file:

  exclude:lofs

  Then reboot your system and install the patch. After you have completed the patch installation operation, restore or uncomment the same line from the /etc/system file. You must then reboot to resume normal operations.

Using Solaris Live Upgrade to manage patching can prevent the problems associated with patching a running system. Solaris Live Upgrade can reduce the amount of downtime involved in patching and limit risk by providing fallback capability if problems occur. You can patch an inactive boot environment while the system is still in production, and boot back to original boot environment (BE) if problems are discovered in the new BE. See Upgrading a System With Packages or Patches in Oracle Solaris 10 9/10 Installation Guide: Solaris Live Upgrade and Upgrade Planning.