News, tips, partners, and perspectives for the Oracle Solaris operating system

Understanding Patches

Gerry Haskins
Director Security and Release Management

Scott McNealy hates the word patch.  It has negative connotations, like a cloth patch used to repair worn out clothing.  Scott prefers the term update as it's more positive, suggesting the provision of positive change, not just repairs.

I wholeheartedly agree with him as patches deliver positive change (feature enhancements, performance enhancements, hardware support, etc.) as well as bug fixes.  Also, many bug fixes delivered in patches address issues found during internal Sun testing rather than issues found by customers, and hence patches often provide proactive preventative change rather than just reactionary change.

Unfortunately, "update" is an overloaded term, as the periodic releases of the current Solaris[TM] OS are often referred to as Solaris Update Releases, such as Solaris 10 Update 4 (offical name, Solaris 10 8/07).  Solaris Update Releases are complete Solaris install images and are therefore quite different from patches which provide discreet change to be installed on top of an existing Solaris install image. 

To avoid confusion, I'll use the politically incorrect term patch in this blog.

Most of the information which follows is available on the new BigAdmin Patching Hub.  The information on the BigAdmin Patching Hub will be added to over time, so it should provide a useful resource to anyone involved in patching Sun software.

"Standard" Patches

This blog concentrates on "standard" patches for the Solaris platform.

Aside: The term Solaris patch is frequently used in documentation.  This is ambiguous, as it can mean either a patch specifically for the Solaris OS product itself, or it can mean any patch, including an application patch, which can be applied to a system running the Solaris OS.  Typically, such application patches behave the same as patches for Solaris itself and so most documentation on "Solaris patches" also applies to application patches for products such as Java Enterprise System, SunCluster, SunStudio, etc., for installation on the Solaris platform.

So, what is a "standard" patch for the Solaris platform ?

Almost all Sun software, and some 3rd party software, for the Solaris platform are delivered as Sun SVR4 packages.  For example, SUNWcsr and SUNWcsu.

A "standard" patch for the Solaris platform is a patch which provides updates to existing Sun SVR4 packages.  For further information on packages, see the Application Packaging Developer's Guide on docs.sun.com.  Note, the section on Patching Packages is out of date, as patches can and do deliver new features and functionality.

Patch Attributes 

