FAQ: Patching for the Solaris OS
Lynne Thompson, February 2008 (Updated February 2009)
This article provides answers to many questions regarding patching a system running the Solaris Operating System.
General Patching Questions
Patching in Single-User Mode or Multiuser Mode
Patches and Rebooting
Question: Why do I need to reboot after installing or removing certain patches?
READMEfile for some patches specifies that a reboot is required after the patch has been installed or removed. This request for a reboot might contain two reboot instructions:
- The first instruction is to “reboot after” patching to see the fix. This instruction has no time constraints, because this is just a reminder that some of the changes are not activated until a reboot occurs.
- The second instruction is to “reboot immediately” after patching.
If patching an active boot environment, a reboot is needed to activate certain objects that have been patched, such as the Kernel. After installation to an active boot environment, some patches specify in their README file that a reboot or reconfiguration reboot (
-r) is required.
Some of these patches specify that a reboot must occur immediately after the patch is installed on an active boot environment. The reboot is required because the active boot environment is in an inconsistent state if the target system is running a Kernel at a patch level below 120012-14. When the reboot is performed, the system is stabilized.
For example, a patch could deliver new kernel binaries and a new library. After the new kernel binaries are installed on the active boot environment, the kernel binaries are still inactive because they will not be loaded until the system is rebooted. The new library might contain interface or behavior changes that depend on the new kernel. But, the new library could be linked and invoked at any point after the library is installed in the file system. This can result in an inconsistent system state, which could potentially lead to serious problems.
Generally, you can complete patching operations before initiating the reboot, but normal operations should not be resumed until the reboot is performed. Some patches, such as 118855-36, require a reboot when applied to an active boot environment before further patches can be applied. The instruction is specified in the “Special Install Instructions” section of the patch
README. As an added safety mechanism, such patches typically contain code to prevent further patching until the reboot is performed.
Kernel patch 120012-14 is the first patch to utilize the “deferred activation patching” functionality. Deferred activation patching was introduced in the Solaris 10 08/07 release to ensure system consistency during patching of an active boot environment. Such patches set the
SAFEMODEparameter in their
pkginfofile or files. Deferred activation patching utilizes loopback mounts (lofs) to mask the patched objects until a reboot is performed. Deferred activation patching is designed to enable subsequent patches to be applied before the reboot is initiated. If any subsequent patch directly or indirectly requires a patch installed in deferred activation patching mode, the patch will also automatically be installed in deferred activation patching mode by the
patchaddcommand. Objects updated by using deferred activation patching will be activated on reboot of the system.
Question: Is there anything I can do to avoid or defer the required reboot?
- One method is to use Solaris Live Upgrade, which enables patches to be installed while you are in production. You can avoid single-user mode and use multiuser mode. Then you simply reboot into the patched environment at a more convenient time.
Note – Currently, Solaris Live Upgrade does not support Veritas encapsulated root (/) file systems very well. The root (
/) file system can be a Veritas Volume Manager volume (VxVM). If VxVM volumes are configured on your current system, the
lucreatecommand can create a new boot environment. When the data is copied to the new boot environment, the Veritas file system configuration is lost and a UFS file system is created on the new boot environment.
- Another approach with similar benefits to Solaris Live Upgrade is to use RAID-1 volumes (disk mirroring) with Solaris Volume Manager. In this scenario, you can split the mirror, mount the inactive root (
/) file system mirror, and apply the patches to the copy with the
-Roption enables you to specify an alternate root (
/) file system location. The
-Roption is usually intended for use with diskless clients but can also be used to delay the reboot.