1    Patch Process Overview

This chapter introduces you to the dupatch utility for installing, removing, and managing patches. See Chapter 3 for instructions on installing and removing patches from the Tru64 UNIX operating system and the TruCluster software products.

1.1    Changes to Patch Kits

Beginning with Version 5.1B Patch Kit 4, Tru64 UNIX patch kits have been modified in several important ways to ensure quality. If you have previously installed Tru64 UNIX patch kits, you will notice the following changes between the old-style kits and the new, inclusive patch kits:

Except for the installation and removal processes, the functions provided by the dupatch utility generally work the same with inclusive patch kits as they do in old-style patch kits. For example, the Patch Tracking and Baselining menus remain the same and work the same in the new style kits as they do in the earlier kits.

The instructions in this manual are the same for earlier kits and for inclusive patch kits. Where the processes differ, each process is explained.

1.2    Using dupatch

All Tru64 UNIX and TruCluster software Release Patch Kits (also referred to as aggregate kits) are installed, removed, and managed using the setld-based dupatch utility, which provides you with menus that step you though the various tasks. The dupatch utility is also used for installing many of the Customer-Specific Patch Kits (CSP) , and Early Release Patch Kits (ERP) . Although the examples and descriptions provided in this manual, in general, refer to Release Patch Kits, the information is similar for CSPs and ERPs that install using dupatch.

The dupatch utility is interactive, but you can also run it from the command line using command options. For information about using the command-line interface, see Appendix D, which includes the dupatch(8) reference page.

For clustered systems running TruCluster Server Version 5.0A or higher, dupatch is run in conjunction with the rolling upgrade (see Chapter 4) or no-roll (see Chapter 5) procedures.

With dupatch, you can perform the following actions:

Because dupatch manages patch interdependencies, direct setld installations (setld -l) and deinstallations (setld -d) are disabled.

Many of the dupatch operations generate log files that record the step-by-step procedures performed during the operation. For information about log files see Appendix A.

1.3    Patch Applicability

Patch applicability to the existing system files is done on a file-by-file basis for each patch. This ensures that the installation of a patch will not degrade or crash the system. The installation of a patch is blocked if any system files to be replaced by a patch are not valid predecessors of the patch files.

Patch applicability also enables consistency checking and reporting for the installation of Tru64 UNIX and TruCluster software patches.

In cases where a patch is blocked, informative messages are provided to assist you in determining how to proceed. Appendix B lists common error messages and suggested corrective actions.

The installation of a patch is blocked if any of the following conditions exist:

1.4    Patch Reversibility

By default, Release Patch Kits are made reversible during the installation so you revert your system to its state prior to the installation. If you choose to make patch kits nonreversible, you will not be able to uninstall the kit.

Customer-Specific patch kits are forced to be reversible when the CSP kit is manufactured. This forced reversibility overrides the reversibility option provided by dupatch during installation.

Patch reversibility is dependent upon saving the existing system files that will be updated by the patch. Saving these files requires the availability of adequate storage space in /var/adm/patch/backup, which can be a mount point for a separate disk partition, an NFS mount point, or a symbolic link to another file system. This allows you to configure your system to reduce the impact on system disk space for the /, /usr, and /var partitions.

The dupatch utility checks for the required storage space prior to patch installation. Patch installation is prevented if adequate backup space is unavailable.

1.5    Viewing the Patch Information

When you select the Patch Documentation item of the main menu, dupatch returns a menu that gives you access to different information:

The following output shows the Patch Documentation menu and a typical session:

    Patch Documentation Menu:
    ------------------------
 
     Installed patches on the system
    1)  View problem summaries 
    2)  View full descriptions 
    3)  View special instructions 
    4)  View Problem Report Identifiers 
    5)  View Revision Control Strings 
     Patches in the patch kit
    6)  View problem summaries
    7)  View full descriptions
    8)  View special instructions
    9)  View Problem Report Identifiers
   10)  View Revision Control Strings
     All (installed and non-installed) patches
   11)  View patch problem summaries
   12)  View patch full descriptions
   13)  View patch special instructions
   14)  View Problem Report Identifiers 
   15)  View Revision Control Strings
 
    b)  Back to Main Menu
    q)  Quit
 
Enter your choice: 6
 
    Patch Documentation Selection Menu:
    -----------------------------------
 
    1)  List Release problem summaries
    2)  List Customer Specific problem summaries
    3)  List All problem summaries
 
    b)  Back to Documentation 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  [/patches/pk4/patch_kit]: [Return]
 
     There may be more patches than can be presented on a single
     screen. If this is the case, you can choose patches screen by screen
     or all at once on the last screen. All of the choices you make will
     be collected for your confirmation before any patches are examined.
 
 - Tru64_UNIX_V5.0A / Cluster Kernel Patches:
     1) Patch 00090.00 - versw command can core dump during rolling upgrade     
     2) Patch 00186.00 - Disks can become inaccessible on a cluster node        
 
 - Tru64_UNIX_V5.0A / Commands, Shells, & Utilities Patches:
     3) Patch 00015.00 - Fixes a problem that occurs in multibyte locales       
     4) Patch 00019

.
.
.

The patch description information and special instructions are conveniently organized in the Patch Summary and Release Notes document that is packaged with each kit.

1.6    Viewing Patch Tracking Information

The dupatch patch-tracking capability lets you view information about installed patches, such as lists of release patches and CSP and ERPs installed on the system and which patch kits you have installed.

For example, the following dupatch output shows the patch tracking menu with the List Installed patches menu item selected:

    Patch Tracking Menu:
    ------------------- 
    1)  List installed patches
    2)  List installed patch files
    3)  List patch kit information for installed patches
    4)  Show Patch History for selected patches
    5)  Show System Patch History 
 
    b)  Back to Main Menu
    q)  Quit  Enter your choice: 1
 
    Patch Tracking Selection Menu:
    ------------------------------
 
    1)  List Release Patches
    2)  List Customer Specific Patches
    3)  List All Patches
 
    b)  Back to Tracking Menu
    q)  Quit
 
Enter your choice: 
 
Gathering details of relevant patches, this may take a bit of time

1.7    Handling Manually Installed System Files with Baselining

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.5 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:

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 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:

Baselining is divided into five 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.

1.7.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 greatly depending on the size of the patch kit, the version of the software product, and the performance of the system.

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

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

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

1.7.4.1    Manually Installed Customer-Specific Patches

In response to a problem report, you may receive a manually installable Customer-Specific patch from your service provider. Customer-Specific patches 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 Customer-Specific patches, you must ensure that the fixes delivered by the Customer-Specific patches 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 Customer-Specific patch is included in the Release Patch Kit, do not enable dupatch to overwrite the manually installed Customer-Specific patch. If you must install the Release patch being blocked by a Customer-Specific patch, contact your service provider for assistance.

If the unknown or missing files are attributable to manually installed Customer-Specific patches that are included in a Release Patch Kit, perform one of the following steps:

To determine if your Customer-Specific patch 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.

1.7.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:

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

1.7.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:

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.

Warning

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.

1.8    Version Switches

A version switch manages the transition of the active version to the new version of an operating system. The active version is the one that is currently in use.

In the old-style patch kits, version switches are controlled by the clu_upgrade -switch command during a rolling patch. See Section 4.10 for more information.

With the new-style kits, you must manually enable the version switch. See Section 3.6.1 for more information