"Standard" patches for the Solaris platform have the following attributes:

  • Most patches are delivered in sparse SVR4 package format.  Sparse, because such patches only redeliver the objects which have changed since the package was originally released.  The sparseness of a patch was advantageous when bandwidth and diskspace were expensive, but it's less of an issue now.  (Some application layer patches may redeliver the entire package
    contents but this is rarer and is usually where the patch is for a 3rd
    party or shareware product or products acquired through acquisitions
    where such behavior was the norm.)
  • A patch may patch one or more packages.
  • Patches are cumulative.  That is, revision -02 of a patch contains all the contents of revision -01, so applying the latest revision of a patch is sufficient to get all the changes to the objects contained in the patch.  There is no need to install revision -01 before installing revision -02.
  • At any point in time, there's only one "active" top-of-tree patch which patches a particular executable object.  Patch relationships specified in the pkginfo files ensure patches are applied/removed in the correct order to prevent regressions. There are several kinds of standard patch relationship:
    • A patch may specify a requirement on another patch (the SUNW_REQUIRES field in the pkginfo file(s) of a patch).  This is used where a patch has a hard code requirement on the contents of another patch.  This tells the patchadd utility that the specified patch(es) must be installed before this patch can be installed in order to preserve the consistency of the target system.  For example, a revision of the zoneadmd patch may depend on new
      functionality introduced in a particular Kernel patch.  In such a case, the Kernel patch needs to be installed before the zoneadmd patch is installed to ensure that the updated zoneadmd will function correctly.  The patch remove utility, patchrm, also uses this dependency information.  In the above example, patchrm will not allow the Kernel patch to be removed unless the zoneadmd patch which requires the Kernel patch is removed first.
    • A patch may also specify a "soft" or "conditional" requirement on another patch. 
      • A "soft" requirement is where other patches are required to deliver specific functionality such as a complete bug fix or new feature, but the system remains in a consistent state if the other patches are not installed.  Any "Soft" dependencies are specified in the Special Install Instructions section of the patch README file.  Such entries typically have the form "To get the complete fix for CR xxxxxx, please also install Patch yyyyyy-yy." or "To get the complete ZFS feature, please also install Patches aaaaaa-aa and bbbbbb-bb."
      • A "conditional" requirement is rarer, but can occur for example where an application layer patch can be applied to the same application on multiple versions of Solaris, e.g. Solaris 8 or Solaris 10, and has a hard code dependency on the OS.  For example, on rare occasions, an AppServer patch may require a Kernel patch for the specific version of Solaris.  Since there's no way to specify an "if Solaris 10, then SUNW_REQUIRE=127111-05, elif Solaris 8, then SUNW_REQUIRE=108528-16" dependency in the pkginfo SUNW_REQUIRES field, any such conditional dependencies are documented in the Special Install Instructions section of the patch README file.  Another possible conditional dependency is where a hardware driver patch may require specific hardware to be at a particular firmware level in order to function correctly.
    • A patch may specify that it obsoletes another patch (the SUNW_OBSOLETES field in the pkginfo file(s) of a patch). This indicates that the new patch supersedes the older patch and accumulates its contents.  No further revisions of the obsoleted patch will be created.  Accumulations typically occur where a code change introduces a two way code dependency between two patches.  In such cases, one of the patches is obsoleted and its contents accumulated into the other patch.
    • On rare occasions, a patch may specify that it's incompatible with another patch (the SUNW_INCOMPAT field in the pkginfo file(s) of a patch).  In such circumstances, the patchadd utility will not allow both patches to be applied to the same target system.  Incompatibilities are typically declared in non-standard Point Patches, which are effectively fixes made to a branch off the main code branch.  Such Point Patches are typically used to provide specific fixes to specific customers, in circumstances where the code change is considered inappropriate for inclusion in the main code branch, for example because it's considered too risky, too immature, or otherwise undesirable for the majority of customers.

The key attributes of a package from a patching perspective are the
package name, package version, and architecture (SPARC or x86).  These attributes are specified in each package's pkginfo file.

When patching, the Solaris patchadd utility checks whether the name, version, and architecture of the package(s) in a patch match the name, version, and architecture of the package(s) on the target system.  If they match, then the matching packages will be updated.  Each object in that package which is delivered in the patch will be updated. 

If a patch patches several packages and only some of them are present on the target system, only the packages which are present will be patched.  If, at a later date, the other packages are added to the target system, the patch will need to be reapplied in order to patch the new packages.  This is called incremental patching.

How an object is updated depends on its file type and associated Class Action Script, as specified in the pkgmap file in each package.  Type "f" (executable file) objects will typically simply be replaced and will typically have a Class Action Script of i.none associated with it.

If the default "save" option is used when patching, the
replaced objects will be archived (typically in
/var/sadm/pkg/<pkgname>/save/<patchid>/undo.Z).  This
enables the patch to be backed out at a later date and the original
files restored.  Such archiving is cumulative, allowing the previous patched state to be restored.

Special handling may be required for other file types, such as type "e" (editable files), for example, in cases where configuration files need to be updated.  Patching configuration files which contain a mixture of "system" data (i.e. data which should only be changed by Sun) and "user" data (i.e. data which can be safely altered by customers) can be problematic from a patching perspective.  For example, it may be risky to try to pattern match a "system" entry in the configuration file which should be modified or deleted as there may be a danger of accidentally pattern matching a "user" entry added by the customer.  In the worst case, the patch may simply either replace the configuration file, save off the old version, and ask the customer to manually merge the two versions, or else leave the configuration file alone, add the ".new" version alongside it, and ask the customer to manually merge the two versions.  This is clearly a less than ideal experience but is largely a property of poor configuration file design (often inherited from legacy or 3rd party code).

For more information on installing patches, see the How To page on the BigAdmin Patching Hub.

