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 4/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.

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

The patch README file 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 (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 SAFEMODE parameter in their pkginfo file 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 patchadd command. Objects updated by using deferred activation patching will be activated on reboot of the system.

No, if a patch requires a reboot, you cannot avoid the reboot. Sooner or later you have to reboot to enable the changes that the patch introduced. However, you can choose from a couple of strategies to defer the reboot until a more convenient time.

• 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 lucreate command 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 patchadd -R command. The -R option enables you to specify an alternate root (/) file system location. The -R option is usually intended for use with diskless clients but can also be used to delay the reboot.