FAQ: Patching for the Solaris OS

The Solaris Operating System (OS) software is delivered and installed with SVR4 packages. Packages contain one or more installable files and package-specific configuration information. The package-specific information defines the attributes of those objects. This information also describes how and where the packages should be installed. The package usually also contains preinstallation and postinstallation scripts to help ensure that the files are delivered correctly.

A patch adds, updates, or deletes one or more of those files on your system by updating the installed packages. The patch itself is physically composed of the following:

• Sparse packages that are a minimalist version of a regular package. A sparse package delivers only the files being updated.

• Class action scripts that define a set of actions to be executed during the installation or removal of a package or patch.

• Other scripts such as the following:

  • Postinstallation and preinstallation scripts.

  • Scripts that undo the patch when the patchrm command is used. These scripts are copied onto the system's patch undo area.

  • Prepatch, postpatch, and prebackout scripts, depending on the patch being installed. The postbackout and prebackout scripts are copied into the /var/sadm/patch/patch-id directory and are run on the patchrm command.

For more information, see Overview of Patch Types and Dependencies. See also, Solaris System Administration: Basic Administration.

Yes, you can patch any Solaris 10 release with Solaris 10 patches.

Each Marketing release has one set of patches. For example, the Solaris 8 Marketing release has a set of Solaris 8 patches, a Solaris 10 release has a set of Solaris 10 patches, and so on.

The set of patches for each release includes all the releases within a Marketing release. For example, the Solaris 10 3/05 release is the first Marketing release for the Solaris 10 release. Following this release are a set of releases such as Solaris 10 1/06, Solaris 10 6/06, Solaris 10 8/07, and so on. The set of patches is applicable to all of these Solaris 10 releases. The same Solaris 10 patch can be applied to the Solaris 10 3/05 release, the Solaris 10 1/06 release, Solaris 10 6/06 release, and so on.

The releases following the Marketing release, such as Solaris 10 1/06, contain new features and patches that are preapplied. Each of these releases has all the patches preapplied that were available when that release was built. These preapplied patches cannot be removed. To display a list of patches currently applied, you can continue to use the patchadd command with the -p option or the showrev command with the -p option.

You cannot patch across Solaris Marketing release boundaries. For example, you cannot apply a Solaris 10 patch to a Solaris 9 release.

Some customers want to upgrade by installing all the patches released since the release was initially installed on their system. Patches released after the general availability of a release, such as the Solaris 10 1/06 release, contain both features and bug fixes delivered in the Solaris 10 1/06 release.

The answer is no. You can obtain a portion of a later release with subsequent patches, but you have no guarantee of updating the entire release.

A Solaris release, such as Solaris 10 6/06, contains patches to existing code and new packages. Any changes to preexisting code, including feature changes, are delivered in patches. If you patch to the same or higher patch level as a release, such as the Solaris 10 6/06 release, you obtain all the bug fixes for preexisting code contained in that release. You might also obtain some new features that are fully self-contained in patches.

While patches can contain new objects, large features typically also introduce new packages. These new packages are typically only available by installing or upgrading to the Solaris release image. Therefore, you cannot patch to the identical feature functionality as a release, such as the Solaris 10 6/06 release.

Installation times vary depending on several issues:

• Current recommended patch clusters can be very large and certain patches, such as the kernel patch, have a tendency to grow. For example, the Solaris 10 11/06 kernel patch, 118833-36, is approximately 136 Mbytes. The Solaris 10 8/07 kernel patch, 120011-10, is approximately 166 Mbytes. Large patches are slower to install.

• On systems that have non-global zones, the patch operation is currently carried out sequentially for each zone, one at a time.

You can avoid system downtime by using Solaris Live Upgrade. Solaris Live Upgrade enables patches to be installed while you are in production. You can also avoid single-user mode and use multiuser mode. You create a copy of the currently running system and patch the copy. Then you simply reboot into the patched environment at a convenient time. You can fall back to the original boot environment if needed. For more information about Solaris Live Upgrade, see Solaris 10 8/07 Installation Guide: Solaris Live Upgrade and Upgrade Planning.