Patch Types

Sun patches typically have a 6-2 digit PatchID, such as
127111-05.  The first 6 digits are the base PatchID.  127111 is a Solaris 10 Kernel patch for SPARC.  The last 2 digits
are the revision number of the patch, starting at revision -01.  As
further changes are incorporated in the patch, the revision number is
incremented.  This PatchID format is used for almost all Sun patches,
including patches for Linux, IBM mainframes, HP-UX, Windows, etc., as
well as for patches for the Solaris platform.

for the Solaris platform start life as a "T-Patch" or Test Patch.  They are prefixed with the
letter "T", such as T127111-07.  T-Patches may be given to customers to
verify that they fix an issue.  T-Patches are also verified by the
engineers who coded the changes and tested by the Patch System Test
team.  See the Overview of Solaris[tm] Patch System Testing and Performance QA Testing for further details.

If appropriate, the contents of a T-Patch may be ported by an
OEM such as Fujitsu and the ported code is merged into the T-Patch. (This merging adds ported objects for OEM supported platforms such as Fujitsu servers, it does not change any objects for Sun supported platforms.)

Once a patch has been fully verified and tested, the "T" prefix is
removed and the patch is released to SunSolve.  Note: The "T-Patch" is
functionally identical to the patch which is eventually released.  No
material changes are allowed to a T-Patch, other than the addition of OEM ported code, if any.  If a serious issue is found with a T-Patch, it will
simply not be released.  This is why customers may notice gaps in the
revision numbers of released patches.  For example, 127111-04 was not
released due to an issue, CR 6627976, found during testing by Sun's Patch System Test team.

Even before a T-Patch is created, customers who are experiencing a problem may be provided with an IDR (Interim Diagnostic and Relief).  The IDR uses a patch-like structure, but it does not attempt to provide a final fix to an issue.  Rather, IDRs are used to help diagnose complex issues and provide customers with prototype solutions to test.  Once a fix has been identified, the process of creating a real patch will begin.  IDRs should be replaced with the real patch as soon as it becomes available as a T-Patch.

For an overview on the Life Cycle of a bug, IDR, and Patch, see A Bug's Lifecycle.

For further information on Patch Types and Dependencies, see the Overview of Patch Types and Dependencies on the BigAdmin Patching Hub.

For further information on IDRs, see the Interim Relief/Diagnostics page.

What's Next ? 

Now that I've covered the basics, my next posting will concentrate on the specific issues around patching Solaris 10, and the process and tool improvements which have been made to address them.

Join the discussion

Comments ( 4 )
  • advantageous Friday, January 4, 2008
    [Trackback] Bookmarked your post over at Blog Bookmarker.com!
  • guest Tuesday, May 27, 2008


    What are the order of the base PatchId?

    For i.e.,

    we have a patch 121017 for SunStudio 11. Is it true that next base PatchID for SS11 will be greater than 121017?

    Thank you.

  • Gerry Haskins Tuesday, May 27, 2008


    It's likely that the next base PatchID will be greater, but it's not guaranteed. The base PatchIDs have no significance. They are simply a reference tag.

    There's an internal Sun tool which assigns unique base PatchIDs. When a patch creator needs some new PatchIDs, they'll take a bunch of PatchIDs. They may keep some "nice" easy-to-remember PatchIDs in reserve to use for key patches such as the Kernel patch, but, in general, it'll simply be the next base PatchID in order.

    Best Wishes,


  • Mikhail Kulinich Tuesday, May 27, 2008

    Gerry, thank you for the fast answer.

    So, the next question (concerning SunStudio).

    In order to be sure that some PatchId have necessary improvements what the user should do to verify that?

    I mean that PatchId include some improvement which is necessary in development process.

    For the moment we use GNU software to verify env before building (i.e., autoconf/automake). We have test programs which return "true" or "false".

    But there are some cases where it cannot be done, so we need to check PatchId to be sure that SS satisfy our requirements during build.

    Are there any rules which we can use to automate this process?

    Thank you,


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.