Solaris Deferred Activation Patching (DAP)

DAP was initially delivered in the Solaris 10 patch utility patch 119254-42 for SPARC and 119255-42 for x86 to ensure system consistency during patching of an active boot environment.

Problems with Patching a Live Boot environment

The problem with patching a live boot environment:

• 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 will only be activated when the system is rebooted.

The Inconsistent State Problem

Problems can occur where the scope of the change applied is very large compared to that which is running on the live boot environment.

• New objects that are invoked may be incompatible with the old objects running in memory. 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, because the patch utilities need to invoke the zones utilities during patching to patch the non-global zones.

The Issue of Complex Patch Scripting and the Initial Solution

Complex patch scripting was required for kernel patches during the patch installation process to avoid the inconsistency issues between the objects the patch was delivering and the running system.

Sun introduced a solution to the patching issue that no longer required complex patch scripting.

• Loopback file system mounts, or LOFS, were used to overlay the patched objects with the original versions that were present on the system.
• The system remained in a consistent state during the application of the patch.
• A forced reboot was required before any further operation could be performed, including the application of any other patches.

The Deferred Activation Patching Solution

• The loopback file system, or LOFS, is used to ensure the stability of the running system.
• The LOFS preserves stability during the patching process.
• The required reboot activates the changes made by the LOFS.

Deferred-Activation Patches

• Only a limited number of patches need to be designated as a deferred-activation patch.
• Typically a deferred-activation patch is a kernel patch associated with a Solaris 10 Update release.
• A deferred-activation patch has the variable SUNW_PATCH_SAFE_MODE set to "true" in the pkginfo file.

Installing Non Deferred-Activation Patches

Patches not designated as deferred-activation patches continue to install as before.

Note: A reboot is required after installing patches 118833-36 (SPARC) / 118855-36 (x86) to the live boot environment before other patches can be installed.

Note: The only other circumstance where a reboot is required before further patching can be performed is for x86, where a potential inconsistency exists between kernel patches below 118844-14 running in memory and libc changes delivered in patch 121208-02 and -03, and 118855-xx which obsoletes it. Code in the scripts of these patches ensures that a later kernel patch, for example, 118844-20, must be active before these patches can be applied.

How Deferred Activation Patching Works

Deferred Activation Patching and the Patch Utilities Patch

It is important to have the latest patch utilities patches installed before installing one of the deferred-activation kernel patches.

Deferred Activation Patching was initially delivered in the Solaris 10 patch utility patch 119254-42 (SPARC) / 119255-42 (x86).

• In this patch utility patch, the patch installation utilities, patchadd and patchrm, have been modified to change the way that certain patches delivering features are handled.
• The patch utilities patches address bugs in the Deferred Activation Patching feature and provide bug fixes and feature enhancements to other features of the patch utilities.

The Deferred Activation Patching Process

To apply a deferred-activation patch:

1. Download the patch.
2. Unzip the patch.
3. Read the README file.
   Note: Pay special attention to the "Installation Requirements" and "Special Install Instructions" sections.
4. Run the patchadd command.
   • The deferred-activation patch is applied using Deferred Activation Patching.
   • Subsequent patches that require the deferred-activation patch are automatically installed in Deferred Activation Patching mode.
5. Reboot the system to activate the patches.

Difference Between Deferred Activation Patching and Solaris Live Upgrade

Initial Comparison of Deferred Activation Patching and Solaris Live Upgrade

Deferred Activation Patching is performed on the active primary boot environment.

Solaris Live Upgrade is used on an inactive alternate boot environment.

Deferred Activation Patching and the Issues with Applying Patches to a Live Boot Environment

Issues with Patching a Live Boot Environment

• The problems with the system entering into an inconsistent state during patching can only occur when patching a live boot environment.
• Patching a live boot environment takes time and does not offer a fallback option.

Advantages of Using Solaris Live Upgrade to Apply Patches

Advantages of Using Solaris Live Upgrade

• Using Solaris Live Upgrade dramatically reduces the risk and downtime associated with patching.
  Note: Patches may contain Special Install Instructions in their README files that users must follow when patching a live boot environment to avoid issues. Most of these do not apply to patching an alternate (inactive) boot environment. Therefore, Solaris Live Upgrade reduces the number of manual steps needed to maintain a system, thereby reducing maintenance time and costs.
• The inconsistency issues do not apply when patching an alternate boot environment because there is no interaction between the objects being patched and the processes running in memory.
• All that is required to switch the alternate boot environment into the primary boot environment is a single reboot.
• If a problem arises with the new boot environment, you can fall back into the old boot environment to enable production to resume and resolve the issues with the alternate boot environment later <?ul>