I'd just like to make the following clear to customers:
Customers who install packages from one Update release (e.g. S10U6) on
a system installed with another release (e.g. S10U3) risk corrupting their system.
You must not install packages from one Update release onto a system installed with any other Update release.
The reason for this is that all available patches are pre-applied into
all packages for each Update release. Patches and packages have a
many-to-many relationship. That is, one patch can patch many
packages. One package can be patched by many patches.
If you install a package from an Update release onto a system installed
with a different Update release, you completely compromise future patch
dependency checking as you've introduced patch metadata from a later Update release. This is likely to lead to system corruption as
further patches are applied.
'patchadd' checks that dependencies are satisfied when installing a
patch. If 'patchadd' finds any installed package patched with a patch
which satisfies the dependency, it assumes the patch is applied to all
packages. This is done for performance reasons. Hence, if a package
from a later release is installed on the system, it's pre-applied
patches may fool subsequent 'patchadd' invocations into thinking that a hard code dependency
has been satisfied for all packages on the system when this is not the
case. The patch application will be allowed to continue, potentially
corrupting the system.
The converse is also true. If a package from an earlier Update is
applied to a system, the patch delta from that Update to the
Update installed on the system plus any additional patches installed on
the system would need to be applied to the package to avoid a mismatch
in software levels between the packages on this system, which could lead to incorrect patch dependency
resolution and hence to system corruption. Since this is difficult to
get right, adding packages from a different Update release onto an
installed system is, in general, unsupported.
There are two exceptions to the above rules, for Live Upgrade and encryption packages.
- Live Upgrade: If you are upgrading from Solaris 8 or Solaris 9 to Solaris 10, you need to apply the Live Upgrade packages from the Solaris 10 system to your Solaris 8 or Solaris 9 system. See document 1004881.1 on My Oracle Support (MOS), http://support.oracle.com, for details.
- SUNWcry\* encryption packages: These weren't included in the Solaris distribution prior to Solaris 10 8/07 (Update 4). For pre-Update4 systems, the recommended way to get these packages is to upgrade to a later Update release. For the reasons outlined above, while not recommended, a possible alternative is to download the packages from OTN, install them, and then re-apply any patches that patch the SUNWcry\* packages which you have already applied to the system (\*\*). Also, for the reasons outlined above, it is not recommended to apply the packages
from the media of a later Update release, as you would need to ensure that all the other packages installed on the system are patched to the same or higher
patch level (e.g. by installing the appropriate Solaris Update Patch Bundle available from My Oracle Support, http://support.oracle.com)
to avoid completely compromising future patch dependency checking on the system.
\*\* A way to check which patches need to be re-applied in this scenario is as follows:
egrep -i "PKG=SUNWcryr|PKG=SUNWcry" \*/log|cut -f1 -d /|sort -u
# cd /var/sadm/patch
# egrep -i "PKG=SUNWcryr|PKG=SUNWcry" \*/log|cut -f1 -d /|sort -u
The above example is on a system installed with Soalris 10 11/06 (Update 3). The user would need to re-apply the patches listed above and be extremely careful to ensure they are applied in the correct dependency order as 'patchadd' will not be able to ensure the correct dependency order as it's dependency checking remains compromised until the added packages are brought up to the same patch level.
Please note that if a package from the same Update is applied to a system, then any additional patches already installed on the system
that patch the added package must be re-applied to bring that
package up to the same software level as the rest of the system. This
is called "incremental patching". This is supported, but care must be
taken. The easiest way to do this is to reapply all patches installed
on the system (as listed by 'patchadd -p'). This will bring the added
package(s) up to the same software level as the rest of the system. Again, you need to be extremely careful to ensure they are applied in the correct dependency
order as 'patchadd' will not be able to ensure the correct dependency
order as it's dependency checking remains compromised until the added
packages are brought up to the same patch level as the rest of the system.
Director, Software Patch Services