This chapter describes information you need to be aware of before you
install a patch kit.
It also describes the steps to take for tasks such as
performing a preinstallation check and a baselining operation.
2.1 Performing a Patch Preinstallation Check
To minimize system down time, you can perform the preinstallation check on a system running in multiuser mode, even if you will perform the actual installation in single-user mode.
The example in this section shows a preinstallation check that results
in a patch that fails the check and is prevented from being installed.
If
this occurs, you would set the system patch baseline, as described in
Section 2.2.
If patches are prevented from being installed because
dependent patches were not selected, choose the
select patches again
item and add the required patches that are missing.
If no patches are blocked, you can proceed to the installation phase, as described in Chapter 3.
Note that the menu you see will differ slightly, depending upon whether you log in from a pseudo-terminal or a system console. The following steps assume you logged in from a pseudo-terminal.
Log in as root.
From the main
dupatch
menu, enter
1
at the
Enter your choice
prompt:
Tru64 UNIX Patch Utility (Rev. 48-00) ========================== - This dupatch session is logged in /var/adm/patch/log/session.log Main Menu: --------- 1) Patch Kit Installation 2) Patch Kit Deletion 3) Patch Kit Documentation 4) Patch Tracking 5) Patch Baseline Analysis/Adjustment h) Help on Command Line Interface q) Quit Enter your choice: 1
The program responds with the Patch Installation Menu.
Enter
1
at the
Enter your choice
prompt:
Patch Installation Menu: ------------------------ 1) Pre-Installation Check ONLY 2) Check & Install in single-user mode w/ network services 3) Check and Install in Multi-User mode b) Back to Main Menu q) Quit Enter your choice: 1 Enter path to the top of the patch distribution, or enter "q" to get back to the menu : ./patch_kit Tru64 Unix License Agreement
.
.
.
To read the license again, type 'license'. Do you accept the license agreement? (y/n) : y Checking patch kit for transmission errors during download... Finished Checking patch kit checksums Gathering patch information... (depending upon the size of the patch kit, this may take awhile) *** Start of Special Instructions ***
.
.
.
*** End of Special Instructions *** Press RETURN to proceed...
You have the option to make the patches reversible so you
can revert the system to its state prior to the installation of a patch.
The
dupatch
utility lists the following information.
Press Return at
the prompt to make the patches reversible.
This is the recommended action.
------------------------------------------------------------------------ To Make Patches Reversible - PLEASE READ THE FOLLOWING INFORMATION: - You have the option to make the patches reversible so you can revert the system to its state prior to the installation of a patch. - Reversibility is achieved by compressing and saving a copy of the files being replaced by the patches. These files would be restored to the system if you choose to delete a patch. - If you choose to make patches NON-reversible, then the system cannot be restored to the state prior to the installation of a patch; you will not be able to delete the patches later. - This patch kit may force a small set of patches to be reversible to ensure your upgrades to future versions of Tru64 UNIX are successful. The Patch Utility will make those patches reversible automatically. Refer to the Release Notes / Installation Instructions provided with this patch kit. Do you want the patches to be reversible? [y]: y By default, the backup copies of the installed patches will be saved in "/var/adm/patch/backup". If you have limited space in /var, you may want to make the backup directory the mount point for a separate disk partition, an NFS mounted directory, or a symbolic link to another file system. You must ensure the backup directory is configured the same way during any patch removal operations. Your current setup of "/var/adm/patch/backup" is: * A plain directory (not a mount point or a symbolic link)
By default, the backup copies of the installed patches
will be saved in
/var/adm/patch/backup
.
If you have limited
space in
/var
, you may want to make the
backup directory the mount point for a separate
disk partition, an NFS-mounted directory, or a symbolic link to another file
system.
Answer
yes
when asked if you want to perform
the preinstallation check with this setup:
Do you want to proceed with the pre-installation check with this setup? [y]: y
Enter your name and any information that you want to appear in the preinstallation check log:
Your name: Betty Enter any notes about this operation that you would like stored for future reference (To end your input, enter a "."): : preinstall check for patch kit 5 : .
The program lists any patches that fail the prerequisite and applicability checks, and asks how you want to proceed. You have the following choices:
Checking patch prerequisites and patch file applicability... (depending upon the number of patches you select, this may take awhile) *** The Patch Kit will install 80 patches *** ------------------------------------------------------------------------- Problem installing: - Tru64_UNIX_V5.1B / Kernel Patches: Patch 26009.00 - SP05 OSFBASE540 (SSRT3631 SSRT3469 SSRT2439 ...) ./usr/sbin/cron: is installed by Customer Specific Patch (CSP): - Tru64_UNIX_V5.1B: Patch C 00981.00 and can not be replaced by this patch. To install this patch, ideally, you must first remove the CSP using dupatch. Before performing this action, you should contact your HP Service Representative to determine if this patch kit contains the CSP. If it does not, you may need to obtain a new CSP from HP in order to install the patch kit and retain the CSP fix. or you may use dupatch baselining to enable the patch installation. This patch will not be installed. ------------------------------------------------------------------------- * The following 1 patch(es) failed in prerequisite/file applicability check: - Tru64_UNIX_V5.1B / Kernel Patches: Patch 26009.00 - SP05 OSFBASE540 (SSRT3631 SSRT3469 SSRT2439 ...) * There were 1 patch(es) which failed in prerequisite/file applicability check: Press Return to go back to the previous menu
The
dupatch
baselining process looks at the files installed on a system,
compares them to the files it expects to find, and prevents the installation
of any patch files that might cause an incompatibility among system files.
This section provides an overview of the baselining process.
See
Section 2.2
for instructions on setting a baseline.
Unknown system files occur when the files are replaced through non-standard system file installation methods such as the following:
The manual installation of system files such as system administration customizations or manually installed patches
Using the
setld
utility to install system
files from user-derived
setld
subsets
Using the
setld
utility to install files
for layered software products
Changes that result from weak system control programs (usually
named
file.scp
)
Missing system files result from a root user manually deleting system
files that were installed during a standard full or update installation procedure
or with the
dupatch
utility.
The file is removed but the
system inventory records are still in place.
Unknown and missing system files will block patch installations until you take corrective action. However, before taking any action, it is important that you understand the origin of the unknown system files or why missing files are no longer present on your system. Changing the system without this knowledge could leave your operating system or layered product software environment in an inconsistent and nonoperational state.
For example, a file whose origin is unknown that is blocking the installation of a Release patch could be part of a manually installed Customer-Specific Patch (CSP) that is not contained in the Release patch. Removing that one file will disrupt the operation of your CSP and possibly the operation of the system.
When you run the
dupatch
system baseline feature,
a baseline log file is captured in
/var/adm/patch/log/baseline.log
.
(See
Appendix A
for information about log files.)
You may need to set the patch baseline for your system if you have
manually installed system files or if
dupatch
informs you
that patch installation is blocked by system files that are missing or unknown.
Warning
Misusing the baselining feature can cause serious problems with your system. It is important to be aware of the following potential problems:
Enabling baselining to override its applicability checking could leave your operating system or layered product software environment in an inconsistent and nonoperational state.
Enabling baselining to update your system sets a new baseline for your operating system or TruCluster software environments. You will not be able to revert to the previous system state for manually installed patches that were marked as installed by baselining.
We recommend that you backup your
/
,/usr
, and/var
file systems before enabling system updates throughdupatch
baselining.
Baselining is divided into seven phases that provide system information
and optionally allow you to take actions that change the patch baseline of
your system.
You can run through all phases of baselining to get the system
analysis without enabling changes to your system.
You can run baselining in
multiuser mode when you are the root user.
2.2.1 Phase 1 - System Evaluation
The primary goal of Phase 1 is to evaluate your system relative to the patch kit that is being installed. However, the baselining feature will report all missing and unknown files to assist you in better understanding the state of the changed files on the system.
The rest of the baselining phases use the information gathered in Phase 1 to inform you of any installation conflicts for patches contained in the patch kit.
The amount of time needed to evaluate the state of the system varies
depending on the size of the patch kit, the version of the software product,
and the performance of the system.
2.2.2 Phase 2 - Patch Layered Product Conflicts
Phase 2 reports information for patches whose installation is blocked by system files that were installed by layered products.
Baselining will not override layered product patch installation collision detection mechanisms as it is likely that the layered product or application customizations are not contained in the patch. Installation of the patch in this situation would leave the layered product or application nonoperational.
To resolve this situation, contact your layered product or application
Customer Services or HP Services if you have purchased Business
Critical Services.
2.2.3 Phase 3 - Identifying Manually Installed Patches
Phase 3 reports patches that exactly match existing files on your system
that are not marked as
installed
by the system inventory.
For example, in earlier kits, TruCluster software Release patches were installed
manually.
This phase will report any manually installed Release patch files
that exactly match a patch contained in the current
dupatch
-based TruCluster software
patch kit.
You can optionally enable
dupatch
to mark these patches
as
installed, which involves copying valid
setld
database information to your system.
The
dupatch
utility will copy the appropriate
patch_subset.inv
,
patch_subset.scp
, and
patch_subset.ctrl
files into place for these patches.
If you do not want to enable
dupatch
to mark these
patches as installed, you must manually remove the patched system files so
the normal
dupatch
installation can install the affected
patches.
2.2.4 Phase 4 - Handling Missing or Unknown Files on Your System
Phase 4 reports information about any unknown and missing system files. These files should be considered as intentional customizations which are important to correct system operation. As such, care should be taken to understand why system files have been customized.
Before enabling any patch installations in Phase 5, review the information reported in Phase 4 against your log of manual system changes to ensure you understand why the system was intentionally customized and to determine how to proceed. In some cases you may need to remove customizations to ensure proper system operation.
To assist you in identifying the origin of changed system files, baselining now reports all missing or unknown system files.
The following sections provide general guidance for some of the normal
situations where system files are intentionally customized manually.
2.2.4.1 Manually Installed CSPs
In response to a problem report, you may receive a manually installable CSP from your service provider. CSPs are a set of compatible files that deliver fixes to the problems you reported. Additionally, the patch may include instrumentation necessary for debugging purposes.
If your system was customized through a manual installation of CSPs,
you must ensure that the fixes delivered by the CSPs are included in the current
Release Patch Kit before enabling
dupatch
to overwrite
any unknown or missing system files.
Warning
If you are unsure if the CSP is included in the Release Patch Kit, do not enable
dupatch
to overwrite the manually installed CSP. If you must install the Release patch being blocked by a CSP, contact your service provider for assistance.
If the unknown or missing files are attributable to manually installed CSPs that are included in a Release Patch Kit, perform one of the following steps:
If all CSP files are overwritten by the patches noted in Phase
5, you can safely enable
dupatch
to overwrite applicable
missing or unknown system files.
If some of the CSP files are not overwritten by the patches noted in Phase 5, contact your service provider for assistance.
To determine if your CSP is included in the Release Patch Kit, refer
to the
Patch Summary and Release Notes
for the Release Patch Kit.
See
Patch Process Resources
and
Related Documentation
for information about viewing patch
documentation on the Web.
2.2.4.2 Manually Installed Release Patches
For some software products, manual installation has been the practiced method for patch installation. For example, patches for TruCluster software used to be installed manually.
You must determine whether the fixes delivered by the manually installed
Release patches are included in the current
dupatch
-based
Release Patch Kit before enabling
dupatch
to overwrite
any unknown or missing system files.
Once you have made this determination,
proceed as follows:
If the unknown or missing system files are attributable to
the manual installation of Release patches and those patches are included
in the current
dupatch
-based Release Patch Kit, you can
safely enable
dupatch
to overwrite applicable missing or
unknown system files.
If the unknown or missing system files are not attributable to manual installation, you must understand the origin of the unknown or missing system files by reviewing the information reported in Phase 4 against your log of manual system changes to ensure you understand why the system was intentionally customized, and to determine how to proceed.
2.2.4.3 User Customized Commands and Utilities
Periodically, system administrators of production computing environments replace Tru64 UNIX commands or utilities with freeware or their own customized version of the command or utility. In this situation you must ensure the unknown or missing files are attributable to intentional replacement of commands, utilities, or other system files.
If the unknown or missing system files are attributable to the replacement
of commands, utilities, or other system files with customized versions for
the computing environment, do not enable
dupatch
to overwrite
the manually installed customized files.
Instead, determine the reason for
the customization and then decide how to proceed.
2.2.5 Phase 5 - Enabling dupatch to Overwrite Changed System Files
Phase 5 reports patches that are blocked due to missing or unknown system
files, and optionally allows you to override the
dupatch
conflict management mechanism so the
dupatch
-based patch
may be installed.
For each patch that is blocked by a missing or unknown system file you are presented with the following information:
Software product identifier
Patch category
Patch identifier
Patch subset description
The list of unknown and missing files that block the patch installation
The origin of all other files contained in the patch
Optionally, you can enable
dupatch
to override the
collision detection mechanisms and install any of these patches.
Use the missing
and unknown file information presented in Phase 4 and your system administration
log of manual system changes to make Phase 5 patch installation enabling decisions.
We recommended that you do not enable
dupatch
to
install patches over missing or unknown system files for which you do not
know the origin.
Doing so may leave your operating system and TruCluster software
environment in an inconsistent and nonoperational state.
We also recommend that you backup your operating system prior to the
actual patch installation.
2.2.6 Phase 6 - Report CSPs with Inventory Conflicts
Phase 6 provides the information about patches that have inventory conflict
due to certain CSPs that are installed on the system.
You will use this information
when considering your decision in Phase 7.
2.2.7 Phase 7 - Enable patches with File Applicability Conflicts
Phase 7 allows you to install patches whose inventory does not match the installed system when the system file changed originates from a CSP.
Failing to determine the origin of the files that are in conflict can cause your operating system to be compromised. We therefore recommend that you track down the origin of those files.
To assist you in this effort, this phase lists the additional files
that have been installed with the files that cannot be superseded.
You can
run through this phase to get the analysis without enabling the installation
of any of the listed patches.
2.2.8 Steps for Running the Baseline Procedure
The following steps begin the baseline procedure:
Log in as root.
Run
dupatch
and enter
5
in response to the
Enter your choice
prompt of the Main
Menu:
Tru64 UNIX Patch Utility (Rev. 48-00) ========================== - This dupatch session is logged in /var/adm/patch/log/session.log Main Menu: --------- 1) Patch Kit Installation 2) Patch Kit Deletion 3) Patch Kit Documentation 4) Patch Tracking 5) Patch Baseline Analysis/Adjustment h) Help on Command Line Interface q) Quit Enter your choice: 5
Enter the location of the patch distribution:
Enter path to the top of the patch distribution, or enter "q" to get back to the menu [/patches/PK4/patch_kit]:
The baselining procedure then runs through it's seven phases as follows:
Baselining Phase 1 evaluates your system relative to the patch kit.
Baselining Phase 2 reports information for patches whose installation
is blocked by system files that were installed by layered products.
You cannot
enable
dupatch
to install patches that replace system files
installed by layered products.
You must contact your layered product customer
services or HP Services if you have purchased Business Critical
Services.
Baselining Phase 3 reports on patches that match existing
files on your system, but are not marked as
installed
by the system inventory.
You can tell
dupatch
to mark
these patches as
installed.
This involves copying valid
setld
database information to your system.
If exact matches are
found you will be asked the following question:
Do you want to mark these patches as installed ? [y/n]
You must provide an answer; there is no default answer.
Baselining Phase 4 reports information about any unknown or missing system files. This information is provided to assist you in understanding the state of files that may prevent patch installation.
Consider this information carefully when making decisions to override patch-installation checks for patches noted in Phase 5.
Phase 5 reports patches that do not pass installation applicability tests due to the current state of your system. The installation of these patches is prevented by missing or unknown system files.
The
dupatch
utility reports the known information
about the files contained in each patch and asks if you want to enable the
installation:
Do you want to enable the installation of any of these patches? [y/n]:
Answer
n
until you know the origin of the files that
are preventing the patch installation.
The changed system files that are preventing
the Release patch installation may be part of a manually installed Customer-Specific
patch or an intentionally customized utility or file.
If, for example, the file that is preventing the installation of a Release patch is one of many files that are part of a CSP, you must determine how to proceed. For more information, see Section 2.2.4.1 and Section 2.2.5.
If you answer
y
to this question,
dupatch
enables all of the patches to be installed.
Phase 6 reports CSPs that have inventory conflicts.
Some CSPs
replace files delivered in the original operating system inventory or other
layered products' inventory.
The
dupatch
utility blocks
the installation of those patches with inventory conflicts because they can
compromise the integrity of the CSPs.
Press RETURN to see the list of patches... * list of Customer Specific Patches with inventory conflicts: ----------------------------------------------------------- - Tru64_UNIX_V5.1B / Kernel Patches: Patch 26009.00 - SP05 OSFBASE540 (SSRT3631 SSRT3469 SSRT2439 ...) - Files with Customer Specific Patch conflicts are: ./usr/sbin/cron is shipped by: Product: "Tru64 UNIX V5.1B Patch Distribution" (T64KIT0024386-V51BB25-20041206OSF540,06-Dec-2004:04:41:29) Subset: OSFPATC0098100540 - Other file(s) within this patch, with their origin (identified through checksum match) listed in terms of their translated subset information, if any, are: ./etc/.new..magic Base System ./etc/.new..nsswitch.conf Tru64_UNIX_V5.1B Patch 26009.00
.
.
.
Press RETURN to proceed to the next phase...
Phase 7 lists additional files that have been installed with the files in the CSP or layered product that cannot be superseded .
After reviewing this section, you can enable the installation of these patches. Enabling a patch means that the checks for patch file applicability, done during patch installation, will be bypassed if you choose to install that patch:
It is recommended that you understand the origin of the listed files before enabling a patch for installation. Press RETURN to see the list of patches... OSFPATC0098100540 CONFLICTING FILE ./usr/sbin/cron * Enabling a patch for installation means allowing to modify these files. It is recommended that you understand the origin of the listed files before enabling a patch for installation. Do you want to enable the installation of these patches? [y/n]: y *** Installation of the following patches is enabled: (NOTE: You need to include these patches for installation from the installation menu) - Tru64_UNIX_V5.1B / Kernel Patches: Patch 26009.00 - SP05 OSFBASE540 (SSRT3631 SSRT3469 SSRT2439 ...) * Baseline Analysis/Adjustment process completed. ============================================== Press RETURN to get back to the Main Menu...