patchadd - apply a patch package to a system running the Solaris operating system
patchadd [-dun] [-G] [-B backout_dir] [-k keystore] [-P passwd] [-t] [-x proxy] {patch} | {-M patch_location [patch_list]} [-C net_install_image | -R client_root_path | -S service]
patchadd -p [-C net_install_image | -R client_root_path | -S service]
patchadd applies a patch package to a system running the Solaris 2.x operating environment or later Solaris environments (such as Solaris 10) that are compatible with Solaris 2.x. This patch installation utility cannot be used to apply Solaris 1 patches. patchadd must be run as root.
The patchadd command has the following forms:
Starting with version 10 of the Solaris operating system, patchadd performs validity and dependency checking among a collection of patches that you specify with the -M source specifier. See the description of -M under OPERANDS, below.
With respect to zones(5), when invoked in the global zone, by default, patchadd patches all appropriate packages in all zones. Patching behavior on system with zones installed varies according to the following factors:
The interaction of the factors above is specified in "Interaction of -G and pkginfo Variable in Zones," below.
When you add patches to packages on a Solaris system with zones installed, you will see numerous zones-related messages, the frequency and content of which depend on whether you invoke patchadd in a global or local zone, the setting of SUNW_PKG_ALLZONES, and the use of the -G option.
The patch, -M, -C, -R, and -S arguments shown in the SYNOPSIS are described under OPERANDS, following OPTIONS.
The following options are supported:
-B backout_dir
-d
-G
-k keystore
-n
-p
-P passwd
-t
-u
-x proxy
The following operands are supported:
patchadd must be supplied a source for retrieving the patch. Specify sources using the syntax shown below.
patch
-M patch_location [patch_list]
When using a directory as the patch_location, specify that directory as an absolute path name. Specify a URL as the server and path name that contains the spooled patches. The optional patch_list is the name of the file at a specified location containing the patches to be installed.
-M patch_location patch_id [patch_id...]
To use the directory location or URL and the patch number, specify patch_location as the absolute path name of the directory that contains spooled patches. Specify a URL as the server and path name that contains the spooled patches. Specify patch_id as the patch number of a given patch. 104945-02 is an example of a patch_id. 104945-02 is also an example of a patchid in 104945-02.jar.
Note that patchadd does not require a list of patches. Among a collection of patches---residing in a directory, specified in a list, or entered on a command line---patchadd performs validity and dependency checking. Specifically, the command does the following:
Most users will find the easiest way to specify a source for patchadd is to specify only a patch_location containing a set of patches.
By default, patchadd applies a patch to the specified destination. If no destination is specified, then the current system (the one with its root filesystem mounted at /) is assumed to be the destination for the patch. You can specify a destination in the following ways:
-C net_install_image
You should use the -C option only to install patches that are recommended for installation to the miniroot. Patches that are recommended for installation to the miniroot usually include install-related patches such as package commands, and Sun install and patch installation tools. If you apply too many patches to the miniroot it can grow too large to fit into memory during a net installation of Solaris. Use the -B option and the -C option together so the miniroot does not get too large. See -B, above.
Note that in the current release and in certain versions of Solaris 10, the miniroot is compressed. To determine whether the miniroot is compressed on your system, look for a file called sparc.miniroot or x86.miniroot under /boot, on the boot medium. Before you can patch a compressed miniroot, you must perform certains steps. See "Patching a Compressed Miniroot" below.
-R client_root_path
Note -
-S service
The Solaris operating system uses a compressed miniroot. The compressed miniroot was adopted first in Solaris for x86 and then in Solaris for SPARC over the course of Solaris 10 update releases. See below for an easy way to determine whether your Solaris system uses a compressed miniroot.
To patch a system with a compressed miniroot (full or partial), you must unpack and then repack the miniroot before and after running patchadd with the -C destination specifier. Use the procedure shown below and accompanying example commands.
# /boot/solaris/bin/root_archive unpackmedia \ /export/home/altuser/testdir /export/home/altuser/mr
# patchadd -C /export/home/altuser/mr \ /var/sadm/spool/104945-02
# /boot/solaris/bin/root_archive packmedia \ /export/home/altuser/testdir /export/home/altuser/mr
At this point, you can use setup_install_server(1M) to install the patched miniroot on an install server. See root_archive(1M) for a description of that command.
To determine whether a Solaris image uses a compressed miniroot, check for the presence of either an x86.miniroot or sparc.miniroot file under /boot on the boot medium.
The following list specifies the interaction between the -G option and the SUNW_PKG_ALLZONES variable (see pkginfo(4)) when adding a patch in global and local (non-global) zones.
global zone, -G specified
If no packages have SUNW_PKG_ALLZONES set to true: Apply patch to package(s) in global zone only.
global zone, -G not specified
If no packages have SUNW_PKG_ALLZONES set to true: Apply patch to appropriate package(s) in all zones.
local zone, -G specified or not specified
If no packages have SUNW_PKG_ALLZONES set to true: Apply patch package(s) in local zone only.
See the section KEYSTORE LOCATIONS in the pkgadd(1M) man page for details.
See the section KEYSTORE AND CERTIFICATE FORMATS in the pkgadd(1M) man page for details.
The examples in this section are all relative to the /usr/sbin directory.
Example 1 Installing a Patch to a Standalone Machine
The following example installs a patch to a standalone machine:
example# patchadd /var/sadm/spool/104945-02
Example 2 Installing a Patch to a Client From the Server's Console
The following example installs a patch to a client from the server's console:
example# patchadd -R /export/root/client1 /var/sadm/spool/104945-02
Example 3 Installing a Patch to a Service From the Server's Console
The following example installs a patch to a service from the server's console:
example# patchadd -S Solaris_8 /var/sadm/spool/104945-02
Example 4 Installing Multiple Patches in a Single Invocation
The following example installs multiple patches in a single patchadd invocation:
example# patchadd -M /var/sadm/spool 104945-02 104946-02 102345-02
Example 5 Installing Multiple Patches Specifying List of Patches to Install
The following example installs multiple patches specifying a file with the list of patches to install:
example# patchadd -M /var/sadm/spool patchlist
Example 6 Installing Multiple Patches to a Client and Saving the Backout Data
The following example installs multiple patches to a client and saves the backout data to a directory other than the default:
example# patchadd -M /var/sadm/spool -R /export/root/client1 \ -B /export/backoutrepository 104945-02 104946-02 102345-02
Example 7 Installing a Patch to a Solaris 8 or Compatible Version Net Install Image
The following example installs a patch to a Solaris 8 or compatible version Net Install Image:
example# patchadd -C /export/Solaris_8/Tools/Boot \ /var/sadm/spool/104945-02
Example 8 Installing a Patch to a Compressed Miniroot
The following example installs a patch to a compressed miniroot, such as one finds on a Solaris x86 machine that supports GRUB-style booting. This example assumes that /export/Solaris_11/Tools/Boot contains the unpacked miniroot. After applying the patch, the miniroot needs to be repacked
example# patchadd -C /export/Solaris_11/Tools/Boot \ /var/sadm/spool/104945-02
See "Patching a Compressed Miniroot," above, for information on Solaris versions that use a compressed miniroot.
Example 9 Installing a Patch to an Uncompressed Miniroot
The following example installs a patch to a miniroot on a Solaris machine that does not have a compressed miniroot.
example# patchadd -C /export/Solaris_9/Tools/Boot \ /var/sadm/spool/104945-02
See "Patching a Compressed Miniroot," above, for information on Solaris versions that use a compressed miniroot.
Example 10 Displaying the Patches Installed on a Client
The following example displays the patches installed on a client:
example# patchadd -R /export/root/client1 -p
Note the caveat on the use of the -R option in the description of that option, above.
Example 11 Installing a Digitally Signed Set of Patches
The following example installs multiple patches, some of which have been signed, using the supplied keystore, password, and HTTP proxy.
example# patchadd -k /etc/mycerts -P pass:abcd -x webcache.eng:8080 \ -M http://www.sun.com/solaris/patches/latest 101223-02 102323-02
The following exit values are returned:
0
>0
See attributes(5) for descriptions of the following attributes:
|
cpio(1), pkginfo(1), patchrm(1M), pkgadd(1M), pkgadm(1M), pkgchk(1M), pkgrm(1M), setup_install_server(1M), smpatch(1M), showrev(1M), pkginfo(4), attributes(5), grub(5), zones(5)
The following messages might help in determining some of the most common problems associated with installing a patch.
Message
The prepatch script exited with return code retcode. patchadd is terminating.
Explanation and Recommended Action
Message
The signature on patch patch_id was unable to be verified. patchadd is terminating.
Explanation and Recommended Action
Message
The postpatch script exited with return code retcode. Backing out patch.
Explanation and Recommended Action
Message
Insufficient space in /var/sadm/patch to save old files. (For 2.4 systems and previous)
Explanation and Recommended Action
If the user elects not to save the old versions of the files to be patched, patchrm cannot be used. One way to regain space on a system is to remove the save area for previously applied patches. Once the user has decided that it is unlikely that a patch will be backed out, the user can remove the files that were saved by patchadd. The following commands should be executed to remove the saved files for patchpatch_id:
cd /var/sadm/patch/patch_id rm -r save/* rm .oldfilessaved
After these commands have been executed, patch patch_id can no longer be backed out.
Message
Insufficient space in /var/sadm/pkg/PKG/save to save old files. (For 2.5 systems and later)
Explanation and Recommended Action
cd /var/sadm/pkg/pkgabbrev/save rm -r patch_id
After these commands have been executed, patch patch_id can no longer be backed out.
Message
Save of old files failed. (For 2.4 systems and previous)
Explanation and Recommended Action
Message
Pkgadd of pkgname package failed with error code code. See /tmp/log.patch_id for reason for failure.
Explanation and Recommended Action
Message
Pkgadd of pkgname package failed with error code code. Will not backout patch...patch re-installation. Warning: The system may be in an unstable state! See /tmp/log.patch_id for reason for failure.
Explanation and Recommended Action
Message
patchadd is unable to find the INST_RELEASE file. This file must be present for patchadd to function correctly.
Explanation and Recommended Action
Message
A previous installation of patch patch_id was invoked that saved files that were to be patched. Since files were saved, you must run this instance of patchadd without the -d option.
Explanation and Recommended Action
Message
A previous installation of patch patch_id was invoked with the -d option. (i.e. Do not save files that would be patched) Therefore, this invocation of patchadd must also be run with the -d option.
Explanation and Recommended Action
The patch installation messages listed below are not necessarily considered errors, as indicated in the explanations given. These messages are, however, recorded in the patch installation log for diagnostic reference.
Message
Package not patched: PKG=SUNxxxx Original package not installed
Explanation and Recommended Action
For example, suppose a patch fixes a bug in both the online-backup and fddi packages. If you had online-backup installed but didn't have fddi installed, you would get the message :
Package not patched: PKG=SUNWbf Original package not installed
This message only indicates an error if you thought the package was installed on your system. If this is the case, take the necessary action to install the package, backout the patch (if it installed other packages) and re-install the patch.
Message
Package not patched: PKG=SUNxxx ARCH=xxxxxxx VERSION=xxxxxxx Architecture mismatch
Explanation and Recommended Action
Package not patched: PKG=SUNWcar ARCH=sparc.sun4c VERSION=11.5.0,REV=2.0.18 Architecture mismatch Package not patched: PKG=SUNWcar ARCH=sparc.sun4u VERSION=11.5.0,REV=2.0.18 Architecture mismatch Package not patched: PKG=SUNWcar ARCH=sparc.sun4e VERSION=11.5.0,REV=2.0.18 Package not patched: PKG=SUNWcar ARCH=sparc.sun4 VERSION=11.5.0,REV=2.0.18 Architecture mismatch
These messages indicate an error condition only if patchadd does not correctly recognize your architecture.
Message
Package not patched: PKG=SUNxxxx ARCH=xxxx VERSION=xxxxxxx Version mismatch
Explanation and Recommended Action
Package not patched: PKG=SUNWcsu ARCH=sparc VERSION=10.0.2 Version mismatch
This message does not necessarily indicate an error. If the version mismatch was for a package you needed patched, either get the correct patch version or install the correct package version. Then backout the patch (if necessary) and reapply.
Message
Re-installing Patch.
Explanation and Recommended Action
Message
patchadd Interrupted. patchadd is terminating.
Explanation and Recommended Action
Message
patchadd Interrupted. Backing out Patch...
Explanation and Recommended Action
To successfully install a patch to a client or server, patchadd must be issued twice, once with the -R option and once with the -S option. This guarantees that the patch is installed to both the /usr and root partitions. This is necessary if there are both /usr and root packages in the patch.
pkgadd is invoked by patchadd and executes the installation scripts in the pkg/install directory. The checkinstall script is executed with its ownership set to user install, if there is no user install then pkgadd executes the checkinstall script as noaccess. The SVR4 ABI states that the checkinstall shall only be used as an information gathering script. If the permissions for the checkinstall script are changed to something other than the initial settings, pkgadd may not be able to open the file for reading, thus causing the patch installation to abort with the following error:
pkgadd: ERROR: checkinstall script did not complete successfully.
The permission for the checkinstall script should not be changed. Contents of log file for a successfull installation: patchadd redirects pkgadd's output to the patch installation log file. For a successfull installation, pkgadd will produce the following message that gets inserted into the log file:
This appears to be an attempt to install the same architecture and version of a package which is already installed. This installation will attempt to overwrite this package. This message does not indicate a failure, it represents the correct behavior by pkgadd when a patch installs correctly.
This message does not indicate a failure, it represents the correct behavior by pkgadd when a patch installs correctly.
On client server machines the patch package is not applied to existing clients or to the client root template space. Therefore, when appropriate, all client machines will need the patch applied directly using this same patchadd method on the client. See instructions above for applying patches to a client. A bug affecting a package utility (for example, pkgadd, pkgrm, pkgchk) could affect the reliability of patchadd or patchrm, which use package utilities to install and backout the patch package. It is recommended that any patch that fixes package utility problems be reviewed and, if necessary, applied before other patches are applied. Existing patches are:
Solaris 2.5.1 Sparc Platform Edition:
Solaris 2.5.1 Intel Platform Edition:
Solaris 2.6 Sparc Platform Edition:
Solaris 2.6 Intel Platform Edition:
Certain patches are classified as "deferred activation" patches (sometimes with initial capitals, as "Deferred Activation" patches). Under conditions indicated below, such patches require special treatment. A patch's README file specifies whether that patch is of the deferred activation variety. (Search on "Deferred Activation" in the README file.)
If you are installing or removing a patch that uses deferred activation patching, you must check on the following:
exclude:lofs
Then, reboot your system and install or remove the patch. After you have completed the patch operation, uncomment the line cited above, then reboot to resume normal operation.
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |