This document provides an overview of patch types. Also, this document describes the
basic interrelationships between patches.
Definition of a Patch
A patch is an accumulation of fixes to a known problem or
to a potential problem within the operating system or other supported software. A
patch can also provide a new feature or an enhancement to a particular
software release. A patch consists of files and directories that replace or update
existing files and directories.
Most Solaris patches are delivered as a collection of sparse SVR4 packages. A
patch can contain one or more sparse packages. A sparse package
contains only those objects that have been altered since Solaris first delivered the package
version in a distribution. When code changes are provided with sparse packages, these
packages enable small patches rather than redistributing complete, but large, packages. Sparse packages
minimize the changes made to the customer's environment.
Each patch is identified by a patch identification number (patch ID). The patch
ID consists of a six-digit base identifier and a two-digit revision number of
the form xxxxxx-yy.
Patches are cumulative. Later revisions contain all of the functionality delivered in previous
revisions. For example, patch 123456-02 contains all the functionality of patch 123456-01 plus
the new bug fixes or features that have been added in Revision 02.
The changes are described in the patch README file.
Overview of Patch Types
This section describes the specific types of patches.
Table 1 Patch Types
Patch Type
Description
Kernel patch (formerly known
as Kernel Update [KU] patch)
A generally-available standard patch. This patch is important
because of the scope of change affecting a system. A Kernel patch
changes the Solaris kernel and related core Solaris functionality. A reboot is required
to activate the new Kernel version.
Temporary patch (T-patch)
A patch that has been built
and submitted for release but has not completed the full test and verification
process.
Before being officially released, Solaris patches are structurally audited, functionally verified, and subjected
to a system test process. Testing occurs when patches are in the “T-patch”
state. After successfully completing the test process, the patches are officially released.
For an overview of Sun's patch test coverage, see patch test.
A T-patch might be
made available to a customer involved in an active escalation to verify that
the patch fixes the customer's problem. This type of patch is identified
by a leading “T” in the patch ID, for example, T108528-14. The words
“(Preliminary Patch - Not Yet Released)” appear on the first line of the
patch README file. After the patch has been tested and verified, the
T-patch designation is removed, and the patch is released.
Note - If you have a T-patch
installed and then find that the patch is released at the same
revision, there is no need to remove the T-patch and then install
the released version. The released version and the T-patch are the same
except for the README file.
Security T-patches
The Security T-Patches section of the SunSolve
site provides early access to patches that address security issues. See the
Security T-Patch download section.
These patches are still in the T-patch stage, which means they have not
completed the verification and patch testing process. The installation of Security T-patches is
at the user's discretion and risk. Information about the issues addressed by Security
T-patches and possible workarounds is available through the Free Security
Sun Alert data collection. See the Sun Security Coordination Team page.
Rejuvenated patch
Patches that become overly
large or complex sometimes follow a process of “rejuvenation.” The rejuvenation process provides
patches that incrementally install complex new functionality in relative safety. When a patch becomes
a rejuvenated patch, no more revisions of the patch are created. Instead, further
changes to the rejuvenated patch are delivered in a series of new patch
IDs. These new patches depend upon and require the rejuvenated patch. If one
of the new patches becomes complex over time, that patch could become a
rejuvenated patch. For example, the Kernel patch is rejuvenated when needed.
The advantage of
this process is that although a customer must install the complex patch once,
future patches are much simpler to install.
A custom patch. This patch is provided to customers
as a response to a specific problem encountered by that customer. Point patches
are only appropriate for the customers for whom the patches have been delivered.
These patches are typically created for one customer, because the majority of customers would
consider the “fix” worse than the issue the fix is addressing. These patches
are created on a branch of the Solaris source code base and are
not folded back into the main source base.
Access to a point patch
is restricted and should only be installed after consultation with Sun support personnel.
Restricted
patch (R-patch)
A rare patch that has a special characteristic. An R-patch
locks the package modified. This lock prevents subsequent modification of the package by other
patches.
R-patches are used in circumstance similar to point patches. Like a point patch,
an R-patch is only appropriate for the customer for whom the patches have
been delivered. These patches are created on a branch of the Solaris source
code base and are not folded back into the main source base.
Before
the “official” standard patch can be applied, an R-patch must be manually removed.
Interim
Diagnostic Relief (IDR)
An IDR provides software to help diagnose a customer issue,
or provide preliminary, temporary relief for an issue. An IDR is provided in
a patch format similar to an R-patch, but because an IDR does not
provide a final fix to the issue, an IDR is not a substitute
for an actual patch. The official patch or patches should replace the IDR
as soon as practical.
A patch that fixes a public security issue. This patch is a
type of IDR. An ISR is an early stage fix that provides protection
to a security vulnerability that is publicly known. An ISR has not completed
the review, verification, and testing processes. The installation of an ISR is at
the user's discretion and risk. An ISR is available on the Security T-Patch download section on
SunSolve. Information about the issues addressed by an ISR and possible workarounds is
available through the Free Security Sun Alert data collection. See the Sun Security Coordination Team page.
Nonstandard
patch
A patch that cannot be installed by using the patchadd command. A nonstandard
patch is not delivered in package format. This patch must be installed according
to the “Special Install Instructions” specified in the patch README file. A nonstandard
patch typically delivers firmware or application software fixes.
Withdrawn patch
If a released patch is
found to cause serious issues, the patch is removed from SunSolve.
The patch is no longer available for download.
The README remains on SunSolve. The README is changed to state that the patch is withdrawn and a brief statement is added about the problem and why the patch was removed.
A Sun Alert is released to notify customers about the withdrawn patch issue. The Sun Alert specifies any actions that should be taken by customers who have the withdrawn patch installed on their system.
The Sun Alert appears in the list of recently published Sun Alerts. See Recent Sun Alerts.
Interactive patches
A patch
that requires user interaction in order to be installed. The patch must be
installed according to the Special Install Instructions specified in the patch README file.
Update
releases and script patches
Sun periodically releases updates to the current version of
the Solaris distribution. These releases are sometimes known as an “Update” release. An
Update release is a complete distribution and is named with a date designation,
for example, Solaris 10 6/06.
An Update release consists of all the
packages that made up the original release, such as Solaris 10 3/05, with
all accumulated patches pre-applied and includes any new features that are qualified for
inclusion.
The process of pre-applying patches involves some patches that do not get released.
Therefore, a system with an Update release installed appears to have some patches
applied that cannot be found on SunSolve. These patches are called script patches.
Script patches do not deliver bug fixes or new features, but deliver fixes
that are a result of issues with the creation of the image. As
a result, script patches are not made available for customers, because they are
not required outside of creating the Update release.
Patch Characteristics
The following sections provide basic information about patch characteristics.
Keywords in the README File
Keywords are provided to enable users to identify which patches might be applicable
to their environment. The most important keyword is “Security.” Security designates that the
patch includes a security fix and therefore should be considered with greater urgency.
Other keywords might include the affected subsystem, hardware platform, or user commands.
Patch Metadata
Patches have associated metadata that describes attributes of the patch. Metadata includes special
handling requirements such as “reboot after installation” or “single-user mode installation required.” These attributes
are translated into text in the README file, which should be read.
The Solaris patch utilities also utilize the metadata contained in the pkginfo
and pkgmap files.
Patch Metadata for Non-Global Zones
Patches contain Solaris Zones specific metadata to ensure the correct patching of a
Zones environment. Detailed information can be found in the following references:
The functionality delivered in a patch, either bug fixes or new features, might
have interrelationships with the functionality delivered in other patches.
These interrelationships are determined by three fields in the package's pkginfo file:
The SUNW_REQUIRES field identifies patch dependencies. These prerequisite patches must be installed before this patch can be installed.
The SUNW_OBSOLETES field identifies patches whose contents have been accumulated into this patch. This new patch obsoletes the original patches.
The SUNW_INCOMPAT field identifies patches that are incompatible with this patch, and therefore cannot be installed on the same system.
These fields are used by the Solaris patchadd and patchrm commands to
automatically ensure the consistency of the target system that is being patched. These
fields are also translated into human readable form in the patch README file.
SUNW_REQUIRES Field for Patch Dependencies
The SUNW_REQUIRES identifies patch dependencies. The functionality delivered in a patch might have
a code dependency on the changes or functionality that is delivered in other
patches. Therefore, one patch requires one or more other patches to function correctly.
If a patch depends on one or more patches, the patch specifies the
required patches in the SUNW_REQUIRES field in the pkginfo file in the patch's packages.
This information is also be reflected in the README file. Such prerequisite
patches must be installed before this patch can be installed.
The dependency requirement can only work one way. If Patch A requires Patch
B, Patch B cannot require Patch A. Because patches are cumulative, if
Patch A-01 requires Patch B-01, any revision of Patch B greater than
or equal to -01 also satisfies the requirement.
If other types of dependencies exist, they are specified in the patch README
file and can include the following:
Conditional dependencies indicate that a hard-coded patch dependency that occurs only under specific conditions. For example, only if CDE 1.3 is installed on the target system.
Soft dependencies indicate that other patches are required to completely deliver a particular bug fix or feature, but the system remains in a consistent state without the other patches.
SUNW_OBSOLETES Field for Patch Accumulation and Obsolescence
The SUNW_OBSOLETES field identifies patch accumulation and obsolescence. Sometimes bug fixes or new
features cause two or more existing patches to become closely intertwined. For example,
a bidirectional, hard-code dependency might exist between two patches. In such cases,
it might be necessary to accumulate the functionality of two or more patches
into one patch, thereby rendering the other patch or patches obsolete. The
patch into which the other patch's functionality is accumulated specifies the patch ID
or IDs of the patch or patches that it has obsoleted. This information
is in the SUNW_OBSOLETES field in the pkginfo files delivered in the patch's
sparse packages. This declaration is called explicit obsolescence.
The patch accumulation can only work one way. That is, if Patch
A accumulates Patch B, Patch A now contains all of Patch B's functionality.
Patch B is now obsolete. No further revision of Patch B will be
generated.
Due to the cumulation of patches, a later revision of a patch
“implicitly” obsoletes earlier revisions of the same patch. Patches that are implicitly obsoleted are
not flagged in the SUNW_OBSOLETES field. For example, Patch A-Revision xx does not
need to explicitly obsolete Patch A-Revision x-1 with a SUNW_OBSOLETES entry in the
pkginfo file.
Note - For Solaris 10 and Solaris 10 releases (after August 2007), a patch might
be released that contains no new changes. This patch might state that it
obsoletes another patch that was released some months earlier. This is a consequence
of the Solaris Update patch creation process. If you have the obsoleted patch
installed, and the new patch does not list any new changes, you do
not need to install this new patch.
For example, the Solaris 10 timezones patch 122032-05 was obsoleted by patch 125378-02. If
you already have 122032-05 installed, there is no need to install 125378-02, because
patch 125378-02 does not deliver any new changes.
SUNW_INCOMPAT Field for Incompatibility
Occasionally, two or more patches are incompatible with one another. Incompatibility is frequently
defined in point patches and IDRs. Incompatibility is rarely defined in regular patches.
An incompatibility is specified in the SUNW_INCOMPAT field in the pkginfo file
in the sparse package of one or both of the patches.
Patch incompatibility is two way. If Patch A or Patch B specifies
an incompatibility with the other patch, only one of the patches can be
installed on the target system. For example, if Patch A is already installed
on the target system and Patch B is incompatible with it, the patch
install utility patchadd will not allow Patch B to be installed. If
Patch B must be installed, Patch A must first be removed.
Both patches or an incompatible pairing do not have to define the
incompatibility. Typically, a point patch or an IDR defines an incompatibility, because these types
of patches are from nonstandard code branches.
Where to Find More Information About Patching
Table 2 Patching References
Description
Information
The Patching documentation hub provides many
other FAQs, procedures, and general information about patching the Solaris OS, as well
as links to support.
With the Solaris 10 1/06 release, Sun includes a new
patch management tool, Sun Connection. This tool analyzes your system and then applies
the appropriate patches.
Print-friendly Version