Historically, the intention has always been to avoid making large and unwieldy patches by providing one patch per software "component.” For example, you might have a UFS patch for the UFS subsystem or a libc patch for the libc library.

These boundaries fade when bug fixes, and especially feature changes, touch code in different subsystems of the operating system. As a result, dependencies can arise that force one or more patches together, so that the change is delivered coherently.

Sometimes the dependency is "soft” and Sun can keep the patches separate and simply note in the patch README that multiple patches might be required to deliver a complete fix. A soft dependency is an incomplete fix or feature, but being incomplete does not lead to an inconsistent system state.

Note - For more information about patch dependencies (including hard and soft dependencies), seeOverview of Patch Types and Dependencies.

This question can be answered in several ways.

• The first answer is that trying to avoid having large patches leads to a larger number of smaller patches.

• Also, a large number of products are in the Sun software portfolio and some, Solaris in particular, can be targeted by a number of different patches that address different subsystems within the product.

In the past, Sun charged for software releases and gave patches away for free. Now, Sun gives the software releases away and charges for most patches. This new model is similar to the model used by some Linux vendors.

However, Security and device driver patches are free. These patches are available for the Solaris 8, 9, and 10 releases. To access the patch lists, follow the steps. To find a free patch, locate the patch ID in the patch list that does not show a key icon. Those patches that cost show the key icon.

1. On the SunSolve site, find the "Download Product Specific Patches” section at the bottom of the page.

2. Find the "Software, Solaris” section and Select OS drop-down menu.

3. From the drop-down menu, obtain the correct patch list by selecting the release and platform type.

You can purchase a support contract to obtain patches for a fee. Or, if you upgrade to the next Solaris 10 release, such as the Solaris 10 5/08 release, this release contains all the available bug fixes.

If you are running the Solaris 8, 9, or 10 OS, for more information about patch policy changes, see Sun Software Update (Patch) Access Policy.

You cannot patch Solaris 10 from Solaris 8 or 9 as the version of 'patchadd' in Solaris 8 and 9 is totally unaware of how to handle Zones and other Solaris 10 specific features.

If using Live Upgrade to upgrade an inactive boot environment from Solaris 8 or 9 to Solaris 10, you must activate and boot into the Solaris 10 boot environment before patching it. For example, activate and boot into the Solaris 10 boot environment, and either patch the live boot environment or create another inactive boot environment, and then apply patches to the inactive boot environment.

The patch README file specifies which patches should be installed in single-user mode. Although the patch tools do not force you to use single-user mode, the patch README should be respected. Patching in single-user mode helps ensure that the system is quiesced. Minimizing activity on the system is important. Some patches update components on the system that are commonly used. Using single-user mode preserves the stability of the system and reduces the chances of these components being used while they are being updated.

Using single-user mode is critical for system patches like the kernel patch. If you apply a kernel patch in multiuser mode, you significantly increase your risk of the system experiencing an inconsistent state.

If single-user mode was required for applying the patch, then yes, you should use single-user mode. The patch properties apply to both installing and backing out patches. Changes being made to the system are equally significant, irrespective of the direction in which they're being made, for example, installing instead of backing out.

Using the init S command does not quiesce the system as much as possible for patches that specify single-user mode installation, but this command can be safely used. Using the init 0 command and then booting to single-user mode provides a more quiesced system because fewer daemons are running. But, this command requires a reboot. You can safely use either command.

This is a known problem and is usually due to the non-global zone file systems not being mounted in single-user mode. Here is an example of an error message you might see:

Preparing checklist for non-global zone check...
Checking non-global zones...
ERROR: unable to boot zone: problem running on zone :
error 1 zoneadm: zone 'myzone': can't stat /zones/full1/root: No such file or directory
zoneadm: zone 'myzone': call to zoneadmd failed
Can not boot non-global zone myzone

Workaround: To ensure that all local file systems are mounted, run mountall -l prior to installing the patches.

Or, you can install the following patches that fix the problem:

• For SPARC based systems, 119254 revision higher than 45

• For x86 based systems, 119255 revision higher than 45