Understanding Patches


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.

Patches 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.

Comments:

[Trackback] Bookmarked your post over at Blog Bookmarker.com!

Posted by advantageous on January 04, 2008 at 04:20 AM GMT #

Hello,

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.

Posted by guest on May 27, 2008 at 05:58 AM IST #

Hi!

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,

Gerry.

Posted by Gerry Haskins on May 27, 2008 at 08:28 AM IST #

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,
Mikhail.

Posted by Mikhail Kulinich on May 27, 2008 at 09:01 AM IST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

This blog is to inform customers about patching best practice, feature enhancements, and key issues. The views expressed on this blog are my own and do not necessarily reflect the views of Oracle. The Documents contained within this site may include statements about Oracle's product development plans. Many factors can materially affect these plans and the nature and timing of future product releases. Accordingly, this Information is provided to you solely for information only, is not a commitment to deliver any material code, or functionality, and SHOULD NOT BE RELIED UPON IN MAKING PURCHASING DECISIONS. The development, release, and timing of any features or functionality described remains at the sole discretion of Oracle. THIS INFORMATION MAY NOT BE INCORPORATED INTO ANY CONTRACTUAL AGREEMENT WITH ORACLE OR ITS SUBSIDIARIES OR AFFILIATES. ORACLE SPECIFICALLY DISCLAIMS ANY LIABILITY WITH RESPECT TO THIS INFORMATION. ~~~~~~~~~~~~ Gerry Haskins, Director, Software Lifecycle Engineer

Search

Categories
Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today