Chapter 3 Software Management: Packages 47
3.1 Managing Software Packages 47
3.2 What Is a Package? 47
3.2.1 SVR4 Package Content 48
3.2.2 Package Naming Conventions 49
3.3 Tools for Managing Software Packages 49
3.4 Installing or Removing a Software Package with the
pkgadd or pkgrm Command 50
3.5 Using Package Commands to Manage Software Packages 51
3.5.1 How to Install Packages with the pkgadd
Command 51
3.5.2 Adding Frequently Installed Packages to a Spool
Directory 54
3.5.3 Removing Software Packages 56
Chapter 4 Software Management: Patches 59
4.1 Managing Software with Patches 59
4.2 What Is a Patch? 59
4.2.1 Patch Content 60
4.2.2 Patch Numbering 61
From the Library of Daniel Johnson
Contents vii
4.3 Patch Management Best Practices 61
4.3.1 Proactive Patch Management Strategy 62
4.3.2 Reactive Patch Management Strategy 68
4.3.3 Security Patch Management Strategy 70
4.3.4 Proactive Patching When Installing a New System 71
4.3.5 Identifying Patches for Proactive Patching and
Accessing Patches 73
4.4 Example of Using Solaris Live Upgrade to
Install Patches 75
4.4.1 Overview of Patching with Solaris Live Upgrade 75
4.4.2 Planning for Using Solaris Live Upgrade 77
4.4.3 How to Apply a Patch When Using Solaris Live
Upgrade for the Solaris 10 8/07 Release 79
4.5 Patch Automation Tools 86
4.6 Overview of Patch Types 88
4.7 Patch README Special Instructions 93
4.7.1 When to Patch in Single-User Mode 93
4.7.2 When to Reboot After Applying or Removing a Patch 94
4.7.3 Patch Metadata for Non-Global Zones 95
4.8 Patch Dependencies (Interrelationships) 96
4.8.1 SUNW_REQUIRES Field for Patch Dependencies 96
4.8.2 SUNW_OBSOLETES Field for Patch Accumulation
and Obsolescence 97
4.8.3 SUNW_INCOMPAT Field for Incompatibility 97
Software Management:
Packages
This chapter describes packages and package tools and includes step-by-step
procedures for installing and removing packages.
3.1 Managing Software Packages
Software management involves installing or removing software products. Sun and
its third-party independent software vendors (ISVs) deliver software as a collection
of one or more packages. The following sections describe packages and provide
step-by-step procedures for adding and removing packages.
Patches are generally delivered as a set of sparse packages. Sparse packages are
a minimalist version of a regular package. See Chapter 4, “Software Management:
Patches,” for information about how to apply patches and patching best practices.
3.2 What Is a Package?
The Solaris Operating System (Solaris OS) is delivered and installed with SVR4
packages. A package is a collection of files and directories in a defined format. This
format conforms to the application binary interface (ABI), which is a supplement
to the System V Interface Definition. The Solaris OS provides a set of utilities that
interpret this format and provide the means to install a package, to remove a
package, and to verify a package installation.
From the Library of Daniel Johnson
48 Chapter 3 _ Software Management: Packages
3.2.1 SVR4 Package Content
A package consists of the following:
_ Package objects—These are the files to be installed.
_ Control files—These files determine the way the application needs to be
installed. These files are divided into information files and installation scripts.
The structure of a package consists of the following:
_ Required components:
– Package objects—Executable or data files, directories, named pipes,
links, and devices.
– pkginfo file—A required package information file defining parameter values
such as the package abbreviation, full package name, and package
architecture.
– pkgmap file—A required package information file that lists the components
of the package with the location, attributes, and file type for each component.
_ Optional components:
– compver file—Defines previous versions of the package that are compatible
with this version.
– depend file—Indicates other packages that this package depends upon.
– space file—Defines disk space requirements for the target environment.
– copyright file—Defines the text for a copyright notice displayed at the
time of package installation.
_ Optional installation scripts—These scripts perform customized actions during
the installation of the package. Different installation scripts include:
– request scripts—Request input from the administrator who is installing
the package.
– checkinstall scripts—Perform special file system verification.
– procedure scripts—Define actions that occur at particular points during
package installation and removal. There are four procedure scripts that
you can create with these predefined names: preinstall, postinstall,
preremove, and postremove.
– class action scripts—Define a set of actions to be performed on a group
of objects.
From the Library of Daniel Johnson
3.3 TOOLS FOR MANAGING SOFTWARE PACKAGES 49
3.2.2 Package Naming Conventions
Sun packages always begin with the prefix SUNW, as in SUNWaccr, SUNWadmap, and
SUNWcsu. Third-party packages usually begin with a prefix that corresponds to the
company’s stock symbol.
3.3 Tools for Managing Software Packages
You can use either a graphical user interface (GUI) or command line tools to install
or remove packages. See Table 3.1 for a list of these tools.
For more information about these tools, see System Administration Guide: Basic
Administration or the specific man pages listed in the table. For the guide and
man pages, see http://docs.sun.com.
Table 3.1 Tools or Commands for Managing Software Packages
Tool or
Command
Description Man Page Installed by
Default?
installer Starts the Solaris installation GUI so that
you can add software from the Solaris
media. The installer must be available
either locally or remotely. Also, this GUI can
determine what software is already
installed on a system.
installer
(1M)
This tool must
be installed
from the
installation CD
or DVD.
prodreg
(GUI)
Starts an installer so that you can add,
remove, or display software product information.
Use the Solaris Product Registry to
remove or display information about software
products that were originally installed
by using the Solaris installation GUI or the
Solaris pkgadd command.
prodreg
(1M)
This tool is
installed by
default.
Solaris
Product
Registry
prodreg
Viewer
commandline
interface
(CLI)
Use the prodreg command to remove or
display information about software products
that were originally installed by using
the Solaris installation GUI or the Solaris
pkgadd command.
prodreg
(1M)
This tool is
installed by
default.
continues
From the Library of Daniel Johnson
50 Chapter 3 _ Software Management: Packages
3.4 Installing or Removing a Software Package with
the pkgadd or pkgrm Command
All the software management tools that are listed in the preceding table are used
to install, remove, or query information about installed software. Both the
Solaris Product Registry prodreg viewer and the Solaris installation GUI access
installation data that is stored in the Solaris Product Registry. The package
tools, such as the pkgadd and pkgrm commands, also access or modify installation
data.
pkgadd Installs a signed or unsigned software package.
A signed package includes a digital
signature. A package with a valid digital
signature ensures that the package has not
been modified since the signature was
applied to the package. Using signed packages
is a secure method of downloading or
installing packages, because the digital signature
can be verified before the package is
installed on your system.
pkgadd
(1M)
This tool is
installed by
default.
pkgadm Maintains the keys and certificates used
to manage signed packages and signed
patches.
pkgadm
(1M)
This tool is
installed by
default.
pkgchk Checks the installation of a software
package.
pkgchk
(1M)
This tool is
installed by
default.
pkginfo Displays software package information. pkginfo
(1)
This tool is
installed by
default.
pkgparam Displays software package parameter
values.
pkgparam
(1)
This tool is
installed by
default.
pkgrm Removes a software package. pkgrm
(1M)
This tool is
installed by
default.
pkgtrans Translates an installable package from one
format to another format. The -g option
instructs the pkgtrans command to generate
and store a signature in the resulting
data stream.
pkgtrans
(1)
This tool is
installed by
default.
Table 3.1 Tools or Commands for Managing Software Packages (continued )
Tool or
Command
Description Man Page Installed by
Default?
From the Library of Daniel Johnson
3.5 USING PACKAGE COMMANDS TO MANAGE SOFTWARE PACKAGES 51
When you add a package, the pkgadd command uncompresses and copies files
from the installation media to a system’s local disk. When you remove a package,
the pkgrm command deletes all files associated with that package, unless those
files are also shared with other packages.
Package files are delivered in package format and are unusable as they are
delivered. The pkgadd command interprets the software package’s control files,
and then uncompresses and installs the product files onto the system’s local disk.
Although the pkgadd and pkgrm commands log their output to a log file, they
also keep track of packages that are installed or removed. The pkgadd and pkgrm
commands store information about packages that have been installed or removed
in a software product database. By updating this database, the pkgadd and pkgrm
commands keep a record of all software products installed on the system.
3.5 Using Package Commands to Manage Software Packages
The following procedures explain how to install and remove packages with the
pkgadd command.
3.5.1 How to Install Packages with the pkgadd Command
This procedure provides the steps to install one or more packages.
1. Become superuser or assume an equivalent role.
2. Remove any already installed packages with the same names as the packages
you are adding.
This step ensures that the system keeps a proper record of software that has
been added and removed.
# pkgrm pkgid ...
pkgid identifies the name of one or more packages, separated by spaces, to be
removed.
3. Install a software package to the system. The syntax for the pkgadd command
is as follows:
# pkgadd -a admin-file -d device-name pkgid ...
Caution
If the pkgid is omitted, the pkgrm command removes all available packages.
From the Library of Daniel Johnson
52 Chapter 3 _ Software Management: Packages
The following list provides explanations of each argument available for
pkgadd.
_ a admin-file
(Optional) Specifies an administration file that the pkgadd command
should check during the installation. For details about using an administration
file, see System Administration Guide: Basic Administration, which
is available on http://docs.sun.com.
_ -d device-name
Specifies the absolute path to the software packages. device-name can be the
path to a device, a directory, or a spool directory. If you do not specify the path
where the package resides, the pkgadd command checks the default spool
directory (/var/spool/pkg). If the package is not there, the package installation
fails.
_ pkgid
(Optional) Represents the name of one or more packages, separated by
spaces, to be installed. If omitted, the pkgadd command installs all available
packages from the specified device, directory, or spool directory.
If the pkgadd command encounters a problem during installation of the package,
then it displays a message related to the problem, followed by this prompt:
Do you want to continue with this installation?
Chose one of the following responses:
– If you want to continue the installation, type yes.
– If more than one package has been specified and you want to stop the
installation of the package being installed, type no.
The pkgadd command continues to install the other packages.
– If you want to stop the entire installation, type quit.
4. Verify that the package has been installed successfully.
# pkgchk -v pkgid
If no errors occur, a list of installed files is returned. Otherwise, the pkgchk
command reports the error.
The following example shows how to install the SUNWpl5u package from a
mounted Solaris 10 DVD or CD. The example also shows how to verify that the
package files were installed properly.
From the Library of Daniel Johnson
3.5 USING PACKAGE COMMANDS TO MANAGE SOFTWARE PACKAGES 53
The path on the DVD or CD Product directory varies depending on your
release:
_ For SPARC based media, the "s0" directory does not exist starting with the
Solaris 10 10/08 release.
_ For x86 based media, there is no "s0" directory in the Solaris 10 releases.
If the packages you want to install are available from a remote system, then you
can manually mount the directory that contains the packages, which are in package
format, and install the packages on the local system.
The following example shows how to install a software package from a remote
system. In this example, assume that the remote system named package-server
has software packages in the /latest-packages directory. The mount command
mounts the packages locally on /mnt. The pkgadd command installs the
SUNWpl5u package.
If the automounter is running at your site, then you do not need to manually
mount the remote package server. Instead, use the automounter path, in this case,
/net/package-server/latest-packages, as the argument to the -d option.
Example 3.1 Installing a Software Package From a Mounted CD
# pkgadd -d /cdrom/cdrom0/s0/Solaris_10/Product SUNWpl5u
.
.
.
Installation of <SUNWpl5u> was successful.
# pkgchk -v SUNWpl5u
/usr
/usr/bin
/usr/bin/perl
/usr/perl5
/usr/perl5/5.8.4
.
.
.
Example 3.2 Installing a Software Package From a Remote Package Server
# mount -F nfs -o ro package-server:/latest-packages /mnt
# pkgadd -d /mnt SUNWpl5u
.
.
.
Installation of <SUNWpl5u> was successful
From the Library of Daniel Johnson
54 Chapter 3 _ Software Management: Packages
3.5.2 Adding Frequently Installed Packages to a Spool Directory
For convenience, you can copy frequently installed packages to a spool directory. If
you copy packages to the default spool directory, /var/spool/pkg, then you do
not need to specify the source location of the package when you use the pkgadd
command. The source location of the package is specified in the -d device-name
option. The pkgadd command, by default, checks the /var/spool/pkg directory
for any packages that are specified on the command line. Note that copying packages
to a spool directory is not the same as installing the packages on a system.
3.5.2.1 How to Copy Software Packages to a Spool Directory with the
pkgadd Command
This procedure copies packages to a spool directory. The packages are then available
for use when you install the packages elsewhere with the pkgadd command.
1. Become superuser or assume an equivalent role.
2. Remove any already spooled packages with the same names as the packages
you are adding.
# pkgrm pkgid ...
pkgid identifies the name of one or more packages, separated by spaces, to be
removed.
3. Copy a software package to a spool directory.
# pkgadd -d device-name -s spooldir pkgid ...
The following list provides explanations of each argument used with the
pkgadd command.
_ -d device-name
Specifies the absolute path to the software packages. The device-name can
be the path to a device, a directory, or a spool directory.
# pkgadd -d /net/package-server/latest-packages SUNWpl5u
.
.
.
Installation of <SUNWpl5u> was successful.
Caution
If the pkgid option is omitted, then the pkgrm command removes all available
packages.
From the Library of Daniel Johnson
3.5 USING PACKAGE COMMANDS TO MANAGE SOFTWARE PACKAGES 55
_ -s spooldir
Specifies the name of the spool directory where the package will be
spooled. You must specify a spooldir.
_ pkgid
(Optional) The name of one or more packages, separated by spaces, to be
added to the spool directory. If omitted, the pkgadd command copies all
available packages to the spool directory.
4. Verify that the package has been copied successfully to the spool directory.
$ pkginfo -d spooldir | grep pkgid
If pkgid was copied correctly, the pkginfo command returns a line of
information about the pkgid. Otherwise, the pkginfo command returns the
system prompt.
The following example shows how to copy the SUNWman package from a mounted
SPARC based Solaris 10 DVD or CD to the default spool directory (/var/spool/pkg).
The path on the DVD or CD Product directory varies depending on your release
and platform:
_ For SPARC based media, the "s0" directory does not exist starting with the
Solaris 10 10/08 release.
_ For x86 based media, there is no "s0" directory in the Solaris 10 releases.
If packages you want to copy are available from a remote system, then you can
manually mount the directory that contains the packages, which are in package
format, and copy them to a local spool directory.
The following example shows the commands for this scenario. In this example,
assume that the remote system named package-server has software packages
in the /latest-packages directory. The mount command mounts the package
directory locally on /mnt. The pkgadd command copies the SUNWpl5p package
from /mnt to the default spool directory (/var/spool/pkg).
Example 3.3 Setting Up a Spool Directory From a Mounted CD
# pkgadd -d /cdrom/cdrom0/s0/Solaris_10/Product -s /var/spool/pkg SUNWman
Transferring <SUNWman> package instance
Example 3.4 Setting Up a Spool Directory From a Remote Software Package Server
# mount -F nfs -o ro package-server:/latest-packages /mnt
# pkgadd -d /mnt -s /var/spool/pkg SUNWpl5p
Transferring <SUNWpl5p> package instance
From the Library of Daniel Johnson
56 Chapter 3 _ Software Management: Packages
If the automounter is running at your site, then you do not have to manually
mount the remote package server. Instead, use the automounter path–which in this
case is /net/package-server/latest-packages–as the argument to the -d
option.
The following example shows how to install the SUNWpl5p package from the
default spool directory. When no options are used, the pkgadd command searches
the /var/spool/pkg directory for the named packages.
3.5.3 Removing Software Packages
To remove a software package, use the associated tool that you used to install a
software package. For example, if you used the Solaris installation GUI to install
the software, use the Solaris installation GUI to remove software.
3.5.3.1 How to Remove Software Packages with the pkgrm Command
This procedure provides the steps to remove packages with the pkgrm command.
1. Become superuser or assume an equivalent role.
2. Remove an installed package.
# pkgrm pkgid ...
# pkgadd -d /net/package-server/latest-packages -s /var/spool/pkg SUNWpl5p
Transferring <SUNWpl5p> package instance
Example 3.5 Installing a Software Package From the Default Spool Directory
# pkgadd SUNWpl5p
.
.
.
Installation of <SUNWpl5p> was successful.
Caution
Do not use the rm command to remove software packages. Doing so will result in inaccuracies
in the database that keeps track of all installed packages on the system.
From the Library of Daniel Johnson
3.5 USING PACKAGE COMMANDS TO MANAGE SOFTWARE PACKAGES 57
pkgid identifies the name of one or more packages, separated by spaces, to be
removed.
This example shows how to remove a package.
This example shows how to remove a spooled package.
For convenience, you can copy frequently installed packages to a spool directory.
In this example, the -s option specifies the name of the spool directory where the
package is spooled.
Caution
If the pkgid option is omitted, the pkgrm command removes all available packages.
Example 3.6 Removing a Software Package
# pkgrm SUNWctu
The following package is currently installed:
SUNWctu Netra ct usr/platform links (64-bit)
(sparc.sun4u) 11.9.0,REV=2001.07.24.15.53
Do you want to remove this package? y
## Removing installed package instance <SUNWctu>
## Verifying package dependencies.
## Removing pathnames in class <none>
## Processing package information.
.
.
.
Example 3.7 Removing a Spooled Software Package
# pkgrm -s /export/pkg SUNWaudh
The following package is currently spooled:
SUNWaudh Audio Header Files
(sparc) 11.10.0,REV=2003.08.08.00.03
Do you want to remove this package? y
Removing spooled package instance <SUNWaudh>
From the Library of Daniel Johnson
This page intentionally left blank
From the Library of Daniel Johnson
59
4
Software Management:
Patches
This chapter describes patches, provides best practices, and includes step-by-step
procedures for applying patches.
4.1 Managing Software with Patches
Software management involves installing or removing software products. Sun and
its third-party independent software vendors (ISVs) deliver software as a collection
of one or more packages. Patches are generally delivered as a set of sparse
packages. Sparse packages are a minimalist version of a regular package. A sparse
package delivers only the files being updated.
The following sections describe patches and provide step-by-step procedures for
applying patches. Also, a best practices section provides planning information for
proactive and reactive patching.
4.2 What Is a Patch?
A patch adds, updates, or deletes one or more files on your system by updating the
installed packages. A patch consists of the following:
_ Sparse packages that are a minimalist version of a regular package. A sparse
package delivers only the files being updated.
From the Library of Daniel Johnson
60 Chapter 4 _ Software Management: Patches
_ 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 a patch when the patchrm command is used. These
scripts are copied onto the system’s patch undo area.
– Prepatch, prebackout, and postpatch 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 by the patchrm
command.
For more detailed information, see Section 4.7, “Patch README Special Instructions.”
4.2.1 Patch Content
In past Solaris releases, patches delivered bug fixes only. Over time, patches have
evolved and now have many other uses. For the Solaris 10 Operating System (OS),
patches are used to deliver the following:
_ Bug fixes.
_ New functionality—Bug fixes can sometimes deliver significant functionality,
such as ZFS file systems or GRUB, the open source boot loader that is the
default boot loader in the Solaris OS.
Some features require the installation of new packages, but any change to
existing code is always delivered in a patch.
– If a new package is required, then the new features are typically available
only by installing or upgrading to a Solaris 10 release that contains the
new packages.
– If the change is to existing code, then the change is always delivered in a
patch. Because new functionality such as new features in ZFS and GRUB
is delivered entirely by patches, the patches enable businesses to take
advantage of the new functionality without having to upgrade to a newer
release of the Solaris OS. Therefore, Sun ships some new functionality in
standard patches.
_ New hardware support—Sun also ships new hardware support in patches for
similar reasons that Sun ships new functionality: the need to get support for
hardware to market quickly and yet maintain a stable release model going
forward.
_ Performance enhancements or enhancements to existing utilities.
From the Library of Daniel Johnson
4.3 PATCH MANAGEMENT BEST PRACTICES 61
4.2.2 Patch Numbering
Patches are identified by unique patch IDs. A patch ID is an alphanumeric string
that consists of a patch base code and a number that represents the patch revision
number joined with a hyphen. The following example shows the patch ID for the
Solaris 10 OS, 10th revision:
_ SPARC: 119254-10
_ x86: 119255–10
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.
4.3 Patch Management Best Practices
This section provides guidelines for creating a patch management strategy for
any organization. These strategies are only guidelines because every organization
is different in both environment and business objectives. Some organizations
have specific guidelines on change management that must be adhered to
when developing a patch management strategy. Customers can contact Sun Services
to help develop an appropriate patch management strategy for their specific
circumstances.
This section also provides useful information and tips that are appropriate for a
given strategy, the tools most appropriate for each strategy, and where to locate
the patches or patch clusters to apply.
Your strategy should be reviewed periodically because the environment and
business objectives change over time, because new tools and practices evolve, and
because operating systems evolve. All of these changes require modifications to
your existing patch management strategy.
The four basic strategies outlined in this section are the following:
_ Proactive patch management
_ Reactive patch management
_ Security patch management
_ Proactive patch management when installing a new system
From the Library of Daniel Johnson
62 Chapter 4 _ Software Management: Patches
4.3.1 Proactive Patch Management Strategy
The main goal of proactive patch management is problem prevention, especially
preventing unplanned downtime. Often, problems have already been identified and
patches have been released. The issue for proactive patching is identifying important
patches and applying those patches in a safe and reliable manner.
For proactive patching, the system is already functioning normally. Because any
change implies risk and risk implies downtime, why patch a system that is functioning
normally? Although a system is functioning normally, an underlying issue
could cause a problem. Underlying issues could be the following:
_ Memory corruption that has not yet caused a problem.
_ Data corruption that is silent until that data is read back in.
_ Latent security issues.
Most security issues are latent issues that exist but are not yet causing security
breaches. These issues require proactive action to prevent security
breaches.
_ Panics due to code paths that have not been exercised before.
Use proactive patching as the strategy of choice, where applicable. Proactive
patching is recommended for the following reasons:
_ It reduces unplanned downtime.
_ It prevents systems from experiencing known issues.
_ It provides the capability to plan ahead and do appropriate testing before
deployment.
_ Planned downtime for maintenance is usually much less expensive than
unplanned downtime for addressing issues reactively.
4.3.1.1 Core Solaris Tools for Patching
Solaris Live Upgrade is the recommended tool for patching proactively. The
patchadd command can be used in situations where Solaris Live Upgrade is not
appropriate.
Note
Before adding any patches, make sure you apply the latest revision of the patch utilities.
The latest patch for the patch utilities must be applied to the live system in all cases. This
chapter assumes that the latest patch for the patch utilities has been applied before any
other patching is done.
From the Library of Daniel Johnson
4.3 PATCH MANAGEMENT BEST PRACTICES 63
4.3.1.2 Benefits of Solaris Live Upgrade
The information in this section describes how to use the Solaris Live Upgrade and
core patch utilities to patch a system. Sun also has a range of higher-level patch
automation tools. See Section 4.5, “Patch Automation Tools,” for more information.
To proactively apply patches, use Solaris Live Upgrade. Solaris Live Upgrade
consists of a set of tools that enable you to create an alternate boot environment
that is a copy of the current boot environment. You can then patch the newly created
boot environment while the system is running. After the copy is patched, the
new boot environment can be booted.
The benefits of using Solaris Live Upgrade are the following:
_ Decreased downtime—The only downtime that is needed is the time to boot
between the currently running boot environment and the newly patched boot
environment. Patching is not done on the currently running boot environment
so that the system can continue to be in production until the timing is
suitable to boot to the newly patched boot environment.
_ Fallback to the original boot environment—If a problem occurs, you can
reboot to the original boot environment. The patches do not need to be
removed by using the patchrm command.
You can use Solaris Live Upgrade’s luupgrade command to apply the Recommended
Patch Cluster. In this example, you use the luupgrade command with the
-t and -O options. The first -t option specifies to install a patch. The -O option
Note
To track issues relevant to proactive patching, register to receive Sun Alerts. For the registration
procedure, see Section 4.3.3.1, “How to Register for Sun Alerts.” For a procedure to
access patches, see Section 4.3.5.1, “How to Access Patches.”
Note
A boot environment is a collection of mandatory file systems (disk slices and mount points)
that are critical to the operation of the Solaris OS. These disk slices might be on the same disk
or distributed across multiple disks. The active boot environment is the one that is currently
booted. Only one active boot environment can be booted. An inactive boot environment is
not currently booted, but can be in a state of waiting for activation on the next reboot.
From the Library of Daniel Johnson
64 Chapter 4 _ Software Management: Patches
with the second -t option instructs the patchadd command to skip patch dependency
verification.
For a complete example of using Solaris Live Upgrade, see Section 4.4, “Example
of Using Solaris Live Upgrade to Install Patches.”
4.3.1.3 When to Use the patchadd Command Instead of Solaris
Live Upgrade
If Solaris Live Upgrade is not applicable to the system being patched, then the
patchadd command is used. After the appropriate patches are downloaded and all
requirements are identified, then the patches can be applied by using the
patchadd command. Table 4.1 provides a guide to when to use the patchadd
command.
Example 4.1 Applying the Recommended Patch Cluster by Using the
luupgrade Command
# cd 10_Recommended
# luupgrade -t -n be3 -O -t -s . ./patch_order
Table 4.1 When to Use the patchadd Command
Problem Description
Limited disk resources If disk resources are limited and you cannot set up an inactive
boot environment, then you need to use the patchadd command.
Also, if you are using Solaris Volume Manager for mirroring,
then you might need to use the patchadd command. You
need extra resources to set up a Solaris Volume Manager inactive
boot environment.
Veritas Storage
Foundation root disk
If you are using Veritas Storage Foundation to encapsulate the
root disk, then you can use Solaris Live Upgrade to create a new
boot environment. However, 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, then
you can use the lucreate command to 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.
From the Library of Daniel Johnson
4.3 PATCH MANAGEMENT BEST PRACTICES 65
If additional patches are to be applied to a Solaris 10 system by using the
patchadd command, then the -a and -M options can be useful for identifying any
missing requirements and identifying a valid installation order for the patches.
While this method of applying patches has the major disadvantage of requiring
you to patch the live system, which increases both downtime and risk, you can
reduce the risk by using the -a option to inspect the patches before applying them
against the actual system.
Note the following limitations to the patchadd -M option:
_ This option is only available starting with the Solaris 10 03/05 release.
_ You cannot apply patches using -M without the -a option, due to several
problems in the current implementation.
In the following example, the -a option instructs the -M option to perform a dry
run, so that no software is installed and no changes are made to the system. The
output from the command is verbose but consists of an ordered list of patches that
can be installed. Also, the dry run clearly identifies any patches that cannot be
installed due to dependencies that must be satisfied first.
After identifying the complete list of patches, you can install the patches one by
one by using the patchadd command without the -M option.
In the following example of using patchadd in a loop, the patch_order_file
is the ordered list from the -M and -a options. The -q option instructs the
Recommended Patch
Cluster installation
If you want to install the Recommended Patch Cluster with the
cluster_install script, then you do not have to use Solaris
Live Upgrade or the patchadd command. The Recommended
Patch Cluster can be installed by using the cluster_install
script that comes with the Cluster. The cluster_install
script invokes the patchadd command to apply the patches to
the live boot environment in the installation order specified in
the patch_order file.
Example 4.2 Using the patchadd Command with the -a Option for a Dry Run
# patchadd -a -M patches-directory
Table 4.1 When to Use the patchadd Command (continued )
Problem Description
From the Library of Daniel Johnson
66 Chapter 4 _ Software Management: Patches
-M option to run in “quiet” mode. Also, this option outputs headings for the installable
patches, which are called Approved patches.
4.3.1.4 Proactive Patching on Systems with Non-Global Zones Installed
Solaris Live Upgrade is the recommended tool for patching systems with nonglobal
zones. The patchadd command can be used in situations where Solaris Live
Upgrade is not applicable.
The Solaris Zones partitioning technology is used to virtualize operating system
services and provide an isolated and secure environment for running applications.
A non-global zone is a virtualized operating system environment created within a
single instance of the Solaris OS. When you create a non-global zone, you produce
an application execution environment in which processes are isolated from the rest
of the system. This isolation prevents processes that are running in one non-global
zone from monitoring or affecting processes that are running in other non-global
zones. Even a process running with superuser privileges cannot view or affect activity
in other zones. A non-global zone also provides an abstract layer that separates
applications from the physical attributes of the system on which they are deployed.
Examples of these attributes include physical device paths. For more information
about non-global zones, see System Administration Guide: Solaris Containers-
Resource Management and Solaris Zones available at http://docs.sun.com.
4.3.1.5 Using Solaris Live Upgrade When Non-Global Zones Are Installed
On systems with non-global zones installed, patching can be done by using Solaris
Live Upgrade.
Note the following limitations for Solaris Live Upgrade:
_ If you are running the Solaris 10 8/07 release or a later release, then Solaris
Live Upgrade can be used to apply patches.
_ If you are running a Solaris 10 release prior to the Solaris 10 8/07 release,
then you must ensure that you have the software and bug fixes to run Solaris
Live Upgrade.
Example 4.3 Applying the Patches by Using the patchadd Command
# patchadd -q -a -M . |grep "Approved patches:" |sort -u \
|sed -e "s/Approved patches://g" > patch_order_file 2>&1
# Cat patch_order_file
120900-03 121333-04 119254-50
#for i in 'cat patch_order-file'
do
patchadd $i
done
From the Library of Daniel Johnson
4.3 PATCH MANAGEMENT BEST PRACTICES 67
_ You cannot use the luupgrade command with the -t option to apply a list of
patches using an order file because this option uses the patchadd -M option
internally. Due to current issues with the patchadd -M option, this option
can lead to unrecoverable errors.
To ensure that you have the software and bug fixes needed because you are running
a Solaris 10 release prior to the 8/07 release, follow these steps:
1. Add the Solaris Live Upgrade packages from the Solaris 10 8/07 release to
the live system.
2. Apply the list of required patches. If these patches are not installed, then
Solaris Live Upgrade fails. These patches are needed to add the current bug
fixes and the latest functionality for Solaris Live Upgrade. These patches are
available on the SunSolve Web site in the info document “Solaris Live
Upgrade Software: Minimum Patch Requirements.” Search on SunSolve for
info document 206844 at http://sunsolve.sun.com. This document lists
the required patches and provides the process needed to update Solaris Live
Upgrade so that a system with a release prior to the Solaris 10 05/08 release
can use the software.
The Solaris 10 Live Upgrade Patch Bundle provides a quick way to install all the
required patches to use Solaris Live Upgrade on systems that have non-global
zones installed. This Patch Bundle provides non-global zones support for systems
running a release prior to the Solaris 10 5/08 release.
The list of required patches for a system with non-global zones is quite large. The
patches must be applied to the live running environment. However, after these
patches are applied, Solaris Live Upgrade can be used to patch going forward with
all the benefits that Solaris Live Upgrade provides.
4.3.1.6 Using the patchadd Command When Non-Global Zones
are Installed
If Solaris Live Upgrade is not an acceptable option, then use the same method outlined
in Section 4.3.1.1, “Core Solaris Tools for Patching.” You identify all the
Note
Starting with the Solaris 10 8/07 release, full support for installing non-global zones
became available, including the capability to use Solaris Live Upgrade to upgrade or patch
a system with non-global zones installed. However, due to problems, the required patches
are needed to use Solaris Live Upgrade with non-global zones in the Solaris 10 8/07
release.
From the Library of Daniel Johnson
68 Chapter 4 _ Software Management: Patches
patches required and use the patchadd command with the -a and -M options to
identify any missing requirements. The -a option performs a dry run and no
patches are installed.
Pay attention to the patchadd -a and -M output. In particular, ensure that all
non-global zones have passed the dependency tests. The -a option can help identify
the following issues with non-global zones:
_ Zones that cannot be booted
_ Patches that did not meet all the required dependencies for a non-global zone
If the -a option identifies any issues, then those issues must be rectified before
patching can begin.
Apply patches individually by using the patchadd command. To facilitate
applying multiple patches, you can use patchadd -a -M patch-dir to produce
an ordered list of patches that can be installed individually.
Due to current issues with patchadd -M option, do not run -M patch-dir
without the -a option. The -M option can lead to unrecoverable errors.
If you are using the patchadd command, then run the following command first.
This command verifies that all zones can be booted and that the specified patch is
applicable in all zones.
4.3.2 Reactive Patch Management Strategy
Reactive patching occurs in response to an issue that is currently affecting the
running system and which requires immediate relief. The most common response
to fixing the system can often lead to worse problems. Usually, the fix is to apply
the latest patch or patches. These patches could be the latest Recommended Patch
Cluster or one or more patches that seem to be appropriate. This strategy might
work if the root cause of the undiagnosed issue had been determined and if a patch
has been issued to fix the issue. However, if this approach does not fix the problem,
then the problem can be worse than it was before you applied the patch.
There are two reasons why this approach is fundamentally flawed:
_ If the problem seems to go away, then you do not know whether the patch or
patches actually fixed the underlying problem. The patches might have
changed the system in such a way as to obscure the problem for now and the
problem could recur later.
Example 4.4 How to Identify Problems Before Applying Patches
# patchadd -a patch-id verify
From the Library of Daniel Johnson
4.3 PATCH MANAGEMENT BEST PRACTICES 69
_ Applying patches in a reactive patching session introduces an element of
risk. When you are in a reactive patching situation, you must try to minimize
risk (change) at all costs. In proactive patching, you can and should
have tested the change you are applying. In a reactive situation, if you
apply many changes and those changes do not fix the underlying issue or if
they do fix the underlying issue, then you now have a system issue that still
needs the root cause identified. Identifying the root cause involves a lot
more risk. Furthermore, the changes that you applied might have negative
consequences elsewhere on the system, which could lead to more reactive
patching.
Therefore, if you experience a problem that is affecting the system, then you
should spend time investigating the root cause of the problem. If a fix can be identified
from such an investigation and that fix involves applying one or more
patches, then the change is minimized to just the patch or set of patches required
to fix the problem.
Depending on the severity of the problem, the patch or patches that fix the problem
would be installed at one of the following times:
_ Immediately
_ At the next regular maintenance window, if the problem is not critical or a
workaround exists
_ During an emergency maintenance window that is brought forward to facilitate
applying the fix
4.3.2.1 Tools for Analyzing Problems and Identifying Patches
Identifying patches that are applicable in a reactive patching situation can often
be complex. If you have a support contract, then use the official Sun Support channels.
To begin, you should do some analysis. Some tools that are useful in starting
this analysis might include the following:
_ The truss command with the options such as -fae
_ The dtrace command (dynamic tracing framework) that permits you to concisely
answer questions about the behavior of the operating system and user
programs
_ Various system analysis tools, such as kstat, iostat, netstat,
prstat, sar, vmstat, and even mdb
When you are providing data to Sun engineers, use the Sun Explorer logs. These
logs provide a good foundation to start an analysis of the system.
From the Library of Daniel Johnson
70 Chapter 4 _ Software Management: Patches
No standard tool for analyzing a problem can be recommended because each
problem involves different choices. Using debug-level logging and examining various
log files might also provide insight into the problem. Also, a proper recording
system that records changes to the system should be considered. A record of recent
system configuration changes can be investigated as possible root causes.
4.3.2.2 Tools for Applying Patches for Reactive Patching
The tool you use for reactive patching depends on the situation as follows:
_ If a fix has been identified and a patch has been downloaded, then use Solaris
Live Upgrade to apply patches. Solaris Live Upgrade is covered in more
detail in Section 4.3.1.1, “Core Solaris Tools for Patching.”
_ If you need to apply the patch or patches immediately or the issue impacts
Solaris Live Upgrade, then you should first run the patchadd command with
the -a option. The -a option performs a dry run and does not modify the system.
Prior to actually installing the patch or patches, inspect the output from
the dry run for issues.
_ If more than one patch is being installed, then you can use the patchadd
command with the -a and -M options. These options perform a dry run and
produce an ordered list of patches that can be installed. After determining
that no issues exist, the patches should be installed individually by using the
patchadd command.
_ If the system has non-global zones installed, then you should apply all
patches individually by using Solaris Live Upgrade with the luupgrade command.
Or, you can use the patchadd command. Never use the -M option to
the patchadd command with non-global zones. Also, never apply a list of
patches using an order file with the luupgrade command with the -t option.
The -t option uses the patchadd -M option in the underlying software.
There are problems with the -M option.
In addition to using the core Solaris Live Upgrade and patch utilities to patch a
system, Sun also has a range of higher-level patch automation tools. For more
information, see Section 4.5, “Patch Automation Tools.”
4.3.3 Security Patch Management Strategy
Security patch management requires a separate strategy from proactive and reactive
patching. For security patching, you are required to be proactive, but a sense
of urgency prevails. Relevant security fixes might need to be installed proactively
before the next scheduled maintenance window.
From the Library of Daniel Johnson
4.3 PATCH MANAGEMENT BEST PRACTICES 71
4.3.3.1 How to Register for Sun Alerts
To be prepared for security issues, register to receive Sun Alerts. When you register
for Sun alerts, you also receive Security Alerts.
In addition, a security Web site contains more information about security and
you can report issues there. On the SunSolve home page, see “Sun Security Coordination
Team.” On this page, you will find other resources such as the security blog.
1. Log in to the SunSolve Web site at http://sunsolve.sun.com.
2. Accept the license agreement.
3. Find the “Sun Alerts” section.
4. Click Subscribe to Sun Alerts.
5. Choose the newsletters and reports that you want to receive.
The Sun Alert Weekly Summary Report provides a summary of new Sun Alert
Notifications about hardware and software issues. This report is updated weekly.
4.3.3.2 Tools for Applying Security Patches
The same rules for proactively or reactively applying patches also apply to applying
security patches. If possible, use Solaris Live Upgrade. If Solaris Live Upgrade
is not appropriate, then use the patchadd command. For more information, see
Section 4.3.1.1, “Core Solaris Tools for Patching.”
In addition to using Solaris Live Upgrade and the patch utilities to patch a system,
Sun also has a range of higher-level patch automation tools. For more information,
see Section 4.5, “Patch Automation Tools.”
4.3.4 Proactive Patching When Installing a New System
The best time to proactively patch a system is during installation. Patching during
installation ensures that, when the system boots, the system has the latest
patches installed. Patching avoids any known issues that are outstanding. Also, if
testing has been scheduled into the provisioning plan, then you can test the configuration
in advance. In addition, you can create a baseline for all installations.
Patching during installation requires that you use the JumpStart installation
program.
The JumpStart installation program is a command-line interface that enables
you to automatically install or upgrade several systems based on profiles that you
create. The profiles define specific software installation requirements. You can also
incorporate shell scripts to include preinstallation and postinstallation tasks. You
choose which profile and scripts to use for installation or upgrade. Also, you can use
a sysidcfg file to specify configuration information so that the custom JumpStart
From the Library of Daniel Johnson
72 Chapter 4 _ Software Management: Patches
installation is completely hands off. Solaris 10 Installation Guide: Custom Jump-
Start and Advanced Installations is available at http://docs.sun.com. You can
find profile examples in the “Preparing Custom JumpStart Installations (Tasks)”
chapter of the installation guide. Also, finish scripts can apply patches. See the
examples in the chapter “Creating Finish Scripts” of the aforementioned Solaris 10
Installation Guide.
A JumpStart profile is a text file that defines how to install the Solaris software
on a system. A profile defines elements of the installation; for example, the software
group to install. Every rule specifies a profile that defines how a system is to
be installed. You can create different profiles for every rule or the same profile can
be used in more than one rule. Here is an example profile that performs an
upgrade and installs patches.
In this example of a JumpStart profile, a system is upgraded and patched at the
same time.
The following describes the keywords and values from this example:
_ install_type
The profile upgrades a system by reallocating disk space. In this example,
disk space must be reallocated because some file systems on the system do
not have enough space for the upgrade.
_ root_device
The root file system on c0t3d0s2 is upgraded.
_ backup_media
A remote system that is named timber is used to back up data during the
disk space reallocation.
_ package
The binary compatibility package, SUNWbcp, is not installed on the system
after the upgrade.
Example 4.5 Upgrading and Installing Patches with a JumpStart Profile
# profile keywords profile values
# ---------------- -------------------
install_type upgrade
root_device c0t3d0s2
backup_media remote_filesystem timber:/export/scratch
package SUNWbcp delete
package SUNWxwman add
cluster SUNWCacc add
patch patch_list \
nfs://patch_master/Solaris_10/patches \
retry 5
locale de
From the Library of Daniel Johnson
4.3 PATCH MANAGEMENT BEST PRACTICES 73
_ package
The code ensures that the X Window System man pages are installed if
they are not already installed on the system. All packages already on the
system are automatically upgraded.
_ cluster
The system accounting utilities, SUNWCacc, are installed on the system.
_ patch
A list of patches are installed with the upgrade. The patch list is
located on an NFS server named patch_master under the directories
Solaris_10/patches. In the case of a mount failure, the NFS mount is
tried five times.
_ locale
The German localization packages are installed on the system.
The following patch keyword example applies an individual patch. The patch
keyword installs the single patch 119254-50 from the network where the Recommended
Patch Cluster is located.
In this example, the patch keyword applies the Recommended Patch Cluster
from the network where the Cluster is located. The retry n keyword is an optional
keyword. The n refers to the maximum number of times the installation process
attempts to mount the directory.
4.3.5 Identifying Patches for Proactive Patching and
Accessing Patches
To track issues relevant to proactive patching, register to receive Sun Alerts. See
Section 4.3.3.1, “How to Register for Sun Alerts.” Alternatively, you can install the
most recent Recommended Patch Cluster, which contains Sun Alerts. The Recommended
Patch Cluster can be downloaded from the SunSolve Patch Access page.
See Section 4.3.5.1, “How to Access Patches.”
Example 4.6 JumpStart Profile for Applying an Individual Patch
patch 119254-50 nfs://server-name/export/images/SPARC/10_Recommended
Example 4.7 JumpStart Profile for Applying the Recommended Patch Cluster
patch patch_order nfs://server-name/export/10_Recommended retry 5
From the Library of Daniel Johnson
74 Chapter 4 _ Software Management: Patches
Individual patches can be downloaded from the Patches and Updates page on
the Web site.
4.3.5.1 How to Access Patches
Some patches are free, while other patches require a support contract.
_ Patches that address security issues and patches that provide new hardware
drivers are free.
_ You must have a valid support contract to access most other Solaris patches,
including the Solaris patch clusters, such as the Recommended Patch Cluster
or the Sun Alert Patch Cluster. The following support contracts entitle customers
to access all patches plus a wide range of additional support services:
– Support contracts for Solaris OS only: Solaris Subscriptions
– Support contracts for your entire system: Sun Spectrum Service Plans
For the Solaris 10 OS, patches for the patch utility patches use the following patch IDs:
_ SPARC: 119254-xx
_ x86: 119255-xx
To install the patches, follow these steps:
1. Log in to the SunSolve Web site at http://sunsolve.sun.com.
2. Accept the license agreement.
3. Find the section “Latest Patch Update.”
This section provides a complete list of prerequisite patches for each OS
version that should be installed before other patches are applied.
4. Click the “Patches and Updates” section.
5. In the “Product Patches” section, select the OS for your platform (either
SPARC or x86).
6. Download the patch.
Note
Both the Recommended Patch Cluster and Sun Alert Patch Cluster contain only core Solaris
OS patches. They do not contain patches for Sun Java Enterprise System, Sun Cluster software,
Sun Studio software, or Sun N1 software. They do not contain other non-Solaris OS
patches that address security, data corruption, or system availability issues.
From the Library of Daniel Johnson
4.4 EXAMPLE OF USING SOLARIS LIVE UPGRADE TO INSTALL PATCHES 75
7. Read the Special Install Instructions for all patches prior to installing them.
Special Install Instructions can be updated after the patch has been
released to the SunSolve Web site. These instructions clarify issues surrounding
the particular patch installation or to notify users of newly identified
issues.
4.4 Example of Using Solaris Live Upgrade to Install Patches
This section provides an example procedure for patching a system with a basic configuration.
This procedure provides commands based on the Solaris 10 8/07
release. If you are using Solaris Live Upgrade from another release, then you
might need slightly different procedures. For detailed planning information or procedures
for more complex upgrading procedures, such as for upgrading when
Solaris Zones are installed or upgrading with a mirrored root (/) file system, see
Solaris 10 Installation Guide: Solaris Live Upgrade and Upgrade Planning available
at http://docs.sun.com. This guide is available for each Solaris 10 release.
4.4.1 Overview of Patching with Solaris Live Upgrade
As Figure 4.1 shows, the Solaris Live Upgrade process involves the following steps.
1. Creating a new boot environment by using the lucreate command.
2. Applying patches to the new boot environment by using the luupgrade
command.
3. Activating the new boot environment by using the luactivate command.
4. Falling back to the original boot environment if needed by using the
luactivate command.
5. Removing an inactive boot environment by using the ludelete command.
You can remove a boot environment after the running boot environment is
stable.
From the Library of Daniel Johnson
76 Chapter 4 _ Software Management: Patches
Figure 4.1 Solaris Live Upgrade Patching Process
From the Library of Daniel Johnson
4.4 EXAMPLE OF USING SOLARIS LIVE UPGRADE TO INSTALL PATCHES 77
4.4.2 Planning for Using Solaris Live Upgrade
Table 4.2 describes the requirements and limitations for patching with Solaris Live
Upgrade. Table 4.3 describes limitations for activating a boot environment.
Table 4.2 Solaris Live Upgrade Planning and Limitations
Planning issue Description
Disk space requirements Using Solaris Live Upgrade involves having two boot environments
on your system. Therefore, a prerequisite is to
have enough disk space for both the original and new boot
environments. You need either an extra disk or one disk
large enough to contain both boot environments.
Supported releases Sun supports and tests an upgrade from any release to a
subsequent release that is no more than two releases
ahead. For example, if you are running the Solaris 7 release,
then you can upgrade to any Solaris 8 or Solaris 9 release,
but not to a Solaris 10 release. If you are running the Solaris
7 release, then you would need to upgrade to the Solaris 8
release before using Solaris Live Upgrade.
Any Solaris release includes all the releases within that release.
For example, you could upgrade from the Solaris 9 release, to
the Solaris 10 3/05 release or the Solaris 10 1/06 release.
You need to upgrade to the latest version of the Solaris Live
Upgrade software prior to patching the system, regardless
of the version of the Solaris OS running on the system. You
need the packages for the latest features and bug fixes.
Dependency order of patches The patchadd command in the Solaris 10 release correctly
orders patches for you, but the Solaris 9 and earlier
releases require patches to be in dependency order. When
using the luupgrade command to apply patches, apply
the patches in dependency order, regardless of the Solaris
release you are using. Sun uses dependency order as part of
the standard testing of the luupgrade command and you
can be assured that this order was tested.
Patch log evaluation Patching can generate a number of errors. You should
examine the patch log to determine whether any patch
failures impact you.
Sometimes a log indicates that a patch has failed to install,
but this is not a problem. For example, if a patch delivers
bug fixes for package A and your system does not have
package A, then the patch fails to install. The installation
log should be checked to ensure all messages are as
expected.
continues
From the Library of Daniel Johnson
78 Chapter 4 _ Software Management: Patches
When you activate a boot environment by using the luactivate command, the
boot environment must meet the conditions described in the Table 4.3.
Support for third-party patches You might not be able to apply third-party patches with
Solaris Live Upgrade. All Sun patches conform to the
requirement that preinstallation and postinstallation scripts
never modify the running system when the target is an
inactive boot environment. Furthermore, testing the application
of Recommended Patches with Solaris Live Upgrade
is part of Sun’s standard test procedures. However, Sun
cannot guarantee that all third-party patches are equally
well behaved. When you intend to patch an inactive boot
environment, you might need to verify that a third-party
patch does not contain a script that attempts to modify the
currently running environment.
Table 4.3 Limitations for Activating a Boot Environment
Description For More Information
The boot environment must have a
status of complete.
Use the lustatus command to display information
about each boot environment.
# lustatus BE-name
The BE-name variable specifies the inactive boot environment.
If BE-name is omitted, lustatus displays
the status of all boot environments in the system.
If the boot environment is not the
current boot environment, then you
cannot mount the partitions of that
boot environment by using the
luumount or mount commands.
See the lumount(1M) or mount(1M) man page at
http://docs.sun.com.
The boot environment that you
want to activate cannot be involved
in a comparison operation.
To compare boot environments, you use the
lucompare command. The lucompare command
generates a comparison of boot environments that
includes the contents of non-global zones.
If you want to reconfigure swap, do
so prior to booting the inactive boot
environment. By default, all boot
environments share the same swap
devices.
By not specifying swap with the lucreate command
with the -m option, your current and new boot
environment share the same swap slices. If you want
to reconfigure the new boot environment’s swap, use
the -m option to add or remove swap slices in the
new boot environment.
Table 4.2 Solaris Live Upgrade Planning and Limitations (continued )
Planning issue Description
From the Library of Daniel Johnson
4.4 EXAMPLE OF USING SOLARIS LIVE UPGRADE TO INSTALL PATCHES 79
4.4.3 How to Apply a Patch When Using Solaris Live
Upgrade for the Solaris 10 8/07 Release
Before installing or running Solaris Live Upgrade, you must install the patches in
SunSolve info doc 206844.
These patches ensure that you have all the latest bug fixes and new features in
the release. Ensure that you install all the patches that are relevant to your system
before proceeding.
1. Become superuser or assume an equivalent role.
2. If you are storing the patches on a local disk, create a directory such as
/var/tmp/lupatches.
3. From the SunSolve Web site, follow the instructions in info doc 206844 to
remove and add Solaris Live Upgrade packages. The Web site is located at
http://sunsolve.sun.com.
The following summarizes the info doc steps for removing and adding the
packages:
1. Remove existing Solaris Live Upgrade packages.
The three Solaris Live Upgrade packages SUNWluu, SUNWlur, and SUNWlucfg
comprise the software needed to upgrade by using Solaris Live
x86 only: Activating the boot environment
If you have an x86 based system, you can activate a
boot environment by using the GRUB menu instead
of the luactivate command. Note the following
exceptions:
_ If a boot environment was created with the
Solaris 8, 9, or 10 3/05 release, then the boot
environment must always be activated with the
luactivate command. These older boot
environments do not display in the GRUB
menu.
_ The first time you activate a boot environment,
you must use the luactivate command. The
next time you boot, that boot environment’s
name is displayed in the GRUB main menu. You
can thereafter switch to this boot environment
by selecting the appropriate entry in the GRUB
menu.
Table 4.3 Limitations for Activating a Boot Environment (continued )
Description For More Information
From the Library of Daniel Johnson
80 Chapter 4 _ Software Management: Patches
Upgrade. These packages include existing software, new features, and bug
fixes. If you do not remove the existing packages and install the new packages
on your system before using Solaris Live Upgrade, upgrading to the target
release fails. The SUMWlucfg package is new starting with the Solaris 10 8/07
release. If you are using Solaris Live Upgrade packages from a release previous
to Solaris 10 8/07, then you do not need to remove this package.
# pkgrm SUNWlucfg SUNWluu SUNWlur
2. Install the new Solaris Live Upgrade packages.
You can install the packages by using the liveupgrade20 command that
is on the installation DVD or CD. The liveupgrade20 command requires
Java software. If your system does not have Java software installed, then you
need to use the pkgadd command to install the packages. See the SunSolve
info doc for more information.
3. Choose to run the installer from DVD or CD media.
a. If you are using the Solaris Operating System DVD, then change directories
and run the installer:
Change directories:
/cdrom/cdrom0/Solaris_10/Tools/Installers
Run the installer:
# ./liveupgrade20 -noconsole - nodisplay
The -noconsole and -nodisplay options prevent the character user
interface (CUI) from displaying. The Solaris Live Upgrade CUI is no
longer supported.
b. If you are using the Solaris Software-2 CD, run the installer without
changing the path:
% ./installer
4. Verify that the packages have been installed successfully.
# pkgchk -v SUNWlucfg SUNWlur SUNWluu
Note
For SPARC based systems, the path to the installer is different for releases previous
to the Solaris 10 10/08 release:
# cd /cdrom/cdrom0/s0/Solaris_10/Tools/Installers
From the Library of Daniel Johnson
4.4 EXAMPLE OF USING SOLARIS LIVE UPGRADE TO INSTALL PATCHES 81
5. Obtain the list of patches.
6. Change to the patch directory.
# cd /var/tmp/lupatches
7. Install the patches.
# patchadd -M /var/tmp/lupatches patch-id patch-id
patch-id is the patch number or numbers. Separate multiple patch names
with a space.
8. Reboot the system if necessary. Certain patches require a reboot to be
effective.
# init 6
x86 only
Rebooting the system is required. Otherwise, Solaris Live Upgrade fails.
9. Create the new boot environment.
# lucreate [-c BE-name] -m mountpoint:device:fs-options \
[-m ...] -n BE-name
Explanation of the lucreate options follows:
_ -c BE-name
(Optional) Assigns the name BE-name to the active boot environment.
This option is not required and is used only when the first boot environment
is created. If you run lucreate for the first time and you omit the
-c option, then the software creates a default name for you.
_ -m mountpoint:device:fs-options [-m ...]
Specifies the file systems’ configuration of the new boot environment in
the vfstab file. The file systems that are specified as arguments to -m can
be on the same disk or they can be spread across multiple disks. Use this
option as many times as needed to create the number of file systems that is
needed.
– mountpoint can be any valid mount point or - (hyphen), indicating a
swap partition.
– device field is the name of the disk device.
– fs-options field is ufs, which indicates a UFS file system.
Note
The patches need to be applied in the order specified in info doc 206844.
From the Library of Daniel Johnson
82 Chapter 4 _ Software Management: Patches
_ -n BE-name
The name of the boot environment to be created. BE-name must be unique
on the system.
In the following example, a new boot environment named solaris2 is created.
The root (/) file system is placed on c0t1d0s4.
# lucreate -n solaris2 -m /:/dev/dsk/c0t1d0s4:ufs
This command generates output similar to the following. The time to complete
varies depending on the system.
Discovering physical storage devices.
Discovering logical storage devices.
Cross referencing storage devices with boot environment configurations.
Determining types of file systems supported.
Validating file system requests.
The device name <c0t1d0s4> expands to device path </dev/dsk/c0t1d0s4>.
Preparing logical storage devices.
Preparing physical storage devices.
Configuring physical storage devices.
Configuring logical storage devices.
Analyzing system configuration.
No name for current boot environment.
Current boot environment is named <solaris1>.
Creating initial configuration for primary boot environment <solaris1>.
The device </dev/dsk/c0t1d0s4> is not a root device for any boot environment.
PBE configuration successful: PBE name <solaris1> PBE Boot Device </dev/dsk/c0t1d0s4>
Comparing source boot environment <solaris1> file systems with the
file system(s) you specified for the new boot environment.
Determining which file systems should be in the new boot environment.
Updating boot environment description database on all BEs.
Searching /dev for possible boot environment filesystem devices.
Updating system configuration files.
The device </dev/dsk/c0t1d0s4> is not a root device for any boot environment.
Creating configuration for boot environment <solaris2>.
Source boot environment is <solaris1>.
Creating boot environment <solaris2>.
Creating file systems on boot environment <solaris2>.
Creating <ufs> file system for </> on </dev/dsk/c0t1d0s4>.
Mounting file systems for boot environment <solaris2>.
Calculating required sizes of file systems for boot environment <solaris2>.
Populating file systems on boot environment <solaris2>.
Checking selection integrity.
Integrity check OK.
Populating contents of mount point </>.
Copying.
Creating shared file system mount points.
Creating compare databases for boot environment <solaris2>.
Creating compare database for file system </>.
Updating compare databases on boot environment <solaris2>.
Making boot environment <solaris2> bootable.
Population of boot environment <solaris2> successful.
Creation of boot environment <solaris2> successful.
From the Library of Daniel Johnson
4.4 EXAMPLE OF USING SOLARIS LIVE UPGRADE TO INSTALL PATCHES 83
10. (Optional) Verify that the boot environment is bootable.
The lustatus command reports if the boot environment creation is
complete and if the boot environment is bootable.
11. Apply patches to the boot environment.
The patches you apply can come from several sources. The following example
provides steps for installing patches from the SunSolve database. However,
the procedure can be used for any patch or patch bundle, such as
patches from custom patch bundles, Sun Update Connection enterprise
patches, the Enterprise Installation Services CD, or security patches.
a. From the SunSolve Web site, obtain the list of patches at
http://sunsolve.sun.com.
b. Create a directory such as /var/tmp/lupatches.
c. Download the patches to that directory.
d. Change to the patch directory.
# cd /var/tmp/lupatches
e. Apply the patches.
The luupgrade command syntax follows:
# luupgrade -n BE-name -t -s path-to-patches patch-name
The options for the luupgrade command are explained in the following list:
– -n BE-name
Specifies the name of the boot environment where the patch is to be added.
– -t
Indicates to add patches to the boot environment.
– -s path-to-patches
Specifies the path to the directory that contains the patches to be added.
– patch-name
Specifies the name of the patch or patches to be added. Separate multiple
patch names with a space.
In the following examples, the patches are applied to the solaris2 boot environment.
The patches can be stored on a local disk or on a server.
# lustatus BE-name
boot environment Is Active Active Can Copy
name Complete Now OnReboot Delete Status
------------------------------------------------------------
solaris1 yes yes yes no -
solaris2 yes no no yes -
From the Library of Daniel Johnson
84 Chapter 4 _ Software Management: Patches
This example shows the installation of patches stored in a directory on the
local disk:
This example shows the installation of patches stored on a server:
12. Examine the patch log file to make sure no patch failures occurred.
13. Activate the new boot environment.
# luactivate BE-name
BE-name specifies the name of the boot environment that is to be activated.
See the following documents for more information about activating a boot
environment:
– For an x86 based system, the luactivate command is required when you
boot a boot environment for the first time. Subsequent activations can be
made by selecting the boot environment from the GRUB menu. For stepby-
step instructions, see Solaris 10 8/07 Installation Guide: Solaris Live
Upgrade and Upgrade Planning. Specifically, see the chapter “Activating a
Boot Environment With the GRUB Menu.” The book is available at
http://docs.sun.com.
– To successfully activate a boot environment, that boot environment must
meet several conditions. For more information, see Table 4.3.
# luupgrade -n solaris2 -t -s /tmp/solaris/patches 222222-01 333333-01
# luupgrade -n solaris2 -t -s
/net/server/export/solaris/patch-dir/patches 222222-01 333333-01
Note
The Solaris 10 patchadd command correctly orders patches for you, but Solaris 9 and
earlier releases require patches to be in dependency order. When using the luupgrade
command to apply patches, apply the patches in dependency order, regardless of the
Solaris release you are using. Sun uses dependency order as part of the standard testing
of the luupgrade command, and you can be assured that this order was tested.
From the Library of Daniel Johnson
4.4 EXAMPLE OF USING SOLARIS LIVE UPGRADE TO INSTALL PATCHES 85
14. Reboot the system.
# init 6
The boot environments have switched and the new boot environment is
now the active boot environment.
15. (Optional) Fall back to a different boot environment.
a. (Optional) Verify that the boot environment is bootable.
The lustatus command reports if the boot environment creation is
complete and if the boot environment is bootable.
b. Activate the solaris1 boot environment.
The following procedures work if the boot environment is bootable. If the
new boot environment is not viable or you want to switch to another boot
environment, see Solaris 10 Installation Guide: Solaris Live Upgrade and
Upgrade Planning. Specifically, see the chapter “Failure Recovery,” which
is available at http://docs.sun.com.
_ For SPARC based systems activate the boot environment and reboot:
_ For x86 based systems, reboot and choose the solaris1 boot environment
from the GRUB menu.
Caution
Use only the init or shutdown command to reboot. If you use the reboot,
halt, or uadmin command, then the system does not switch boot environments.
The most recently active boot environment is booted again.
# lustatus BE-name
boot environmentIsActiveActiveCanCopy
name CompleteNowOnRebootDeleteStatus
----------------------------------------------------------
solaris1 yesyesyesnosolaris2
yesnonoyes-
# /sbin/luactivate solaris1
# init 6
From the Library of Daniel Johnson
86 Chapter 4 _ Software Management: Patches
4.5 Patch Automation Tools
In addition to using Solaris Live Upgrade and the patch utilities to patch a system,
a range of higher-level patch automation tools is available. See Table 4.4 for
descriptions of patch automation tools.
GNU GRUB version 0.95 (616K lower / 4127168K upper memory)
+----------------------------------------------+
|solaris1
|solaris1 failsafe
|Solaris2
|solaris2 failsafe
+----------------------------------------------+
Use the ^ and v keys to select which entry is highlighted. Press enter to boot the
selected OS, 'e' to edit the commands before booting, or 'c' for a command-line.
# init 6
Table 4.4 Patch Automation Tools Description
Tool Description
Sun xVM Ops Center Sun’s premier patch management tool. Sun xVM Ops Center provides
patch management to enterprise customers for systems running
the Solaris 8, 9, and 10 releases or the Linux operating systems.
Sun xVM Ops Center also provides OS and firmware provisioning,
inventory, registration, and system management. See the Center’s
Web site at http://www.sun.com/software/products/
xvmopscenter/index.jsp.
Sun xVM Ops Center provides the following tools for managing your
systems:
_ Optimize your maintenance window—Use Sun xVM Ops
Center’s automation to check for dependencies, schedule
update jobs, and stage your updates. You can also create
patch policies to define which updates are applied.
_ Improve security and availability—Make these improvements
by keeping your Solaris and Linux systems updated with
the latest patches. The Sun xVM Ops Center knowledge base
captures all new patches, packages, Sun freeware, and RPMs.
Sun develops and tests all dependencies and then publishes
updated dependency rules to its clients.
From the Library of Daniel Johnson
4.5 PATCH AUTOMATION TOOLS 87
_ Register multiple systems—Register your hardware and
software, or gear, at the same time with the new, quick, and
easy registration client in Sun xVM Ops Center.
_ Manage and organize your registered Sun asset
inventory—Control your inventory by using the gear feature
in Sun xVM Ops Center. Update your Solaris, Red Hat, and
SuSE operating systems from a single console.
Patch Check
Advanced (PCA):
A popular third-party tool developed by Martin Paul. PCA generates
lists of installed and missing patches for Solaris systems and optionally
downloads patches. PCA resolves dependencies between
patches and installs them in the correct order. The tool is a good
solution for customers interested in an easy-to-use patch automation
tool.
To try PCA, run these commands on any Solaris system:
1. $ wget
http://www.par.univie.ac.at/solaris/pca/pca
2. $ chmod +x pca
3. $ ./pca
smpatch command
and Update Manager
GUI
Both the smpatch command and Update Manager GUI are tools
that are included in the Solaris OS.
_ smpatch is a command-line tool. This command enables you
to analyze and update the Solaris OS with current patches.
_ The Update Manager GUI is based on the smpatch command.
You can check which patches or updates are available
or you can easily select the patches to install. To display the
GUI, run update manager.
For both of these tools, support from Sun is the following:
_ For customers with a valid support contract, all patches are
available.
_ For customers without a valid support contract, only security
and driver patches are available.
continues
Table 4.4 Patch Automation Tools Description (continued )
Tool Description
From the Library of Daniel Johnson
88 Chapter 4 _ Software Management: Patches
4.6 Overview of Patch Types
Table 4.5 describes the specific types of patches that you can apply.
Enterprise Installation
Standards (EIS)
Enterprise Installation Standards (EIS) originated from Sun field
personnel’s goal of developing best practices for installation standards
for systems installed at customer sites.
EIS has traditionally been available only through Sun field personnel
but is now available directly to customers from xVM OPs Center as
baselines. Baselines provide a good option for customers who want
to patch to a defined and tested patch baseline.
The EIS set of patches is based on the Recommended Patch Cluster
with additional patches included by the field engineers. These additional
patches include products or patches to address issues that do
not meet the criteria for inclusion in the Recommended Patch Cluster.
The EIS patch baseline covers the Solaris OS and other products
such as Sun Cluster, Sun VTS, System Service Processor (SSP), System
Management Services (SMS), Sun StorEdge QFS, and Sun
StorEdge SAM-FS. The baseline also includes patches that provide
firmware updates.
The EIS patch baseline is tested by QA prior to release. The images
installed on servers by Sun’s manufacturers are also based on the EIS
patch baseline. Additional testing by Sun’s manufacturers as well as
feedback from the EIS user community raises confidence in the EIS
patch baseline content. Because many system installations worldwide
use the EIS methodology, any inherent problems quickly
appear and can be addressed. If problems arise with the EIS patch
baseline, recommendations are communicated to the EIS community.
Sun field engineers consider installing the EIS set of patches on
a new system a best practice. This set can also be used to patch
existing systems to the same patch level.
Table 4.5 Description of 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.
Table 4.4 Patch Automation Tools Description (continued )
Tool Description
From the Library of Daniel Johnson
4.6 OVERVIEW OF PATCH TYPES 89
Deferred-
Activation
patches
Starting with patch 119254-42 and 119255-42, the patch installation
utilities–patchadd and patchrm–have been modified to change the
way that certain patches delivering features are handled. This modification
affects the installation of these patches on any Solaris 10 release.
These “deferred-activation“ patches better handle the large scope of
change delivered in feature patches.
A limited number of patches are designated as a deferred-activation
patch. Typically a deferred-activation patch is a kernel patch associated
with a Solaris 10 release after the Solaris 10 3/05 release, such as the
Solaris 10 8/07 release. Patches are designated a deferred-activation
patch if the variable SUNW_PATCH_SAFE_MODE is set in the pkginfo
file. Patches not designated as deferred-activation patches continue to
install as before. For example, previously released patches, such as kernel
patches 118833-36 (SPARC) and 118855-36 (x86), do not use the
deferred-activation patching utilities to install.
Previously, complex patch scripting was required for these kernel patches.
The scripting was required to avoid issues during the patch installation
process on an active partition because of inconsistencies between the
objects the patch delivers and the running system (active partition). Now,
deferred-activation patching uses the loopback file system (lofs) to
ensure the stability of the running system. When a patch is applied to the
running system, the lofs preserves stability during the patching process.
These large kernel patches have always required a reboot, but now
the required reboot activates the changes made by the lofs. The patch
README provides instructions on which patches require a reboot.
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 the SunSolve Web site at
http://sunsolve.sun.com. Find the “Patches and Updates” section
and then the “Patch Documents and Articles” section. The text
coverage is in the section “Testing Overview.”
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.
continues
Table 4.5 Description of Patch Types (continued )
Patch type Description
From the Library of Daniel Johnson
90 Chapter 4 _ Software Management: Patches
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.
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.
On the SunSolve Web site, find the “Security Resources” section. See the
“Security T-Patches and ISRs” or “Sun Security Coordination Team”
sections.
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, then 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.
For more details, see the “Patch Rejuvenation” article on the SunSolve
Web site at http://sunsolve.sun.com. Click on the “Patches and
Updates” section, then see the “Documents Relating to Updating/
Patching” section.
Point patch A custom patch. This patch is provided to a customer 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.
Table 4.5 Description of Patch Types (continued )
Patch type Description
From the Library of Daniel Johnson
4.6 OVERVIEW OF PATCH TYPES 91
Restricted patch
(R-patch)
A rare patch that has a special lock characteristic. An R-patch locks the
package modified. This lock prevents subsequent modification of the
package by other patches.
R-patches are used in circumstances 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 provides
preliminary, temporary relief for an issue. An IDR is provided in a patch
format similar to an R-patch. However, 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 is
practical.
For more details, see the “Interim Relief/Diagnostics” article on the Sun-
Solve Web site at http://sunsolve.sun.com. Click the “Patches
and Updates” section and then see the “Documents Relating to
Updating/Patching” section.
Interim Security
Relief (ISR)
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 at http://sunsolve.sun.com. Information
about the issues addressed by an ISR and possible workarounds is
available through the Free Security Sun Alert data collection. On the
SunSolve site, in the “Security Resources” section, see the “Sun Security
Coordination Team” section.
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’s README file. A nonstandard patch typically delivers firmware
or application software fixes.
continues
Table 4.5 Description of Patch Types (continued )
Patch type Description
From the Library of Daniel Johnson
92 Chapter 4 _ Software Management: Patches
Withdrawn patch If a released patch is found to cause serious issues, then the patch is
removed from the SunSolve Web site.
_ The patch is no longer available for download.
_ The README file remains on the SunSolve Web site. The README
file is changed to state that the patch is withdrawn and a brief
statement is added about the problem and why the patch was
removed.
_ The patch is logged for a year in the list of withdrawn patches. On
the SunSolve Web site, click the “Patches and Updates” section,
then see the “Patch Reports” section for the “Withdrawn Patch
Report.”
_ A Sun Alert is released to notify customers about the withdrawn
patch. 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.
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’s 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 release.
An Update release consists of all the packages in 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 the Sun-
Solve Web site. These patches are called script patches. Script patches
do not deliver bug fixes or new features, but they 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.
Genesis patch A rare patch that installs a new package.
Generally, new packages are only available as part of a new release of a
product. Patches only change the content of packages already installed
on a system. However, in rare cases, new packages can be installed on a
system by applying a genesis patch. For example, patch 122640-05 is a
genesis patch that delivers and installs ZFS packages. This patch contains
new ZFS packages that are installed on systems with older Solaris
10 releases that do not contain the new ZFS functionality.
Table 4.5 Description of Patch Types (continued )
Patch type Description
From the Library of Daniel Johnson
4.7 PATCH README SPECIAL INSTRUCTIONS 93
4.7 Patch README Special Instructions
Patches have associated metadata that describes their attributes. 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.
4.7.1 When to Patch in Single-User Mode
You can avoid booting to single-user mode by using Solaris Live Upgrade. You can
also avoid system downtime. Solaris Live Upgrade enables patches to be installed
while your system is in production. 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.
If you cannot use Solaris Live Upgrade, then 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 instructions in the patch’s README file
should be followed. 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, then you significantly increase your
risk of the system experiencing an inconsistent state.
The patch properties apply to both installing and removing patches. If singleuser
mode was required for applying the patch, then you should also use singleuser
mode for removing a patch. Changes being made to the system are equally
significant, irrespective of the direction in which they’re being made, for example,
installing instead of removing.
You can safely boot into single-user mode by changing the run level with the
init command.
_ Using the init S command does not quiesce the system enough 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. However, this
command requires a reboot.
From the Library of Daniel Johnson
94 Chapter 4 _ Software Management: Patches
4.7.2 When to Reboot After Applying or Removing a Patch
If a patch requires a reboot, then you cannot avoid the reboot. Sooner or later, you
must reboot to enable the changes that the patch introduced. However, you can
choose a strategy to defer the reboot until a more convenient time.
_ One method is to use Solaris Live Upgrade, which enables patches to be
installed while your system is running. You can avoid single-user mode and
use multiuser mode. Then, you simply reboot into the patched environment at
a more convenient time.
_ Another approach with similar benefits to Solaris Live Upgrade is to use
RAID-1 volumes (disk mirroring) with Solaris Volume Manager. For example,
you can split the mirror, mount the inactive root (/) file system mirror, and
apply the patches to the copy by using 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 the option can
also be used to delay the reboot.
The 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 you are patching an active boot environment, then a reboot is needed to
activate certain objects that have been patched, like 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
Note
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, you can use the lucreate
command to 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.
From the Library of Daniel Johnson
4.7 PATCH README SPECIAL INSTRUCTIONS 95
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. However, 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 they are
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’s README file. 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 be automatically installed in deferred-activation patching
mode by the patchadd command. Objects updated by using deferredactivation
patching will be activated upon reboot of the system.
4.7.3 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
available at http://docs.sun.com:
_ See the patchadd command -G option.
_ See System Administration Guide: Solaris Containers-Resource Management
and Solaris Zones. Specifically, see the chapter “About Packages and Patches
on a Solaris System With Zones Installed (Overview).”
From the Library of Daniel Johnson
96 Chapter 4 _ Software Management: Patches
4.8 Patch Dependencies (Interrelationships)
The functionality delivered in a patch, consisting of 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 the 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. Therefore, this patch cannot be installed on the same system.
These fields are used by the patchadd and patchrm commands to automatically
ensure the consistency of the target system that is being patched. These fields are
included in the patch README file.
4.8.1 SUNW_REQUIRES Field for Patch Dependencies
The SUNW_REQUIRES field 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, then the patch specifies
the required patches in the SUNW_REQUIRES field in the pkginfo file in the
patch’s packages. This information is also 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, then they are specified in the patch’s
README file and can include the following:
_ Conditional dependencies indicate 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.
From the Library of Daniel Johnson
4.8 PATCH DEPENDENCIES (INTERRELATIONSHIPS) 97
4.8.2 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-coded 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 accumulation 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.
4.8.3 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, then only one of the patches can be installed on the target
Note
For 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 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.
From the Library of Daniel Johnson
98 Chapter 4 _ Software Management: Patches
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.
From the Library of Daniel Johnson
![浅谈---测试Native Windows Command与Native PowerShell Command哪个效率高[图]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)