Patch Kit Installation Instructions Copyright (c) 2006 Hewlett-Packard Development Company, L.P. Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. UNIX is a registered trademark of The Open Group. December 2006 Abstract This guide provides instructions for installing, removing, and working with Release patch kits, Customer-Specific patch kits (CSPs), and Early Release patch kits (ERPs) using the dupatch utility, which is included with HP Tru64 UNIX patch kits. The information in this guide provides examples and descriptions for the Inclusive patch kit structure, which was introduced with Version 5.1B-2. If you are working with earlier patch kits, we recommend using the instructions that came with your patch kit. We also provide a guide named Installation Instructions for Pre-Inclusive Patch Kits on the patch documentation Web. See "Patch Process Resources" for information. See the Patch Summary and Release Notes document for the kit you are installing for important information you need to know about when installing or removing the patch kit. The Patch Summary and Release Notes document also provides information about individual patches and information that is specific to a patch kit. ---------------------------------------------------------------------- Table of Contents 1 About This Manual 1.1 Audience 1.2 Changes to This Manual 1.3 Organization 1.4 Related Documentation 1.5 Patch Process Resources 1.6 HP Encourages Your Comments 1.7 Typographic Conventions 1 Patch Process Overview 1.1 Using dupatch 1.1.1 dupatch Overview 1.1.2 Invoking dupatch and Installing New Patch Tools 1.2 Patch Applicability 1.3 Patch Reversibility 1.4 Using the Patch Tracking Menu 1.5 Using the Patch Documentation Menu 1.6 Version Switches 1.7 General Issues and Restrictions 1.7.1 When Single-User Mode Is Recommended 1.7.2 Use Clean Directory for Each Patch Kit 1.7.3 Patching a System Prior to Creating a Cluster 1.7.4 RIS and DMS Unsupported for Patch Installation 1.7.5 Direct setld Installation and Removal of Patch Subsets Is Not Allowed 1.7.6 Limitation for /var/adm/patch/backup Directory Handling 1.7.7 Do Not Enter Ctrl/c During Installation Phase 1.7.8 Removing Patches Containing Customized Files 1.7.9 Release Patches Do Not Automatically Supersede CSPs 1.7.10 Impact on System Upgrades to Later Versions of Tru64 UNIX 1.7.11 Some Patch Kits Cannot Be Removed 1.7.12 Do Not Install Prior NHD Kits on a Patched System 1.7.13 Changes to System May Need to Be Reversed 1.7.14 Script Required When Returning to Pre-Patched System 2 Preparing for the Installation 2.1 Performing a Patch Preinstallation Check 2.2 Creating a Baseline 2.2.1 Phase 1 - System Evaluation 2.2.2 Phase 2 - Patch Layered Product Conflicts 2.2.3 Phase 3 - Identifying Manually Installed Patches 2.2.4 Phase 4 - Handling Missing or Unknown Files on Your System 2.2.5 Phase 5 - Enabling dupatch to Overwrite Changed System Files 2.2.6 Phase 6 - Report CSPs with Inventory Conflicts 2.2.7 Phase 7 - Enable patches with File Applicability Conflicts 2.2.8 Steps for Running the Baseline Procedure 3 Patch Installation and Removal Instructions 3.1 Before You Begin the Installation 3.2 Expanding the Patch Kit Tar File 3.3 Choosing Single-User or Multi-User Mode 3.3.1 Installing Patches from Single-User Mode 3.3.2 Installing Patches from Multi-User Mode 3.4 Common Installation Steps 3.5 Rebuilding the Kernel 3.6 Rebooting the System 3.6.1 In Single-User Mode 3.6.2 In Multi-User Mode 3.7 Post-Installation Actions 3.7.1 Enabling the Version Switch After Installing a New Style Patch Kit 3.7.2 Remove Temporary Directory 3.7.3 Adding the Worldwide Language Support 3.8 Removing Patches 3.8.1 Overview 3.8.2 Important Tasks Required Before Removing Patches and Rebooting System 3.8.3 Running dupatch to Remove Patches 4 Patching a Cluster 4.1 Rolling Upgrade 4.1.1 Rolling Upgrade Supported Tasks 4.1.2 Unsupported Tasks 4.1.3 Rolling Upgrade Procedure 4.1.4 Removing Patches Installed During a Rolling Upgrade 4.1.5 Displaying the Status of a Rolling Upgrade 4.1.6 Undoing a Stage 4.1.7 Rolling Upgrade Commands 4.1.8 Rolling Upgrade Stages 4.1.9 Tagged Files 4.1.10 Version Switch 4.1.11 Rolling Upgrade and Layered Products 4.1.12 Rolling Upgrade and RIS 4.2 No-Roll Patching 4.2.1 Overview 4.2.2 Steps for Running a No-Roll Procedure 4.2.3 Throwing the Version Switch 4.2.4 Removing Patches 4.3 Using the dupclone Script 4.3.1 Benefits and Detriments of Cloning 4.3.2 Performing the Cloned Installation A Viewing Log files B Common Error, Warning, and Informational Messages B.1 Patch Preinstallation Check and Installation Messages B.1.1 Patch Installation Blocked by Unknown System File B.1.2 Patch Installation Blocked by Missing System File B.1.3 Installation Blocked by Layered Product Collision B.1.4 Patch Installation Blocked by Dependencies on Other Patches B.1.5 Patch Installation Blocked by Missing Product Subset B.1.6 Patch Installation Blocked by Disk Space B.1.7 Patch Installation Blocked by Installed Patch or Subset B.1.8 Patch Installation Blocked by an Existing CSP B.1.9 The dupatch Tools Are Outdated B.1.10 Some Patches Must Be Made Reversible B.2 Patch Removal Messages B.2.1 Patch Removal Blocked by Missing Patch Backup Files B.2.2 Patch Removal Blocked by Dependencies on Other Patches B.2.3 No Original Files Restored When Patch Is Removed B.3 TruCluster Specific dupatch Messages B.3.1 System Not Adequately Prepared B.3.2 Rolling Upgrade in Progress (Installation) B.3.3 Rolling Upgrade in Progress (Baselining) B.3.4 Version 5.0 Wave 4 Cluster is Unsupported B.3.5 Patch Removal Fails Because Needed File Is Unavailable B.3.6 Patch Removal Fails Because of a Version Switch B.3.7 dupatch Cannot Create Needed File B.3.8 Insufficient Free Space (File System Full) C Using dupatch from the Command Line C.1 Installing and Removing Release Patch Kits C.2 Deleting a CSP C.3 dupatch Reference Page D Prior Patch Installation Changes D.1 Changes Made in Version 5.1B-2 D.2 Changes Made in Version 5.1B-3 Glossary Index List of Figures 4.1 Rolling Upgrade Flow Chart List of Tables 4.1 Rolling Upgrade Tasks Supported by Version 5.1A and Version 5.1B 4.2 Time Estimates for Rolling Upgrade Stages 4.3 Undoing a Stage 4.4 Stages and clu_upgrade Versions When Performing a Rolling Upgrade from Version 5.1A 4.5 Stages and clu_upgrade Versions When Performing a Rolling Upgrade from Version 5.1B 4.6 Blocking Layered Products List of Examples A.1 Sample Event Log About This Manual Table of Contents 1.1 Audience 1.2 Changes to This Manual 1.3 Organization 1.4 Related Documentation 1.5 Patch Process Resources 1.6 HP Encourages Your Comments 1.7 Typographic Conventions This manual provides instructions for installing and removing patches that are provided by Hewlett-Packard Company in its Tru64(TM) UNIX and TruCluster software products patch kits. It also describes baselining techniques and provides other information for working with patches. The information in this guide provides examples and descriptions for the Inclusive patch kit structure, which was introduced with Version 5.1B-2. If you are working with earlier patch kits, we recommend using the instructions that came with your patch kit. We also provide a guide named Installation Instructions for Pre-Inclusive Patch Kits on the patch documentation Web site. See "Patch Process Resources" for information. [Note] Note: See the Patch Summary and Release Notes document for the kit you are installing for important information you need to know about when installing or removing the patch kit. The Patch Summary and Release Notes document also provides information about individual patches and information that is specific to a patch kit. 1.1 Audience This manual is for those who install and remove patch kits and manage patches after they are installed. 1.2 Changes to This Manual This version introduces the a new tool for installing Tru64 Version 5.1B-4 and higher kits. This installation method, generically referred to as cloning, uses the dupclone tool. See the section "Using the dupclone Script" for a discussion on the benefits of using dupclone and instructions on how to use it. 1.3 Organization This manual is organized as follows: Chapter 1 "Patch Process Overview" Introduces the dupatch utility and describes its features. Chapter 2 "Preparing for the Provides information to be aware of Installation" when installing and removing patches. Chapter 3 "Patch Installation and Describes the procedures for Removal Instructions" installing and removing patches. Chapter 4 "Patching a Cluster" Describes the three methods for installing and removing patches on a systems running the TruCluster Server software: performing a rolling upgrade, performing no-roll patching, and using the the dupclone tool. Appendix A "Viewing Log files" Helps you understand the log files generated by dupatch. Appendix B "Common Error, Warning, Describes error messages you might and Informational Messages" see while installing, removing, or maintaining patches. Appendix C "Using dupatch from the Provides information about using the Command Line" dupatch command-line interface and documents the dupatch(8) reference page. 1.4 Related Documentation In addition to this manual, the following documentation may be helpful in the patching process: o The Patch Summary and Release Notes for the patch kit you are working with. o Technical Updates for Tru64 UNIX Version 5.0 and Higher Patch Kits or Technical Updates for Tru64 UNIX Versions 4.0F and 4.0G, which report any information about restrictions and problems that may have been discovered since the release of these patch kits. o Patching Best Practice o Tru64 UNIX Installation Guide o Tru64 UNIX Cluster Administration o TruCluster Server Cluster Installation See "Patch Process Resources" for Web sites where you can find this documentation. 1.5 Patch Process Resources We provide Web sites to help you with the patching process: o To obtain the latest patch kit for your operating system and cluster go to: http://www.itrc.hp.com/service/patch/mainPage.do o To obtain early release patches (ERPs): http://h30097.www3.hp.com/unix/EarlyReleasePatch-download.html o To view or print patch-related documentation go to: http://h30097.www3.hp.com/docs/patch/ Here you can find patch-specific technical updates, release notes for current and previous patch kits, this installation guide, and other information that can help you with the patching process. o To view or print patch-related documentation go to: http://h30097.www3.hp.com/docs/ Here you can find Tru64 UNIX documentation, TruCluster software product documentation, operating system and other technical updates, and other information to help you with your Tru64 UNIX systems. o To visit the Tru64 UNIX homepage go to: http://h30097.www3.hp.com/ o To visit our main support HP page go to: http://h71025.www7.hp.com/support/home/index.asp 1.6 HP Encourages Your Comments We welcome any comments and suggestions you have on this and other Tru64 UNIX documentation. You can send your comments using the following Web site:http://h30097.www3.hp.com/comments.html 1.7 Typographic Conventions This document uses the following typographical conventions: # A number sign represents the superuser prompt. audit(5) A reference page. The reference page name is audit, and it is located in Section 5. Command A command name or qualified command phrase. User input Commands and other text that you type. Variable The name of a placeholder in a command, function, or other syntax display that you replace with an actual value. device names Operating system versions before Version 5.0 use different names than those of Version 5.0 and higher. In general, this manual uses the Version 5.0 names. For example, where a partition name is represented by /dev/disk/dsk3g, the Version 4.0n name might be /dev/rz3g. Chapter 1 Patch Process Overview Table of Contents 1.1 Using dupatch 1.1.1 dupatch Overview 1.1.2 Invoking dupatch and Installing New Patch Tools 1.2 Patch Applicability 1.3 Patch Reversibility 1.4 Using the Patch Tracking Menu 1.5 Using the Patch Documentation Menu 1.6 Version Switches 1.7 General Issues and Restrictions 1.7.1 When Single-User Mode Is Recommended 1.7.2 Use Clean Directory for Each Patch Kit 1.7.3 Patching a System Prior to Creating a Cluster 1.7.4 RIS and DMS Unsupported for Patch Installation 1.7.5 Direct setld Installation and Removal of Patch Subsets Is Not Allowed 1.7.6 Limitation for /var/adm/patch/backup Directory Handling 1.7.7 Do Not Enter Ctrl/c During Installation Phase 1.7.8 Removing Patches Containing Customized Files 1.7.9 Release Patches Do Not Automatically Supersede CSPs 1.7.10 Impact on System Upgrades to Later Versions of Tru64 UNIX 1.7.11 Some Patch Kits Cannot Be Removed 1.7.12 Do Not Install Prior NHD Kits on a Patched System 1.7.13 Changes to System May Need to Be Reversed 1.7.14 Script Required When Returning to Pre-Patched System This chapter introduces you to the dupatch utility for installing, removing, and managing patches. See Chapter 3 "Patch Installation and Removal Instructions" for instructions on installing and removing patches from the Tru64 UNIX operating system and the TruCluster software products. 1.1 Using dupatch The dupatch utility is provided as an interactive and command-line tool for working with Patch kits. The following sections provide an overview of dupatch and describe the procedure for installing the most current version. If you are familiar with dupatch but have not installed one or more of the most recent patch kits, you may want to review the installation changes that were introduced in those kits as described in Appendix D "Prior Patch Installation Changes"t. 1.1.1 dupatch Overview All Tru64 UNIX and TruCluster software Release Patch 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 (CSPs) , and Early Release Patch Kits (ERPs) . 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 C "Using dupatch from the Command Line", which includes the dupatch(8) reference page. For clustered systems running TruCluster dupatch is run in conjunction with the rolling upgrade (see "Rolling Upgrade") or no-roll (see "No-Roll Patching") procedures. With dupatch, you can perform the following actions: o Install and remove patches. o View patch tracking and management information. o Track current dupatch-installed patches and Customer-Specific patches. o Establish a baseline for systems that had manually installed system files placed on them. o Ensure the correct handling of customized system configuration files so that customizations are not lost (for example, conf.c). These files are also referred to as system-protected files (.new..). o Validate patch applicability to existing system files (collision detection). o View the patch-specific documentation. Because dupatch manages patch interdependencies, direct setld installations (setld -l) and deinstallations (setld -d) are disabled. Most dupatch operations generate log files that record the step-by-step procedures performed during the operation. For information about log files see Appendix A "Viewing Log files". 1.1.2 Invoking dupatch and Installing New Patch Tools After you have made the patch kits available to the system being patched, run dupatch from root or you can change directories to patch_kit, which contains the dupatch utility: From root: # /patches/pk4/patch_kit/dupatch From the patch_kit directory: # cd /patches/pk4/patch_kit # ./dupatch If new patch tools are available they will be loaded and you will see messages similar to the following: * A new version of patch tools required for patch management is now being installed on your system. * Tools updated, invoking the updated Patch Utility... The dupatch utility saves information on the tools that have been loaded to the log file /var/adm/patch/log/Dupatch_load_date.log. (See Appendix A "Viewing Log files" for information about log files.) [Note] Note: To install the latest version of the patch tools, it is important that you run the dupatch utility located in the /patch_kit directory every time you obtain a new patch tar file or a new Tru64 UNIX Patch CD-ROM. See "Installing and Removing Release Patch Kits" for information you need to be aware of when installing from the command line. After the new tools have been loaded, dupatch prompts you for the path to the patch kit files. After you specify the path (or press Return if the patch kit is in your current directory) you will see the main menu. For example: Enter path to the top of the patch distribution, or enter "q" to get back to the menu : /patches/pk4/patch_kit 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.2 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 "Common Error, Warning, and Informational Messages" lists common error messages and suggested corrective actions. The installation of a patch is blocked if any of the following conditions exist: o The underlying software product subset is not installed - for example, if the applicable Tru64 UNIX or TruCluster software release subset is not installed. o The setld inventory is inconsistent with the existing system files. This occurs when an operating system or TruCluster software setld subset is installed and individual operating system files that are part of that subset are moved, deleted, or replaced. o The patch installation is blocked if any existing system files (files that are targeted to be updated by a patch) have changed and cannot be related to previous versions of the patch. This ensures that operating system files that change due to other explicit system administrator action (for example, layered product patches or non-dupatch installed CSP installations) are not inadvertently overwritten. You must take special action, through the baseline feature to enable patch installation in this situation. 1.3 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. "Performing a Patch Preinstallation Check" includes an example of the dupatch output regarding patch reversibility. 1.4 Using the Patch Tracking Menu The dupatch patch-tracking capability lets you view information about installed patches, such as lists of release patches, CSPs, 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 Patches installed on the system: ------------------------------- (depending upon the number of patches you installed, this may take awhile) - Tru64_UNIX_V5.1B / Commands, Shells, & Utilities Patches: Patch 25022.00 - SP04 OSFDCMT540 Patch 25080.00 - SP04 OSFTCLBASE540 Patch 26022.00 - SP05 OSFDCMT540 Patch 26080.00 - SP05 OSFTCLBASE540 - Tru64_UNIX_V5.1B / Common Desktop Environment (CDE) Patches: Patch 25015.00 - SP04 OSFCDEDT540 (SSRT2405) Patch 25016.00 - SP04 OSFCDEMAIL540 :3 Patch 26085.00 - SP05 OSFX11540 (SSRT4831 SSRT4802 SSRT4800 SSRT4721) Patch 26086.00 - SP05 OSFXADMIN540 Press RETURN to get back to the Patch Tracking Menu... 1.5 Using the Patch Documentation Menu When you select the Patch Documentation item of the main menu, dupatch returns a menu that gives you access to different information: o Problem summaries Provide brief descriptions of the problems corrected by the patches. You can view the problems corrected by installed patches or by patches available from a specific kit. o Full descriptions Provide complete descriptions of the problems corrected by the individual patches. You can view the problem descriptions for installed patches or for patches available from a specific kit. o Special Instructions These files describe special instructions you need to be aware of for individual patches. You can view the instructions for installed patches or for patches available from a specific kit. o Report identifiers o Revision control strings 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: 1 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: 3 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.1B / Commands, Shells, & Utilities Patches: 1) Patch 25022.00 - SP04 OSFDCMT540 2) Patch 25080.00 - SP04 OSFTCLBASE540 3) Patch 26022.00 - SP05 OSFDCMT540 4) Patch 26080.00 - SP05 OSFTCLBASE540 - Tru64_UNIX_V5.1B / Common Desktop Environment (CDE) Patches: 5) Patch 25015.00 - SP04 OSFCDEDT540 (SSRT2405) 6) Patch 25016.00 - SP04 OSFCDEMAIL540 :3 - Tru64_UNIX_V5.1B / X11 Patches: 49) Patch 25075.00 - SP04 OSFSER540 50) Patch 25085.00 - SP04 OSFX11540 Or you may choose one of the following options: 55) ALL of the above 56) CANCEL selections and redisplay menus 57) EXIT without examining any patches Enter your choices or press RETURN to redisplay menus. Choices (for example, 1 2 4-6): 1-4 7 Enter the output filename for the problem summaries for installed patches, or < Return> to continue (output to screen): ======================================================== Tru64_UNIX_V5.1B / Commands, Shells, & Utilities Patches: Patch 25022.00 - SP04 OSFDCMT540 A potential security vulnerability has been discovered, where under certain circumstances, system integrity may be compromised. This may be in the form of improper file or privilege management. HP has corrected this potential vulnerability :3 Press RETURN to proceed... 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: q 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 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. With the Inclusive patch kits, you must manually enable the version switch. See "Enabling the Version Switch After Installing a New Style Patch Kit" for more information In the old-style patch kits, version switches are controlled by the clu_upgrade -switch command during a rolling patch. See "Version Switch" for more information. 1.7 General Issues and Restrictions This section provides information you must be aware of when installing or removing patches. Be sure to check the Patch Summary and Release Notes document of the kit you are installing for any issues and restrictions that pertain to that installation. 1.7.1 When Single-User Mode Is Recommended Although you can install patches in multi-user mode, we recommend that you bring down your system to single-user mode when installing patches that affect the operation of the Tru64 UNIX operating system or the product you are patching. If your system must remain in multi-user mode, apply the patches when the system is as lightly loaded as possible. There are no restrictions on performing patch selection and preinstallation checking in multi-user mode. Patch removals can only be done in single-user mode. 1.7.2 Use Clean Directory for Each Patch Kit When installing a patch kit downloaded from the Web, untar the file in a clean directory; that is, one that does not contain files from a previous patch kit. A failure to do this can have adverse consequences when installing the new kit. 1.7.3 Patching a System Prior to Creating a Cluster Patching your system before creating your cluster can save you time, although if you do so, be aware that you cannot then remove the patch kit. The following steps describe how to patch your system before creating a cluster: 1. Install and configure the Tru64 UNIX operating system. 2. Use the setld command to install the TruCluster software kit. If the TruCluster software kit is not loaded before the patch operation, patches for TruCluster software will not be loaded. 3. Patch the system. 4. Use the clu_create command to create the single-member cluster. See the Tru64 UNIX Installation Guide for information about installing the operating system and the TruCluster Cluster Installation manual for information about creating your cluster. 1.7.4 RIS and DMS Unsupported for Patch Installation Remote Installation Services (RIS) and Dataless Management Services (DMS) installations of patches are not supported. However, the patch kit installation mechanism does support network installation via NFS. 1.7.5 Direct setld Installation and Removal of Patch Subsets Is Not Allowed You can install and remove Tru64 UNIX and TruCluster software patches only through dupatch. You cannot directly install or reinstall the patch subsets with setld. This ensures that patch tracking and management are not compromised. 1.7.6 Limitation for /var/adm/patch/backup Directory Handling The patch management utility assumes there is one /var/adm/patch/backup directory per system. It does not handle placement of archived original files for multiple systems in one directory. 1.7.7 Do Not Enter Ctrl/c During Installation Phase Do not enter a Ctrl/c command during the installation phase of the patch kit. [Note] Caution: As with any system update, entering a Ctrl/c during this phase could leave the operating system software environment in an inconsistent and nonrecoverable state. 1.7.8 Removing Patches Containing Customized Files If you use dupatch to remove a patch containing a customized file, messages similar to the following may appear in the session log file, /var/adm/patch/log/session.log: - Tru64_UNIX_V5.1B / Network Patches: Patch 25020.00 - SP04 OSFCLINET540 (SSRT3653 SSRT2384 SSRT2275 ...) Customization found in ./etc/inetd.conf. Before the backup was restored, we had saved a copy of this file in: ./etc/inetd.conf.PreDel_OSFPAT02502000540 Please compare ./etc/inetd.conf with this saved copy. If there are extra customizations you want to keep, you would need to merge them into ./etc/inetd.conf manually. ./etc/inetd.conf.PreDel_OSFPAT02502000540 can be removed afterwards. This message warns you to examine the removed patch for any customized files it may contain, which in this example is the file /etc/inetd.conf. In order to keep those customizations, you will have to manually add them. The following are examples of such customized files: o /usr/var/spool/cron/crontabs/root o /etc/sysconfigtab o /usr/var/adm/sendmail/sendmail.cf 1.7.9 Release Patches Do Not Automatically Supersede CSPs Release patches do not automatically supersede dupatch-based Customer-Specific patches (CSPs). Any Release patch blocked by a CSP will result in a dupatch message. See "Patch Installation Blocked by Installed Patch or Subset " for more information. See the release notes of the new style patch kits for a list of CSPs that are included in those patch kits. The Patch Summary and Release Notes document included with Version 5.1B-2 and higher includes a list of CSPs that were reconciled in the patch kit. 1.7.10 Impact on System Upgrades to Later Versions of Tru64 UNIX In the presence of patches of layered products, certain procedures used to upgrade a system to a later version of Tru64 UNIX can lead to inconsistencies among operating system and layered product objects. [Note] Note: After successfully installing a new version of Tru64 UNIX, you should obtain and install the latest patch kit that is applicable to that version. 1.7.11 Some Patch Kits Cannot Be Removed You cannot remove a patch kit on systems that have New Hardware Delivery 7 (NHD-7) kit installed when either of the following conditions exist: o The patch kit you want to remove was installed before the NHD kit. For example, if you installed Patch Kit 2 and then installed NHD-7, you cannot remove that patch kit. However, if you later installed Patch Kit 4, you can remove that patch kit. o The patch kit was installed with NHD-7. Beginning with the release of Patch Kit 3, patch kits were incorporated into the NHD-7 kits. As a result, when you installed NHD-7, you automatically installed the current patch kit. These patch kits cannot be removed. However, you can remove any subsequent patch kits. For example, if you installed NHD-7 with Patch Kit 4 and later installed Patch Kit 5, you cannot remove Patch Kit 4, but can remove Patch Kit 5. If you must remove the patch kit, the only solution is to rebuild your system environment by reinstalling the Version 5.1B operating system and then restoring your system to its state before you installed NHD-7 with the unwanted patch kit. 1.7.12 Do Not Install Prior NHD Kits on a Patched System Do not install the NHD-5 or NHD-6 kits on your TruCluster system if you have installed this patch kit or earlier patch kits. Doing so may cause an incorrect system configuration. The installation code for these new hardware delivery kits does not correctly preserve some cluster subset files. 1.7.13 Changes to System May Need to Be Reversed If you made the following changes to your system after installing this patch kit, you will have to undo those changes before you can uninstall it: o If you changed your hardware configuration (for example, by adding a new disk), the system configuration that existed prior to installing this patch kit might not recognize the new devices or may not provide the necessary support for them. o If you added new cluster members, the new members will not have an older state to revert to if you attempt to uninstall this patch kit. To uninstall this kit, do the following: 1. Remove all new hardware and new cluster members that you added after installing this kit. 2. Run dupatch to uninstall the patch kit. 3. Verify that the patch kit was successfully uninstalled. You can now add the cluster members you removed and reinstall the hardware you removed, as long as the support for it existed in the pre-patched system. You can also reinstall the patch kit. 1.7.14 Script Required When Returning to Pre-Patched System If removing this patch kit restores your system to a pre-patched state, you must run the script /etc/dn_fix_dat.sh before rebooting your system during the patch-deletion process. This situation would occur if Version 5.1B-4 is the only Tru64 UNIX patch kit installed on your 5.1B system. [Note] Note: Because the no-roll procedure automatically reboots the system after deleting the patches, you cannot use this method to delete this patch kit if doing so returns your system to a pre-patched state. Failing to run this script will result in your system being unable to boot normally. If this occurs, do the following: 1. Boot your system in single-user mode: >>> boot -fl s 2. Run the script: # /etc/dn_fix_dat.sh 3. Reboot normally. If you also need to reverse the version switch as described in "Version Switches", run the /etc/dn_fix_dat.sh script after step 5 in that process. [Note] Note: If during the dupatch installation and deletion processes you see a Special Instruction about running this script, you should ignore that instruction unless your system meets the requirement described here. Chapter 2 Preparing for the Installation Table of Contents 2.1 Performing a Patch Preinstallation Check 2.2 Creating a Baseline 2.2.1 Phase 1 - System Evaluation 2.2.2 Phase 2 - Patch Layered Product Conflicts 2.2.3 Phase 3 - Identifying Manually Installed Patches 2.2.4 Phase 4 - Handling Missing or Unknown Files on Your System 2.2.5 Phase 5 - Enabling dupatch to Overwrite Changed System Files 2.2.6 Phase 6 - Report CSPs with Inventory Conflicts 2.2.7 Phase 7 - Enable patches with File Applicability Conflicts 2.2.8 Steps for Running the Baseline Procedure 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 multi-user 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 "Creating a Baseline". 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 "Patch Installation and Removal Instructions". 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. 1. Log in as root. 2. 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 3. 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 :3 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 *** :3 *** End of Special Instructions *** Press RETURN to proceed... 4. 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. 5. 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 6. 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 : . 7. 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 2.2 Creating a Baseline 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 "Creating a Baseline" 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: o The manual installation of system files such as system administration customizations or manually installed patches o Using the setld utility to install system files from user-derived setld subsets o Using the setld utility to install files for layered software products o 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 "Viewing Log files" 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] Warning! Misusing the baselining feature can cause serious problems with your system. It is important to be aware of the following potential problems: o Enabling baselining to override its applicability checking could leave your operating system or layered product software environment in an inconsistent and nonoperational state. o 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 through dupatch 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 multi-user 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] 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: o 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. o 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: o 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. o 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: o Software product identifier o Patch category o Patch identifier o Patch subset description o The list of unknown and missing files that block the patch installation o 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: 1. Log in as root. 2. 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 3. 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: o Baselining Phase 1 evaluates your system relative to the patch kit. o 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. o 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. o 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. o 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 "Manually Installed CSPs" and "Phase 5 - Enabling dupatch to Overwrite Changed System Files". If you answer y to this question, dupatch enables all of the patches to be installed. o 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 :3 Press RETURN to proceed to the next phase... o 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... Chapter 3 Patch Installation and Removal Instructions Table of Contents 3.1 Before You Begin the Installation 3.2 Expanding the Patch Kit Tar File 3.3 Choosing Single-User or Multi-User Mode 3.3.1 Installing Patches from Single-User Mode 3.3.2 Installing Patches from Multi-User Mode 3.4 Common Installation Steps 3.5 Rebuilding the Kernel 3.6 Rebooting the System 3.6.1 In Single-User Mode 3.6.2 In Multi-User Mode 3.7 Post-Installation Actions 3.7.1 Enabling the Version Switch After Installing a New Style Patch Kit 3.7.2 Remove Temporary Directory 3.7.3 Adding the Worldwide Language Support 3.8 Removing Patches 3.8.1 Overview 3.8.2 Important Tasks Required Before Removing Patches and Rebooting System 3.8.3 Running dupatch to Remove Patches This chapter provides instructions for installing and removing patches from the Tru64 UNIX operating system and the TruCluster software products. Although the descriptions and examples in this chapter reflect the installation and removal steps of Release Patch Kits, the steps are basically the same for dupatch-based CSP and ERP kits. "Rolling Upgrade" describes the procedure for patching a TruCluster Server Version 5.0A or higher cluster using the rolling upgrade function. If you are patching your system with that process, follow the steps described there. You will be returned to this chapter when it is time to run dupatch. If you have not yet created your cluster, follow the steps in "Patching a System Prior to Creating a Cluster". The -l of the setld command is disabled for patch subsets. 3.1 Before You Begin the Installation Before beginning the installation, make sure that you have completed all of the following preliminary steps: o Make sure you have the correct software You must have the appropriate versions of Tru64 UNIX and TruCluster software installed on your system to install patch kits. There are separate patch kits for each version of the Tru64 UNIX and TruCluster software products. The patch kits will not install on any other version of those products. For example, a Tru64 UNIX 5.1B patch kit will only install on Tru64 UNIX Version 5.1B. o Back up your system It is recommended that you backup your /, /usr, and /var file systems prior to installing patches or baselining your system. o Make sure you have enough storage space Refer to the Patch Summary and Release Notes for the required storage space. o Make the patch distribution available to your system, as described in "Expanding the Patch Kit Tar File". o Load any new patch tools, as described in "Invoking dupatch and Installing New Patch Tools". o Perform the patch preinstallation check, as described in "Performing a Patch Preinstallation Check". o Set a system patch baseline, if needed, as described in "Creating a Baseline". o Review the list of issues and restrictions in "General Issues and Restrictions" and in the Patch Summary and Release Notes document that comes with your patch kit. The following sections provide step-by-step instructions for installing and enabling patches. 3.2 Expanding the Patch Kit Tar File If you are using patch tar files obtained via the Internet (see "Patch Process Resources"), you must expand the tar file to access the patch kits. The tar file can be expanded on any mountable file system. The following list describes procedure: 1. Mount the file system and create a directory. # /usr/sbin/mount /dev/disk/dsk3g /patches # cd /patches # mkdir pk5 [Note] Note: If you are installing successive patch kits, place and untar each kit in a separate directory. Copy or ftp the patch kit to the directory you created. For example: # cp T64V51BB26AS0005-20050215.tar /patches/pk5 2. Untar the patch kit, capturing the process to a log file. For example: # script untar.log # tar -xpvf /patches/pk5/T64V51BB26AS0005-20050215.tar # Ctrl/d 3. View the untar.log for errors or failures untarring the file. 3.3 Choosing Single-User or Multi-User Mode You can install patches from either single-user or multi-user modes. See "When Single-User Mode Is Recommended" for information about selecting one of these modes. "Installing Patches from Single-User Mode" describes the process from single-user mode and "Installing Patches from Multi-User Mode" describes the process from multi-user mode. "Common Installation Steps" describes the remaining steps, which are common to installations from single-user and multi-user modes. 3.3.1 Installing Patches from Single-User Mode The following steps describe a patch kit installation from single-user mode. Although these steps are the same whether installing an old or new style patch kit, the text that dupatch displays differs in minor ways. The examples used in these steps reflect the output of a new style patch kit installation. 1. Halt the system. For example: # /usr/sbin/shutdown -h +5 "Applying 5.1B-3 OS and TCR patches" 2. Boot to single-user mode from the console prompt. For example: >>>boot -fl s 3. Run the init s command to change the run level to a single-user state with only essential kernel services: # /sbin/init s 4. Run the bcheckrc command to check and mount all the UFS and AdvFS file systems, the kloadsrv command to load kernel modules into the kernel, and the lmf reset command to copy license details for all enabled products from the License Database to the kernel cache: # /sbin/bcheckrc # /sbin/kloadsrv # /usr/sbin/lmf reset 5. For systems prior to 5.0A, issue the update command and activate your swap partition with the swapon command: # /sbin/update # /sbin/swapon -a 6. Enter the rcinet command to start network services: # /usr/sbin/rcinet start Informational messages will appear on the screen. 7. Run the dupatch utility. You will be asked to specify the path to the patch_kit file. For example: # cd /var/patch/pk5/patch_kit # ./dupatch Enter path to the top of the patch distribution, or enter "q" to quit : . 8. From the Main Menu, enter 1 at the Enter your choice prompt to invoke the patch installation session. For example: 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 9. When the patch installation menu is displayed, enter 2 at the Enter your choice prompt: Patch Installation Menu: ----------------------- 1) Pre-Installation Check ONLY 2) Check & Install the patch kit in Single-User Mode b) Back to Main Menu q) Quit Enter your choice: 2 3.3.2 Installing Patches from Multi-User Mode The following list describes the steps you take and the type of output you will see when you install patches from multi-user mode. 1. Run the dupatch utility and enter 1 at the Enter your choice prompt to the invoke the patch installation session: # /patches/pk4/patch_kit/dupatch 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 2. When the patch installation menu is displayed. Enter 3, at the Enter your choice prompt. Read the warning message and press Return if you want to continue the installation in multi-user mode: Patch Kit Installation Menu: ----------------------- 1) Pre-Installation Check ONLY 2) Check & Install in single-user mode w/ network services 3) Check & Install in Multi-User mode b) Back to Main Menu q) Quit Enter your choice: 3 *** Installation Warning *** You have chosen to install the patch kit onto this system while it is running in Multi-User mode. Some patches may directly affect core operating system operations. To ensure the proper operation of all applications, it is strongly suggested that you install these patches while the system is in Single-User mode. If this cannot be done, install these patches when the system is as lightly loaded as possible (i.e. not running production environments, no users logged on, etc.). Do you wish to continue? (y/n) [y]: 3.4 Common Installation Steps The following steps provide instructions for continuing the installation of Tru64 UNIX and TruCluster software patches after you have selected either single-user or multi-user mode. 1. Specify whether or not you accept the license agreement. You can read the license on screen or you can read the license before beginning the installation process in the Patch Summary and Release Notes that comes with the patch kit. In the following output, the license is removed to save space: 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 2. You have the option to make patches reversible so you can return the system to its state prior to the installation of a patch. Enter y or press Return to make the patches reversible. For example: Do you want the patches to be reversible? [y]: By default, backup copies of the installed patches are 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. If you answer no to this question, the existing system files will not be saved and the installed patches will not be reversible. HP recommends that you install patches so they are reversible. 3. The program describes your backup setup and asks you if you want to proceed: Do you want to proceed with the installation with this setup? [y]: 4. You are asked to record your name as the person installing the patches and to add any comments you would like stored for future reference. For example: Your name: Joe C. Enter any notes about this operation that you would like stored for future reference. To end your input, enter a period (.) and press Return. : Installing Patch Kit 5 : . Return 5. The next action depends on the type of kit you are installing: o Inclusive patch kit With this type of kit dupatch peforms a preinstallation check and begins to install the patches if it finds no problems. For example: Checking patch prerequisites and patch file applicability... (depending upon the number of patches you select, this may take awhile). *** Installing 78 patches *** If any patches fail the preinstallation check, do one of the following: o If the failure is the result of a file conflict, you will need to run the patch baseline process, as described in "Creating a Baseline". o If the failure is caused by an installed CSP that is not included in the current patch kit, you will have to remove the CSP, install the patch kit, and reinstall the CSP. See "Patch Installation Blocked by an Existing CSP" for more information. o Customer-Specific patch kit With this type of kit you must install all patches. You can, however, remove individual CSPs after the installation process is completed and the system has been rebooted. 3.5 Rebuilding the Kernel The dupatch utility determines whether the installation or removal of patches requires that the kernel be rebuilt. This action is performed automatically or manually, depending upon the method you used to install the patches: o When using the menu-based interface, you will be prompted for actions to take. Those prompts are the same ones you would see if you ran the doconfig command. The dupatch utility asks if your system has a custom configuration file and if you want to change it. o When using dupatch from the command line, the kernel is built automatically. It does this by calling the doconfig -a command. If you specify the dupatch -cfgfile command, dupatch calls doconfig with the -a-c options. After the patch kit is installed you will see output similar to the following: Configuring "Patch: SP04 OSFADVFSBIN540" (OSFPAT02500300540) Configuring "Patch: SP04 OSFADVFS540 (SSRT2275)" (OSFPAT02500200540) Beginning kernel build... Do you have a pre-existing configuration file?: If you answer yes, dupatch will build the kernel noninteractively, enabling all (mandatory and optional) kernel options automatically. This procedure is similar to running the doconfig -a command. If you answer no, dupatch will build the kernel interactively. This procedure is similar to running the doconfig -c command. The following steps describe this procedure and provide some guidance for making your selections: 1. Enter a new name for the kernel configuration file or accept the default. If you accept the default you will be asked if you want to replace it. For example: *** KERNEL CONFIGURATION AND BUILD PROCEDURE *** Enter a name for the kernel configuration file. [IDIOM2]: Return A configuration file with the name 'IDIOM2' already exists. Do you want to replace it? (y/n) [n]: y Saving /sys/conf/IDIOM2 as /sys/conf/IDIOM2.bck 2. Specify the kernel options you want. If you are unsure of which options to specify, consider the following: o Selecting the All of the Above option ensures that you can access any new functions provided by the patch kit. You may, however, create a kernel that is larger than you need. If you know of options you do not need, you can ignore those and specify all of the other options, thereby ensuring that you will have access to the new functions you need but with a smaller kernel than if you had selected all of the options. o Selecting the None of the Above option will result in a kernel build that is similar to using the doconfig -ac command. This is the default. The following output is similar to what you will see. The procedure gives you the opportunity to edit the configuration file: *** KERNEL OPTION SELECTION *** Selection Kernel Option -------------------------------------------------------------- 1 System V Devices 2 NTP V3 Kernel Phase Lock Loop (NTP_TIME) 3 Kernel Breakpoint Debugger (KDEBUG) 4 Packetfilter driver (PACKETFILTER) 5 IP-in-IP Tunneling (IPTUNNEL) 6 IP Version 6 (IPV6) 7 Point-to-Point Protocol (PPP) 8 STREAMS pckt module (PCKT) 9 Data Link Bridge (DLPI V2.0 Service Class 1) 10 X/Open Transport Interface (XTISO, TIMOD, TIRDWR) 11 Digital Versatile Disk File System (DVDFS) 12 ISO 9660 Compact Disc File System (CDFS) 13 Audit Subsystem 14 ATM UNI 3.0/3.1 ILMI (ATMILMI3X) --- MORE TO FOLLOW --- Enter your choices or press to display the next screen. Choices (for example, 1 2 4-6): 2-12 15 IP Switching over ATM (ATMIFMP) 16 LAN Emulation over ATM (LANE) 17 Classical IP over ATM (ATMIP) 18 ATM UNI 3.0/3.1 Signalling for SVCs (UNI3X) 19 Asynchronous Transfer Mode (ATM) The following choices override your previous selections: 20 All of the above 21 None of the above 22 Help 23 Display all options again -------------------------------------------------------------- Enter your choices, choose an overriding action or press to confirm previous selections. Choices (for example, 1 2 4-6): Return You selected the following kernel options: NTP V3 Kernel Phase Lock Loop (NTP_TIME) Kernel Breakpoint Debugger (KDEBUG) Packetfilter driver (PACKETFILTER) IP-in-IP Tunneling (IPTUNNEL) IP Version 6 (IPV6) Point-to-Point Protocol (PPP) STREAMS pckt module (PCKT) Data Link Bridge (DLPI V2.0 Service Class 1) X/Open Transport Interface (XTISO, TIMOD, TIRDWR) Digital Versatile Disk File System (DVDFS) ISO 9660 Compact Disc File System (CDFS) Is that correct? (y/n) [y]: Return Do you want to edit the configuration file? (y/n) [n]: Return *** PERFORMING KERNEL BUILD *** A log file listing special device files is located in /dev/MAKEDEV.log Working....Tue Mar 9 11:36:33 EST 2004 The new kernel is /sys/IDIOM2/vmunix See the doconfig(8) reference page for more information. 3.6 Rebooting the System The action that dupatch takes to reboot your system depends upon whether you used the command-line or menu-based interface or performed the action in single-user or multi-user mode. The following sections describe these actions. Before rebooting, review the dupatch session log, /var/adm/patch/log/session.log, to ensure that the installation was successful. Note any special patch instructions, informational messages, and error messages. Certain patches may require you to take a particular action, such as running a script, before rebooting. (See Appendix A "Viewing Log files" for information about dupatch logs.) 3.6.1 In Single-User Mode When performing a patch installation or removal in single-user mode from the command line, the system automatically reboots after the command line operation is completed. When performing a patch installation or removal in single-user mode using the menu-based interface, dupatch asks if you want to reboot the system after the patch installation or removal is completed: o If you answer yes, the system reboots immediately. o If you answer no, dupatch returns to the appropriate menu - either installation or removal, depending on the operation. 3.6.2 In Multi-User Mode When installing patches in multi-user mode from the command line, you are given a message informing you that a reboot is necessary to complete the patch installation. However, the system does not reboot itself. When installing patches in multi-user mode using the menu-based interface, dupatch gives you three options if a reboot is necessary: o Reboot now o Schedule a reboot for a later time o Do not reboot 3.7 Post-Installation Actions The following sections describe actions for you to take after you have completed the dupatch installation procedure. 3.7.1 Enabling the Version Switch After Installing a New Style Patch Kit Some patches may require you to run the versw -switch command to enable the new functions delivered in those patches. (See "Version Switches" for information about version switches.) You perform this action after dupatch has completed the installation: # versw -switch The new functionality will not be available until after you reboot your system. You do not have to run the versw -switch command, but if you do not, your system will not be able to access the functionality provided in the version switch patches. 3.7.2 Remove Temporary Directory Once your patch kit is installed, delete the temporary directory in which you expanded the patch kit tar file. For example: # rm -r /Patches/PK4 Removing the temporary directory will preclude the possibility of using that directory for subsequent patch kit installations. When performing a patch kit installation, using a directory that contains files from a previous patch kit installation can leave your system in an unstable condition. Remember that if you want to save the patch kit tar file, remove it from the temporary directory before deleting the directory. 3.7.3 Adding the Worldwide Language Support Inclusive patch kits provide patches to the Tru64 UNIX Worldwide Language Support subset (WLS). If the WLS subset is installed on your system, the WLS patches will be installed automatically when you install the patch kit. However, if you install the WLS subset after patching your system, you will have to rerun dupatch to install the WLS patches. The dupatch utility will see the WLS subset, recognize that the patches have not been installed, and will install them. 3.8 Removing Patches To remove patches from your system, use the Patch Deletion option of the dupatch Main Menu. The following sections describe actions describe the patch removal process. 3.8.1 Overview Beginning with the version of dupatch delivered in the Version 5.1B-3 kit, the patch removal process depends upon whether you installed the new form of patch kits, called Inclusive Patch Kits. These kits began shipping with Version 5.1B-2. With Inclusive Patch Kits you must remove the entire kit rather than individual patches. However, once you have removed any Inclusive Patch Kits installed on your system, you can then remove individual patches from earlier kits. To do this, dupatch recognizes the type of kit you have installed. When you select the patch deletion menu, dupatch lists the most current Inclusive Patch Kit installed on your system as well as any customer-specific patches (CSPs) that depend upon that kit. After you remove that kit and reboot your system, you can rerun dupatch to remove the next most current Inclusive Patch Kit and the CSPs that depend on it. Once all inclusive patch kits have been removed, the next time you run the patch deletion program, dupatch will list all of the patches on your system and you can selectively remove any of those patches. [Caution] Caution: With the old-style patch kits, the Patch Deletion menu lists every setld-based patch on your system, regardless of which patch kit installed them. If you select the ALL of the above menu item, it will remove all setld-based patches from your system. Therefore, you want to remove all of the patches from a patch kit, but do not want to delete setld-based patches, you will have to specify the patch ID of all of that kit's patches. The latest version of dupatch also gives you the option to delete patches in single-user mode or in multi-user mode. As with the installation process, using single-user mode is safer and is the recommended procedure. See "When Single-User Mode Is Recommended" for more information. The dupatch utility issues the following warning when you are deleting patches in multi-user mode. *** Multi-User Deletion Warning *** You have chosen to delete patches from this system while it is running in Multi-User mode. Some patches may directly affect core operating system operations. To ensure the proper operation of all applications, it is strongly suggested that you delete these patches while the system is in Single-User mode. If this cannot be done, delete these patches when the system is as lightly loaded as possible (i.e. not running production environments, no users logged on, etc.). Do you want to continue? (y/n): If you want to continue, answer yes. If you do not want to delete the patch kit in multi-user mode, answer no and bring your system down to single-user mode as described in "Installing Patches from Single-User Mode". 3.8.2 Important Tasks Required Before Removing Patches and Rebooting System Before running the patch deletion process you may have to perform the tasks described in the following sections. 3.8.2.1 Run Mandatory Script Before Removing New Style Patch Kits If you enabled version switches as described in "Enabling the Version Switch After Installing a New Style Patch Kit" for an Inclusive Patch Kit, you must run the /usr/sbin/versw_enable_delete script before attempting to remove the patch kit. The steps for running this script require a complete cluster or single system shutdown, so choose a time when a shutdown will have the least impact on your operations. The following steps describe the procedure: 1. Make sure that all phases of the patch kit installation process have been completed. 2. Run /usr/sbin/versw_enable_delete: # /usr/sbin/versw_enable_delete 3. Shut down the entire cluster or the single system. 4. Reboot the entire cluster or the single system. 5. Run dupatch on your single system or on a cluster using the rolling upgrade procedure to delete the patch kit. [Note] Note: The next step requires that you reboot each cluster member to remove the patch kit. Because the no-roll procedure automatically reboots the system after deleting the patches, you would not be able to perform the next steps as required. Therefore, you cannot use the no-roll procedure to remove this patch kit. 6. Reboot the single system or each member of the cluster. 3.8.2.2 Changes to System May Need to Be Reversed If you made the following changes to your system after installing the patch kit, you will have to undo those changes before you can uninstall the patch kit: o If you changed your hardware configuration (for example, by adding a new disk), the system configuration that existed prior to installing the patch kit might not recognize the new devices or may not provide the necessary support for them. o If you added new cluster members, the new members will not have an older state to revert to if you attempt to uninstall the patch kit. To uninstall the patch kit, do the following: 1. Remove all new hardware and new cluster members that you added after installing the patch kit. 2. Run dupatch to uninstall the patch kit. 3. Verify that the patch kit was successfully uninstalled. You can now add the cluster members you removed and reinstall the hardware you removed, as long as the support for it existed in the pre-patched system. You can also reinstall the patch kit. 3.8.2.3 Script Must Be Run Prior to Reboot on Certain Version 5.1B Systems If removing a PK4 or higher patch kit restores your Version 5.1B system to a pre-patched state, you must run the script /etc/dn_fix_dat.sh before rebooting your system during the patch deletion process. This would occur if the inclusive patch kit you are uninstalling is the only patch kit installed on your Version 5.1B system You must also run this script if you are removing a specific patch from previous Version 5.1B patch kits if those kits are the only patch kit on your system. The affected patch in those kits will be noted in a Special Instruction that is displayed when you run the dupatch installation and deletion processes. Failing to run this script will result in your system being unable to boot normally. If this occurs, do the following: 1. Boot your system in single-user mode: >>> boot -fl s 2. Run the script: # /etc/dn_fix_dat.sh 3. Reboot normally. If you also need to reverse the version switch as described in "Run Mandatory Script Before Removing New Style Patch Kits", run the /etc/dn_fix_dat.sh script after step 5 in that process. 3.8.3 Running dupatch to Remove Patches The process for removing patches is similar to the one for installing them. The following steps describe the patch removal process for an Inclusive Patch Kit with the system running in single-user mode. In mutiuser mode the steps would be the same except you would see the multi-user deletion warning described in "Overview". See "Installing Patches from Single-User Mode" for the steps on bringing down your system to single-user mode. 1. Run dupatch and select 2 for patch removal: # /patch/pk4/patch_kit/dupatch 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: 2 2. Select the current patch kit. This menu will change if no Inclusive patch kits are installed. 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 deleted. 1) CSP C688.00 drag-and-drop or cut-and-paste may fail 2) CSP C718.00 Debug version of ping 3) CSP C752.00 page on o/h list panic 4) CSP C882.00 Fix for memory leak and slowdown in rpc.lockd 5) T64V51BB26AS0005-20050215 and all CSP's dependent upon it Or you may choose one of the following options: 2) ALL of the above 3) CANCEL selections and redisplay menus 4) EXIT without deleting any patches Enter your choices or press RETURN to redisplay menus. Choices (for example, 1 2 4-6): 7 You are deleting the following patches: T64V51BB26AS0005-20050215 and all CSP's dependent upon it Is this correct? (y/n):y *** Start of Special Instructions *** If you delete this patch kit, you MUST run the following script prior to rebooting your system: /etc/dn_fix_dat.sh :3 3. You are asked to record your name as the person removing the patches and to add any comments you would like stored for future reference in the log file. For example: Your name: Betty Enter any notes about this operation that you would like stored for future reference. To end your input, enter a period (.) and press Return. : Uninstalling V5.1B-3 : . Return Checking patch dependency... (depending upon the number of patches you select, this may take awhile) *** The Patch Kit will delete 67 patches *** ************************** CAUTION ************************************ Interruption of this phase of the operation will corrupt your operating system software and compromise the patch database integrity. DO NOT Ctrl/C, power off your system, or in any other way interrupt the patch operation. The patch operation is complete when you are returned to the Patch Utility menus. *********************************************************************** Deleting "Patch: SP05 OSFEXER540" (OSFPAT02603100540). Deleting "Patch: SP05 OSFEXAMPLES540" (OSFPAT02603000540). Deleting "Patch: SP05 OSFENVMON540" (OSFPAT02602800540). :3 4. Rebuild the kernel. This step is the same as for the installation process. See "Rebuilding the Kernel" for details. 5. Review the session log to ensure the removal was successful. Note any special patch instructions, informational messages, and error messages. This is especially important to identify any actions that you may have to take (such as running a script) before rebooting your system. 6. Run the script described in "Script Must Be Run Prior to Reboot on Certain Version 5.1B Systems". 7. Reboot the system. See "Rebooting the System" for details. Chapter 4 Patching a Cluster Table of Contents 4.1 Rolling Upgrade 4.1.1 Rolling Upgrade Supported Tasks 4.1.2 Unsupported Tasks 4.1.3 Rolling Upgrade Procedure 4.1.4 Removing Patches Installed During a Rolling Upgrade 4.1.5 Displaying the Status of a Rolling Upgrade 4.1.6 Undoing a Stage 4.1.7 Rolling Upgrade Commands 4.1.8 Rolling Upgrade Stages 4.1.9 Tagged Files 4.1.10 Version Switch 4.1.11 Rolling Upgrade and Layered Products 4.1.12 Rolling Upgrade and RIS 4.2 No-Roll Patching 4.2.1 Overview 4.2.2 Steps for Running a No-Roll Procedure 4.2.3 Throwing the Version Switch 4.2.4 Removing Patches 4.3 Using the dupclone Script 4.3.1 Benefits and Detriments of Cloning 4.3.2 Performing the Cloned Installation The following sections describe the procedures for installing the patch kit using the following methods: o Rolling upgrade procedure ("Rolling Upgrade") o No-roll procedure ("No-Roll Patching") o Cloning procedure using the duclone script ("Using the dupclone Script") 4.1 Rolling Upgrade A rolling upgrade is a software upgrade of a cluster that is performed while the cluster is in operation. Patching your system is one type of upgrade that can be performed using this procedure. The term "Rolling Patch" is sometimes used to describe the patching process using the Rolling Upgrade procedure. In general, the terms Rolling Patch and Rolling Upgrade are synonymous in this chapter. In a Rolling Upgrade, one member at a time is upgraded and returned to operation while the cluster transparently maintains a mixed-version environment for the base operating system, cluster, and Worldwide Language Support (WLS) software. Clients accessing services are not aware that a rolling upgrade is in progress. A rolling upgrade consists of an ordered series of steps, called stages. The commands that control a rolling upgrade enforce this order. When performing a rolling upgrade, the same procedure is used for patching your system as for upgrading to a new operating system or TruCluster version. The principal difference is that for a rolling patch you use the dupatch utility and for a rolling upgrade you use the installupdate utility during the install stage. This chapter provides the same information as the Rolling Upgrade chapter of the Cluster Installation manual. It is provided here as a convenience so you can review your patching options in one manual. [Note] Note: If you have not yet created your cluster, we recommend that you patch your system first. See "Patching a System Prior to Creating a Cluster" for this time-saving procedure. The first part of this chapter contains instructions for performing a rolling upgrade, for displaying the status of a rolling upgrade, and for undoing one or more stages of a rolling upgrade. Those interested in how a rolling upgrade works can find the details in "Rolling Upgrade Commands" and the sections that follow it. This chapter discusses the following topics: o Tasks, and combinations of tasks, you can perform during a single rolling upgrade ("Rolling Upgrade Supported Tasks") o Tasks you cannot perform during a rolling upgrade ("Unsupported Tasks") o How to perform a rolling upgrade ("Rolling Upgrade Procedure") o How to display the status of a rolling upgrade ("Displaying the Status of a Rolling Upgrade") o Iimportant information you need to be aware of if you remove or reinstall patches during a rolling upgrade ("Removing Patches Installed During a Rolling Upgrade") o Displaying the status of a rolling upgrade ("Displaying the Status of a Rolling Upgrade") o How to undo the stages of a rolling upgrade ("Undoing a Stage") o The commands used during a rolling upgrade ("Rolling Upgrade Commands") o Rolling upgrade stages ("Rolling Upgrade Stages") o Two mechanisms that support rolling upgrades: tagged files ("Tagged Files") and version switches ("Version Switch") o Rolling upgrade and layered products ("Rolling Upgrade and Layered Products") o Rolling upgrade and RIS ("Rolling Upgrade and RIS") Figure 4.1 "Rolling Upgrade Flow Chart" provides a simplified flow chart of the tasks and stages that are part of a rolling upgrade initiated on a Version 5.1B cluster: Figure 4.1 Rolling Upgrade Flow Chart Rolling Upgrade Flow Chart 4.1.1 Rolling Upgrade Supported Tasks The tasks that you can perform during a rolling upgrade depend on which versions of the base operating system and cluster software are currently running on the cluster. The main focus of this chapter is to describe the behavior of a rolling upgrade that starts on a TruCluster software Version 5.1B cluster. However, because you may read this chapter in preparation for a rolling upgrade from TruCluster software Version 5.1A to Version 5.1B, we point out rolling upgrade differences between the two versions. The following list describes the basic tasks you can perform within a rolling upgrade: o Upgrade the cluster's Tru64 UNIX base operating system and TruCluster software software. You perform this type of rolling upgrade to upgrade from the installed version to the next version. When performing a rolling upgrade of the base operating system and cluster software, you can roll only from one version to the next version. You cannot skip versions. [Note] Note: A rolling upgrade updates the file systems and disks that the cluster currently uses. The roll does not update the disk or disks that contain the Tru64 UNIX operating system used to create the cluster (the operating system on which you ran clu_create). Although you can boot the original operating system in an emergency when the cluster is down, remember that the differences between the current cluster and the original operating system increase with each cluster update. o Patch the cluster's current versions of the Tru64 UNIX base operating system and TruCluster software software. o Install a New Hardware Delivery (NHD) kit (the cluster must be running TruCluster software Version 5.1A or later). Rolling in a patch kit or an NHD kit uses the same procedure as rolling in a new release of the base operating system and cluster software. The difference is which commands you run during the install stage: o To upgrade the base operating system and cluster software, run installupdate in the install stage. o To roll in a patch kit, run dupatch in the install stage. You can invoke dupatch multiple times in the install stage to roll in multiple patch kits. If you want to perform a no-roll patch of the cluster, do not run the clu_upgrade command. Instead run the dupatch command from a cluster member running in multi-user mode. No-roll patching applies patches quickly and reduces the number of reboots required. It patches the cluster in one operation. However, it requires a reboot of the whole cluster to complete the operation, so the cluster is unavailable for a period. o To install an NHD kit, run nhd_install in the install stage. Throughout this chapter, the term rolling upgrade refers to the overall procedure used to roll one or more software kits into a cluster. As shown in Figure 4.1 "Rolling Upgrade Flow Chart", you can perform more than one task during a rolling upgrade. If the cluster is running Version 5.1A or Version 5.1B, a rolling upgrade can include the task combinations listed in Table 4.1 "Rolling Upgrade Tasks Supported by Version 5.1A and Version 5.1B": Table 4.1 Rolling Upgrade Tasks Supported by Version 5.1A and Version 5.1B +------------------------------------------------------------------------+ | An update installation from Version 5.1A to Version 5.1B | | | | An update installation from Version 5.1B to the next release | |------------------------------------------------------------------------| | A patch of Version 5.1A | | | | A patch of Version 5.1B | |------------------------------------------------------------------------| | The installation of a New Hardware Delivery (NHD) kit onto a Version | | 5.1A cluster | | | | The installation of an NHD kit onto a Version 5.1B cluster | |------------------------------------------------------------------------| | An update installation from Version 5.1A to Version 5.1B of the base | | operating system and cluster software, followed by a patch of Version | | 5.1B | | | | An update installation from Version 5.1B to the next release of the | | base operating system and cluster software followed by a patch of the | | next release[a] | |------------------------------------------------------------------------| | An NHD installation onto a Version 5.1A cluster followed by a patch of | | Version 5.1A | | | | An NHD installation onto a Version 5.1B cluster followed by a patch of | | Version 5.1B | |------------------------------------------------------------------------| | An update installation from Version 5.1A to Version 5.1B followed by | | the installation of an NHD kit for Version 5.1B | | | | An update installation from Version 5.1B to the next release of the | | base operating system and cluster software followed by the | | installation of an NHD kit for that next release[b] | |------------------------------------------------------------------------| | An update installation from Version 5.1A to Version 5.1B, followed by | | the installation of an NHD kit for Version 5.1B, followed by a patch | | of Version 5.1B | | | | An update installation from Version 5.1B to the next release, followed | | by the installation of an NHD kit for the next release, followed by a | | patch of the next release[b] | |------------------------------------------------------------------------| | [a] Within one rolling upgrade, you can combine an upgrade of the base | | operating system and cluster software with a patch of the new | | software. This means that during the install stage, you can run | | installupdate on the first member followed by dupatch to patch the | | newly installed software. When you roll the remaining members they | | automatically get both the new software and the patches. | | | | However, you cannot patch the current software and then upgrade the | | base operating system and cluster software within one rolling upgrade. | | This operation requires two rolling upgrades. | | | | [b] Allowed only if you have already installed an NHD kit on the | | Version 5.1A or Version 5.1B cluster. | +------------------------------------------------------------------------+ 4.1.2 Unsupported Tasks The following list describes tasks that you cannot perform or that we recommend you do not attempt during a rolling upgrade: o Do not remove or modify files in the /var/adm/update directory. The files in this directory are critical to the roll. Removing them can cause a rolling upgrade to fail. o During the install stage, you cannot run a dupatch command followed by an installupdate command. To patch the current software before you perform a rolling upgrade, you must perform two complete rolling upgrade operations: one to patch the current software, and one to perform the update installation. o You cannot bypass versions when performing a rolling upgrade of the base operating system and cluster software. You can only roll from one version to the next version. o Do not use the /usr/sbin/setld command to add or delete any of the following subsets: o Base Operating System subsets (those with the prefix OSF). o TruCluster Server subsets (those with the prefix TCR). o Worldwide Language Support (WLS) subsets (those with the prefix IOS). Adding or deleting these subsets during a roll creates inconsistencies in the tagged files. o Do not install a layered product during the roll. Unless a layered product's documentation specifically states that you can install a newer version of the product on the first rolled member, and that the layered product knows what actions to take in a mixed-version cluster, we strongly recommend that you do not install either a new layered product or a new version of a currently installed layered product during a rolling upgrade. For more information about layered products and rolling upgrades, see "Rolling Upgrade and Layered Products". 4.1.3 Rolling Upgrade Procedure In the procedure in this section, unless otherwise stated, run commands in multi-user mode. Each step that corresponds to a stage refers to the section that describes that stage in detail. We recommend that you read the detailed description of stages in "Rolling Upgrade Stages" before performing the rolling upgrade procedure. Some stages of a rolling upgrade take longer to complete than others. Table 4.2 "Time Estimates for Rolling Upgrade Stages" lists the approximate time it takes to complete each stage. Table 4.2 Time Estimates for Rolling Upgrade Stages +------------------------------------------------------------------------+ | Stage | Duration | |-------------------------+----------------------------------------------| | Preparation | Not under program control. | |-------------------------+----------------------------------------------| | Setup | 45 - 120 minutes.[a] | |-------------------------+----------------------------------------------| | Preinstall | 15 - 30 minutes.[a] | |-------------------------+----------------------------------------------| | Install | The same amount of time it takes to run | | | installupdate, dupatch, nhd_install, or a | | | supported combination of these commands on a | | | single system. | |-------------------------+----------------------------------------------| | Postinstall | Less than 1 minute. | |-------------------------+----------------------------------------------| | Roll (per member) | Patch: less than 5 minutes. | | | | | | Update installation: about the same amount | | | of time it takes to add a member.[b] | |-------------------------+----------------------------------------------| | Switch | Less than 1 minute. | |-------------------------+----------------------------------------------| | Clean | 30 - 90 minutes.[a] | |------------------------------------------------------------------------| | [a] These stages create, verify, or remove the tagged files required | | for a rolling upgrade. The time that it takes to run one of these | | stages depends on the speed of the member executing the command, the | | speed of the storage, and whether the member executing the command is | | the CFS server for the root (/), /usr, and /var file systems. Consider | | relocating these file systems to the member where you will run the | | clu_upgrade command. | | | | [b] After rolling the lead member, use parallel rolls to roll multiple | | members simultaneously and shorten the time it takes to roll a | | cluster. | +------------------------------------------------------------------------+ You can use the following procedure to upgrade a TruCluster software Version 5.1A cluster to Version 5.1B, and to upgrade a cluster that is already at Version 5.1B. 1. Prepare the cluster for the rolling upgrade ("Preparation Stage"): a. Choose one cluster member to be the lead member (the first member to roll). (The examples in this procedure use a member whose memberid is 2 as the lead member. The example member's host name is provolone.) b. Back up the cluster. c. If you will perform an update installation during the install stage, remove any blocking layered products, listed in Table 4.6 "Blocking Layered Products", that are installed on the cluster. d. To determine whether the cluster is ready for an upgrade, run the clu_upgrade -v check setup lead_memberid command on any cluster member. For example: # clu_upgrade -v check setup 2 If a file system needs more free space, use AdvFS utilities such as addvol to add volumes to domains as needed. For disk space requirements, see "Preparation Stage". For information on managing AdvFS domains, see the Tru64 UNIX AdvFS Administration manual. e. Verify that each system's firmware will support the new software. Update firmware as needed before starting the rolling upgrade. 2. Perform the setup stage ("Setup Stage"). [Note] Notes: If your current cluster is at Version 5.1A or later and if you plan to upgrade the base operating system and cluster software during the install stage, mount the device or directory that contains the new TruCluster software kit before running clu_upgrade setup. The setup command will copy the kit to the /var/adm/update/TruClusterKit directory. If your current cluster is at Version 5.1A or later and if you plan to install an NHD kit during the install stage, mount the device or directory that contains the new NHD kit before running clu_upgrade setup. The setup command will copy the kit to the /var/adm/update/NHDKit directory. On any member, run the clu_upgrade setup lead_memberid command. For example: # clu_upgrade setup 2 "Setup Stage" shows the menu displayed by the clu_upgrade command. When the setup stage is completed, clu_upgrade prompts you to reboot all cluster members except the lead member. 3. One at a time, reboot all cluster members except the lead member. Do not start the preinstall stage until these members are either rebooted or halted. 4. Perform the preinstall stage ("Preinstall Stage"). On the lead member, run the following command: # clu_upgrade preinstall If your current cluster is at Version 5.1A or later, the preinstall command gives you the option of verifying or not verifying the existence of the tagged files created during the setup stage. o If you have just completed the setup stage and have done nothing to cause the deletion any of the tagged files, you can skip this test. o If you completed the setup stage a while ago and are not sure what to do, let preinstall test the correctness of the tagged files. 5. Perform the install stage ("Install Stage"). [Note] Note: During the install stage you load the new software on the lead member, in effect rolling that member. When you perform the roll stage, this new software is propagated to the remaining members of the cluster. The clu_upgrade command does not load software during the install stage. The loading of software is controlled by the commands you run: installupdate, dupatch, or nhd_install. See Table 4.1 "Rolling Upgrade Tasks Supported by Version 5.1A and Version 5.1B" for the list of rolling upgrade tasks and combination of tasks supported for Version 5.1A and Version 5.1B. a. See Chapter 3 "Patch Installation and Removal Instructions" for instructions on installing a patch kit using the dupatch command. See the Tru64 UNIX Installation Guide for detailed information on using the installupdate command. See the Tru64 UNIX New Hardware Delivery Release Notes and Installation Instructions that came with your NHD kit for detailed information on using the nhd_install command. b. If the software you are installing requires that its installation command be run from single-user mode, halt the system and boot the system to single-user mode: # shutdown -h now >>> boot -fl s [Note] Note: Halting and booting the system ensures that it provides the minimal set of services to the cluster and that the running cluster has a minimal reliance on the member running in single-user mode. In particular, halting the member satisfies services that require the cluster member to have a status of DOWN before completing a service failover. If you do not first halt the cluster member, services will probably not fail over as expected. When the system reaches single-user mode, run the following commands: # init s # bcheckrc # lmf reset c. Run the installupdate, dupatch, or nhd_install command. To roll in multiple patch kits, you can invoke dupatch multiple times in a single install stage. Be aware that doing so may make it difficult to isolate problems should any arise after the patch process is completed and the cluster is in use. You cannot run a dupatch command followed by an installupdate command. To patch the current software before you perform a rolling upgrade, you must perform two complete rolling upgrade operations: one to patch the current software, and one to perform the update installation. 6. (Optional) After the lead member performs its final reboot with its new custom kernel, you can perform the following manual tests before you roll any additional members: a. Verify that the newly rolled lead member can serve the shared root (/) file system. i. Use the cfsmgr command to determine which cluster member is currently serving the root file system. For example: # cfsmgr -v -a server / Domain or filesystem name = / Server Name = polishham Server Status : OK ii. Relocate the root (/) file system to the lead member. For example: # cfsmgr -h polishham -r -a SERVER=provolone / b. Verify that the lead member can serve applications to clients. Make sure that the lead member can serve all important applications that the cluster makes available to its clients. You decide how and what to test. We suggest that you thoroughly exercise critical applications and satisfy yourself that the lead member can serve these applications to clients before continuing the roll. For example: o Manually relocate CAA services to the lead member. For example, to relocate the application resource named cluster_lockd to lead member provolone: # caa_relocate cluster_lockd -c provolone o Temporarily modify the default cluster alias selection priority attribute, selp, to force the lead member to serve all client requests directed to that alias. For example: # cluamgr -a alias=DEFAULTALIAS,selp=100 The lead member is now the end recipient for all connection requests and packets addressed to the default cluster alias. From another member or from an outside client, use services such as telnet and ftp to verify that the lead member can handle alias traffic. Test client access to all important services that the cluster provides. When you are satisfied, reset the alias attributes on the lead member to their original values. 7. Perform the postinstall stage ("Postinstall Stage"). On the lead member, run: # clu_upgrade postinstall 8. Perform the roll stage ("Roll Stage"). Roll the members of the cluster that have not already rolled.[1] You can roll multiple members simultaneously (parallel roll), subject to the restriction that the number of members not being rolled (plus the quorum disk, if one is configured) is sufficient to maintain cluster quorum. To roll a member, do the following: a. Halt the member system and boot it to single-user mode. For example: # shutdown -h now >>> boot -fl s b. When the system reaches single-user mode, run the following commands: # init s # bcheckrc # lmf reset c. Roll the member: # clu_upgrade roll If you are performing parallel rolls, use the -f option with the clu_upgrade roll command. This option causes the member to automatically reboot without first prompting for permission: # clu_upgrade -f roll The roll command verifies that rolling the member will not result in a loss of quorum. If a loss of quorum will result, then the roll of the member does not occur and an error message is displayed. You can roll the member later, after one of the currently rolling members has rejoined the cluster and its quorum vote is available. If the roll proceeds, the member is prepared for a reboot. If you used the -f option, no prompt is displayed; the reboot occurs automatically. If you did not use the -f option, clu_upgrade displays a prompt that asks whether you want to reboot at this time. Unless you want to examine something specific before you reboot, enter yes. (If you enter yes, it may take approximately half a minute before the actual reboot occurs.) Perform parallel rolls to minimize the time needed to complete the roll stage. For example, on an eight-member cluster with a quorum disk, after rolling the lead member, you can roll four members in parallel. i. Begin the roll stage on a member. (The lead member was rolled during the install stage. You do not perform the roll stage on the lead member.) ii. When you see a message similar to the following, begin the roll stage on the next member: *** Info *** You may now begin the roll of another cluster member. If you see a message that begins like the following, it is probably caused by the number of currently rolling members that contribute member votes. *** Info *** The current quorum conditions indicate that beginning a roll of another member at this time may result in the loss of quorum. In this case, you have the following options: o You can wait until a member completes the roll stage before you begin to roll the next member. o If there is an unrolled member that does not contribute member votes, you can begin the roll stage on it. d. Continue to roll members until all members of the cluster have rolled. Before starting each roll stage, wait until you see the message that it is all right to do so. When you roll the last member, you will see a message similar to the following: *** Info *** This is the last member requiring a roll. [Note] Note: The roll actually takes place during the reboot. The clu_upgrade roll command sets up the it(8) scripts that will be run during the reboot. When you reboot, the it scripts roll the member, build a customized kernel, and then reboot again so the member will be running on its new customized kernel. When the member boots its new customized kernel, it has completed its roll and is no longer running on tagged files. 9. Perform the switch stage ("Switch Stage"). After all members have rolled, run the switch command on any member. # clu_upgrade switch 10. One at a time, reboot each member of the cluster. 11. Perform the clean stage ("Clean Stage"). Run the following command on any member to remove the tagged (.Old..) files from the cluster and complete the upgrade. # clu_upgrade clean 4.1.4 Removing Patches Installed During a Rolling Upgrade The following sections provide important information you need to be aware of if you remove or reinstall patches during a rolling upgrade. 4.1.4.1 Undoing a CSP or ERP When Paused at the Postinstall Stage When applying an ERP or CSP to a TruCluster system it is good practice to stop at the Postinstall stage and perform testing of the patch prior to rolling the patch on all the cluster members. This can help reduce further impacts to the cluster. Installing the ERP/CSP using the Rolling Patch method is fairly straightforward. The removal of the patch is where questions arise. This note provides a summary of the steps and commands used to perform this task on a two-member TruCluster system. This procedure assumes that the ERP/CSP was installed using the Rolling Patch upgrade method (using clu_upgrade) and not the No Roll method. This procedure does not apply to ERPs or CSPs that where installed using the NoRoll method or to situations where the ERP/CSP was installed on a single member TruCluster system. Prior to installing patches, always make sure to maintain current backups of the following file systems for a TruCluster system, along with disklabels for associated disks. Also note system configuration information using the sys_check -all command. o / = cluster_root#root Shared by all members o /usr = cluster_usr#usr Shared by all members o /var = cluster_var#varShared by all members o /cluster/members/member1/boot_partition = root1_domain#root Member1 Member specific root file system. o /cluster/members/member1/boot_partition = root2_domain#root Member2 Member specific root file system o Any additional Member specific root file systems Summary of Steps: 1. While logged on to Server 1 (Lead Member) perform the undo of the Postinstall stage. # clu_upgrade undo postinstall 2. Shut down SERVER1 (Lead Member) then boot single-user mode to run the dupatch patch removal program. Do not shut down to single-user level. Instead, shut down the system and boot to single-user mode: # shutdown -h now P00>> boot -fl s Entering Single-User Mode 3. Perform the following commands on SERVER1: # init s # bcheckrc # lmf reset 4. Perform the dupatch delete procedure. For systems running Patch Kit 4 and earlier, SERVER1 (Lead Member) must be at single-user mode for this procedure. With systems running Patch Kit 5 and later, you can run the procedure in multi-user mode. Change directories to the location of the CSP patch and run dupatch. # cd /usr/patch_kit a. Run dupatch on SERVER1 and select Patch Kit Deletion from the Main Menu: # ./dupatch 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: 2 Ignore any Special Instructions displayed at this time; they do not apply to ERPs or CSPs. You should, however, refer to the ERP/CSP Patch Release Notes for any special instructions specific to the ERP/CSP being removed. b. After the Special Instructions are presented, the following menu is displayed: 1) Patches for Tru64 UNIX V5.1B 2) Patches for TruCluster Server V5.1B If the CSP/ERP is a base operating system patch select 1, if the patch is specific to TruCluster, select 2. c. Enter you name and comment when prompted. d. Following the display of a long listing of operating system or TruCluster patches (depending on selection made in last menu) identify the patch from the list and select it. e. The patch will then be deleted and, if necessary, a new kernel will be built. f. When prompted to reboot answer yes; if not prompted, manually reboot system. 5. With the dupatch deletion completed and the Lead Member rebooted, perform undo of the Install Stage as follows: # shutdown -h now Halted P00>> On SERVER2 (Member2 or any Non-Lead Member) run enter the clu_upgrade undo install command. It warns to use dupatch, which has already completed, so answer yes. This restores tagged files and may take a few minutes (for example, 20 minutes on an ES45 using EVA5000 SAN storage): # clu_upgrade undo install 6. Boot the Lead Member into multi-user mode and perform undo of the Preinstall Stage. # clu_upgrade undo preinstall 7. Undo Setup Stage. To do this first you have to disable tagged files on other members (Member 2 (SERVER2) and so on). a. Check the status of the clu_upgrade process and if non-lead member is running on Tagged Files, perform the following command to disabled tagged files. The non-lead members should be running on tagged files at this time. # clu_upgrade tagged disable 2 [Note] : This command is run on Member2 (SERVER2) and the member ID 2 is passed as a parameter for this member. Any additional members need to be disabled also. b. Reboot the member that the Tagged Files where disabled on to complete the process; in this example, Member 2 (SERVER2). c. Run the undo Setup Stage on the lead member (SERVER1) to complete the deletion of the patch. This task takes approximately 10 minutes to complete. # clu_upgrade undo setup The cluster is now backed out from the clu_upgrade patch installation. 4.1.4.2 Caution on Removing Version Switched Patches When removing version switched patches on a cluster, do not remove version switched patches that were successfully installed in a previous rolling upgrade. This situation can occur because more than one patch subset may contain the same version switched patch. Although both the new and old patches can be removed during a roll, only the most recently installed, newer version switched patch can be properly removed. The older version switched patch can only be properly removed according to the documented procedure associated with that patch. This usually requires running some program before beginning the rolling upgrade to remove the patch. If you accidentally remove the older version switched patch, the rolling upgrade will most likely fail on the switch stage. To correct this situation, you will have to undo the upgrade by undoing all the stages up to and including the "install" stage. You will then need to reinstall the original version switched patch from the original patch kit that contained it. 4.1.4.3 Steps Prior to the Switch Stage You can remove a patch kit you installed during the rolling upgrade at any time prior to issuing the clu_upgrade switch command by returning to the install stage, rerunning dupatch, and selecting the Patch Deletion item in the Main Menu. See "Removing Patches" for information about removing patches with dupatch. The procedure is as follows: 1. Uninstall the patch kit as described in "Removing Patches". 2. Run the clu_upgrade undo install command. Note that although you do not have to run the clu_upgrade install command when installing a patch kit or an NHD kit, you must run the clu_upgrade undo install command if you want to remove those kits and undo the install stage. After you run the clu_upgrade undo install, you can continue undoing stages as described in "Undoing a Stage". 4.1.4.4 Steps for After the Switch Stage To remove patches after you have issued the clu_upgrade switch command, you will have to complete the current rolling upgrade procedure and then rerun the procedure from the beginning (starting with the setup stage). When you run the install stage, you must bring down your system to single-user mode as described in steps 1 through 6 of "Installing Patches from Single-User Mode". When you rerun dupatch (step 7), select the Patch Deletion item in the Main Menu. See "Removing Patches" for information about removing patches with dupatch. If the patch uses the version switch, you can still remove the patch, even after you have issued the clu_upgrade switch command. Do this as follows: 1. Complete the current rolling upgrade procedure. 2. Undo the patch that uses the version switch by following the instructions in the release note for that patch. Note that the last step to undo the patch will require a shutdown of the entire cluster. 3. Rerun the rolling upgrade procedure from the beginning (starting with the setup stage). When you rerun dupatch, select the Patch Deletion item in the Main Menu. Use the grep command to learn which patches use the version switch. For example, in the C shell: # grep -l PATCH_REQUIRES_VERSION_SWITCH=\"Y\" /usr/.smdb./*PAT*.ctrl For information about version switches, see "Version Switch". [Note] Note: If you rerun the rolling upgrade procedure to remove patches, the prompts you receive during the setup stage will be different from those issued during the initial rolling upgrade. Those prompts will look as follows: Do you want to continue to upgrade the cluster? [yes]: Return What type of upgrade will be performed? 1) Rolling upgrade using the installupdate command 2) Rolling patch using the dupatch command 3) Both a rolling upgrade and a rolling patch 4) Exit cluster software upgrade Enter your choice: 2 4.1.5 Displaying the Status of a Rolling Upgrade The clu_upgrade command provides the following options for displaying the status of a rolling upgrade. You can run status commands at any time. o To display the overall status of a rolling upgrade: clu_upgrade -v or clu_upgrade -v status. o To determine whether you can run a stage: clu_upgrade check [stage]. If you do not specify a stage, clu_upgrade tests whether the next stage can be run. o To determine whether a stage has started or completed: clu_upgrade started stage or clu_upgrade completed stage. o To determine whether a member has rolled: clu_upgrade check roll memberid. o To verify whether tagged files have been created for a layered product: clu_upgrade tagged check [prod_code [prod_code ...]]. If you do not specify a product code, clu_upgrade inspects all tagged files in the cluster. [Note] Notes: During a roll, there might be two versions of the clu_upgrade command in the cluster - an older version used by members that have not yet rolled, and a newer version (if included in the update distribution or patch kit). The information that is displayed by the status command might differ depending on whether the command is run on a member that has rolled. Therefore, if you run the status command on two members, do not be surprised if the format of the displayed output is not the same. If you run clu_upgrade status after running installupdate, clu_upgrade will display a message indicating that the install stage is complete. However, the install stage is not really complete until you run the clu_upgrade postinstall command. 4.1.6 Undoing a Stage The clu_upgrade undo command provides the ability to undo a rolling upgrade that has not completed the switch stage. You can undo any stage except the switch stage and the clean stage. You must undo stages in order; for example, if you decide to undo a rolling upgrade after completing the preinstall stage, you undo the preinstall stage and then undo the setup stage. [Note] Note: Before undoing any stage, we recommend that you read the relevant version of the Cluster Release Notes to determine whether there are restrictions related to the undoing of any stage. To undo a stage, use the undo command with the stage that you want to undo. The clu_upgrade command determines whether the specified stage is a valid stage to undo. Table 4.3 "Undoing a Stage" outlines the requirements for undoing a stage: Table 4.3 Undoing a Stage +------------------------------------------------------------------------+ | Stage to Undo | Command | Comments | |---------------+------------------+-------------------------------------| | Setup | clu_upgrade undo | You must run this command on the | | | setup | lead member. In addition, no | | | | members can be running on tagged | | | | files when you undo the setup | | | | stage. | | | | | | | | Before you undo the setup stage, | | | | use the clu_upgrade -v status | | | | command to determine which members | | | | are running on tagged files. Then | | | | use the clu_upgrade tagged disable | | | | memberid command to disable tagged | | | | files on those members. (See | | | | "Tagged Files" for information | | | | about tagged files and the commands | | | | used to manipulate them.) | | | | | | | | When no members are running on | | | | tagged files, run the clu_upgrade | | | | undo setup command on the lead | | | | member. | |---------------+------------------+-------------------------------------| | Preinstall | clu_upgrade undo | You must run this command on the | | | preinstall | lead member. | |---------------+------------------+-------------------------------------| | Install | clu_upgrade undo | You can run this command on any | | | install | member except the lead member. | | | | | | | | Halt the lead member. Then run the | | | | clu_upgrade undo install command on | | | | any member that has access to the | | | | halted lead member's boot disk. | | | | When the command completes, boot | | | | the lead member. | | | | | | | | If you installed a patch kit or | | | | individual patches during the | | | | install stage, you must first run | | | | dupatch to uninstall the patch kit | | | | before running the clu_upgrade undo | | | | install command. "Removing Patches | | | | Installed During a Rolling Upgrade" | | | | describes the steps for removing a | | | | patch kit during a rolling upgrade. | |---------------+------------------+-------------------------------------| | Postinstall | clu_upgrade undo | You must run this command on the | | | postinstall | lead member. | |---------------+------------------+-------------------------------------| | Roll | clu_upgrade undo | You can run this command on any | | | roll memberid | member except the member whose roll | | | | stage will be undone. | | | | | | | | Halt the member whose roll stage is | | | | being undone. Then run the | | | | clu_upgrade undo roll memberid | | | | command on any other member that | | | | has access to the halted member's | | | | boot disk. When the command | | | | completes, boot the halted member. | | | | The member will now be using tagged | | | | files. | +------------------------------------------------------------------------+ 4.1.7 Rolling Upgrade Commands The clu_upgrade command, described in clu_upgrade(8), controls the overall flow of a rolling upgrade and ensures that the stages are run in order. During the install stage, you run one or more of installupdate, dupatch, or nhd_install to load and install software. These commands are rolling upgrade aware; they are modified to understand which actions they are allowed to take during the install and roll stages of a rolling upgrade. When you start a rolling upgrade, the cluster is running the software from the previous release. For the first part of any rolling upgrade, you are running the clu_upgrade command that is already installed on the cluster. If a new version is installed during the rolling upgrade, there may be minor differences in the on-screen display and behavior between the two versions of the command. The following two tables show at which stages during a rolling upgrade new versions of upgrade commands, if shipped with the kits being installed, become available during a rolling upgrade:[2] o Table 4.4 "Stages and clu_upgrade Versions When Performing a Rolling Upgrade from Version 5.1A" maps commands to stages for a rolling upgrade from Version 5.1A to Version 5.1B, a patch kit, or an NHD kit; or to Version 5.1B of the base operating system and cluster software followed by a patch of the new software within the same rolling upgrade. o Table 4.5 "Stages and clu_upgrade Versions When Performing a Rolling Upgrade from Version 5.1B" maps commands to stages for a rolling upgrade from Version 5.1B to the next release of the operating system and cluster software, a Version 5.1B patch kit, or an NHD kit; or to the next release of the base operating system and cluster software followed by a patch of the new software within the same rolling upgrade. Table 4.4 Stages and clu_upgrade Versions When Performing a Rolling Upgrade from Version 5.1A +------------------------------------------------------------------------+ | Stage | Version | Next | Comments | | | 5.1A | Release[a] | | |--------------+----------+-------------+--------------------------------| | Preparation | X | | The currently installed (old) | | | | | version of clu_upgrade is | | | | | always run in this stage. | |--------------+----------+-------------+--------------------------------| | Setup | X | | The currently installed (old) | | | | | version of clu_upgrade is | | | | | always run in this stage. | | | | | | | | | | If performing an update | | | | | installation, the new version | | | | | of the clu_upgrade is | | | | | extracted from the TruCluster | | | | | software kit and installed at | | | | | /usr/sbin/clu_upgrade, | | | | | replacing the old version. | | | | | Because this replacement is | | | | | done before tagged files are | | | | | created, all members will use | | | | | the new clu_upgrade throughout | | | | | the remainder of the rolling | | | | | upgrade. | |--------------+----------+-------------+--------------------------------| | Preinstall | | X | If the rolling upgrade | | | | | includes an update | | | | | installation, all members use | | | | | the new version of clu_upgrade | | | | | installed during the setup | | | | | stage. (Otherwise, members | | | | | continue to run the current | | | | | version of clu_upgrade.) | |--------------+----------+-------------+--------------------------------| | Install | | X | If the rolling upgrade | | | | | includes an update | | | | | installation, all members use | | | | | the version of clu_upgrade | | | | | installed during the setup | | | | | stage. | | | | | | | | | | During the update | | | | | installation, a new version of | | | | | installupdate replaces the old | | | | | one. | | | | | | | | | | A patch kit always installs | | | | | the latest version of dupatch. | | | | | | | | | | If performing a patch, and if | | | | | the patch kit includes a new | | | | | version of clu_upgrade, the | | | | | new version is installed and | | | | | will be used by all cluster | | | | | members starting with the | | | | | postinstall stage. | |--------------+----------+-------------+--------------------------------| | Postinstall | | X | If a new version of | | | | | clu_upgrade was installed in | | | | | either the setup stage or the | | | | | install stage, all members use | | | | | the new version. | |--------------+----------+-------------+--------------------------------| | Roll | | X | If a new version of | | | | | clu_upgrade was installed in | | | | | either the setup stage or the | | | | | install stage, all members use | | | | | the new version. | |--------------+----------+-------------+--------------------------------| | Switch | | X | If a new version of | | | | | clu_upgrade was installed in | | | | | either the setup stage or the | | | | | install stage, all members use | | | | | the new version. | |--------------+----------+-------------+--------------------------------| | Clean | | X | If a new version of | | | | | clu_upgrade was installed in | | | | | either the setup stage or the | | | | | install stage, all members use | | | | | the new version. | |------------------------------------------------------------------------| | [a] Version 5.1B of Tru64 UNIX and TruCluster software, a patch kit | | for Version 5.1A, or the installation of an NHD kit on Version 5.1A. | +------------------------------------------------------------------------+ Table 4.5 Stages and clu_upgrade Versions When Performing a Rolling Upgrade from Version 5.1B +------------------------------------------------------------------------+ | Stage | Version | Next | Comments | | | 5.1B | Release[a] | | |--------------+----------+------------+---------------------------------| | Preparation | X | | The currently installed (old) | | | | | version of clu_upgrade is | | | | | always run in this stage. | |--------------+----------+------------+---------------------------------| | Setup | X | | The currently installed (old) | | | | | version of clu_upgrade is | | | | | always run in this stage. | | | | | | | | | | If performing an update | | | | | installation, the new version | | | | | of the clu_upgrade is extracted | | | | | from the TruCluster software | | | | | kit and installed at | | | | | /usr/sbin/clu_upgrade, | | | | | replacing the old version. | | | | | Because this replacement is | | | | | done before tagged files are | | | | | created, all members will use | | | | | the new clu_upgrade throughout | | | | | the remainder of the rolling | | | | | upgrade. | |--------------+----------+------------+---------------------------------| | Preinstall | | X | If the rolling upgrade includes | | | | | an update installation, all | | | | | members use the new version of | | | | | clu_upgrade installed during | | | | | the setup stage. (Otherwise, | | | | | members continue to run the | | | | | current version of | | | | | clu_upgrade.) | |--------------+----------+------------+---------------------------------| | Install | | X | If the rolling upgrade includes | | | | | an update installation, all | | | | | members use the version of | | | | | clu_upgrade installed during | | | | | the setup stage. | | | | | | | | | | During the update installation, | | | | | a new version of installupdate | | | | | replaces the old one. | | | | | | | | | | A patch kit always installs the | | | | | latest version of dupatch. | | | | | | | | | | If performing a patch, and if | | | | | the patch kit includes a new | | | | | version of clu_upgrade, the new | | | | | version is installed and will | | | | | be used by all cluster members | | | | | starting with the postinstall | | | | | stage. | |--------------+----------+------------+---------------------------------| | Postinstall | | X | If a new version of clu_upgrade | | | | | was installed in either the | | | | | setup stage or the install | | | | | stage, all members use the new | | | | | version. | |--------------+----------+------------+---------------------------------| | Roll | | X | If a new version of clu_upgrade | | | | | was installed in either the | | | | | setup stage or the install | | | | | stage, all members use the new | | | | | version. | |--------------+----------+------------+---------------------------------| | Switch | | X | If a new version of clu_upgrade | | | | | was installed in either the | | | | | setup stage or the install | | | | | stage, all members use the new | | | | | version. | |--------------+----------+------------+---------------------------------| | Clean | | X | If a new version of clu_upgrade | | | | | was installed in either the | | | | | setup stage or the install | | | | | stage, all members use the new | | | | | version. | |------------------------------------------------------------------------| | [a] The next release of Tru64 UNIX and TruCluster software, a patch | | kit for Version 5.1B, or the installation of an NHD kit on Version | | 5.1B. | +------------------------------------------------------------------------+ 4.1.8 Rolling Upgrade Stages The following sections describe each of the rolling upgrade stages. [Note] Note: These sections only describe the stages. Use the procedure in "Rolling Upgrade Procedure" to perform a rolling upgrade. o Preparation stage ("Preparation Stage") o Setup stage ("Setup Stage") o Preinstall stage ("Preinstall Stage") o Install stage ("Install Stage") o Postinstall stage ("Postinstall Stage") o Roll stage ("Roll Stage") o Switch stage ("Switch Stage") o Clean stage ("Clean Stage") 4.1.8.1 Preparation Stage +------------------------------------------------------------------------+ | Command | Where Run | Run Level | |-----------------------------------------+------------+-----------------| | clu_upgrade -v check setup | any member | multi-user mode | | lead_memberid | | | +------------------------------------------------------------------------+ During the preparation stage, you back up all important cluster data and verify that the cluster is ready for a roll. Before beginning a rolling upgrade, do the following: 1. Choose one member of the cluster as the first member to roll. This member, known as the lead member, must have direct access to the root (/), /usr, /var, and, if used, i18n file systems. Make sure that the lead member can run any critical applications. You can test these applications after you update this member during the install stage, but before you roll any other members. If a problem occurs, you can try to resolve it on this member before you continue. If you cannot resolve a problem, you can undo the rolling upgrade and return the cluster to its pre-roll state. ("Undoing a Stage" describes how to undo rolling upgrade stages.) 2. Back up the clusterwide root (/), /usr, and /var file systems, including all member-specific files in these file systems. If the cluster has a separate i18n file system, back up that file system. In addition, back up any other file systems that contain critical user or application data. [Note] Note: If you perform an incremental or full backup of the cluster during a rolling upgrade, make sure to perform the backup on a member that is not running on tagged files. If you back up from a member that is using tagged files, you will only back up the contents of the .Old.. files. Because the lead member never uses tagged files, you can back up the cluster from the lead member (or any other member that has rolled) during a rolling upgrade. Most sites have automated backup procedures. If you know that an automatic backup will take place while the cluster is in the middle of a rolling upgrade, make sure that backups are done on the lead member or on a member that has rolled. 3. If you plan to run the installupdate command in the install stage, remove any blocking layered products listed in Table 4.6 "Blocking Layered Products" that are installed on the cluster. 4. Run the clu_upgrade -v check setup lead_memberid command, which verifies the following information: o No rolling upgrade is in progress. o All members are running the same versions of the base operating system and cluster software. o No members are running on tagged files. o There is adequate free disk space. 5. Verify that each system's firmware will support the new software. Update firmware as needed before starting the rolling upgrade. A cluster can continue to operate during a rolling upgrade because two copies exist of the operating system and cluster software files. (Only one copy exists of shared configuration files so that changes made by any member are visible to all members.) This approach makes it possible to run two different versions of the base operating system and the cluster software at the same time in the same cluster. The trade-off is that, before you start an upgrade, you must make sure that there is adequate free space in each of the clusterwide root (/), /usr, and /var file systems, and, if a separate domain exists for the Worldwide Language Support (WLS) subsets, in the i18n file system. A rolling upgrade has the following disk space requirements: o At least 50 percent free space in root (/), cluster_root#root. o At least 50 percent free space in /usr, cluster_usr#usr. o At least 50 percent free space in /var, cluster_var#var, plus, if updating the operating system, an additional 425 MB to hold the subsets for the new version of the base operating system. o If a separate i18n domain exists for the WLS subsets, at least 50 percent free space in that domain. o No tagged files are placed on member boot partitions. However, programs might need free space when moving kernels to boot partitions. We recommend that you reserve at least 50 MB free space on each member's boot partition. [Note] Note: You cannot use the addvol command to add volumes to a member's root domain (the a partition on the member's boot disk). Instead, you must delete the member from the cluster, use diskconfig or SysMan to configure the disk appropriately, and then add the member back into the cluster. o See the Patch Summary and Release Notes that came with your patch kit to find the amount of space you will need to install that kit. If installing an NHD kit, see the New Hardware Delivery Release Notes and Installation Instructions that came with your NHD kit to find the amount of space you will need to install that kit. If a file system needs more free space, use AdvFS utilities such as addvol to add volumes to domains as needed. For information on managing AdvFS domains, see the Tru64 UNIX AdvFS Administration manual. (The AdvFS Utilities require a separate license.) You can also expand the clusterwide root (/) domain. [Note] Note: The clu_upgrade command verifies whether sufficient space exists at the start of a rolling upgrade. However, nothing prevents a cluster member from consuming disk space during a rolling upgrade, thus creating a situation where a later stage might not have enough disk space. Disk space is dynamic. If you know that a member will be consuming disk space during a rolling upgrade, add additional space before you start the upgrade. 4.1.8.2 Setup Stage +----------------------------------------------------------------+ | Command | Where Run | Run Level | |---------------------------------+------------+-----------------| | clu_upgrade setup lead_memberid | any member | multi-user mode | +----------------------------------------------------------------+ The setup stage performs the clu_upgrade check setup command, creates tagged files, and prepares the cluster for the roll. The clu_upgrade setup lead_memberid command performs the following tasks: o Creates the rolling upgrade log file, /cluster/admin/clu_upgrade.log. o Makes the -v check setup tests listed in "Preparation Stage". o Prompts you to indicate whether to perform an update installation, install a patch kit, install an NHD kit, or a combination thereof. The following example shows the menu displayed by the TruCluster software Version 5.1B clu_upgrade command: What type of rolling upgrade will be performed? Selection Type of Upgrade --------------------------------------------------------------- 1 An upgrade using the installupdate command 2 A patch using the dupatch command 3 A new hardware delivery using the nhd_install command 4 All of the above 5 None of the above 6 Help 7 Display all options again --------------------------------------------------------------- Enter your Choices (for example, 1 2 2-3): o If you specify an update installation, copies the relevant kits onto disk: o If performing an update installation, copies the cluster kit to /var/adm/update/TruClusterKit so that the kit will be available to the installupdate command during the install stage. (The installupdate command copies the operating system kit to /var/adm/update/OSKit during the install stage.) The clu_upgrade command prompts for the absolute pathname for the TruCluster software kit location. On a TruCluster software Version 5.1B cluster, when performing a rolling upgrade that includes an update installation, remember to mount the TruCluster software kit before running the clu_upgrade setup command. o On a TruCluster software Version 5.1B cluster, if performing an NHD installation, uses the nhd_install command to copy the NHD kit to /var/adm/update/NHDKit [Caution] Caution: The files in /var/adm/update are critical to the roll process. Do not remove or modify files in this directory. Doing so can cause a rolling upgrade to fail. o Creates the mandatory set of tagged files for the OSF (base), TCR (cluster), and IOS (Worldwide Language Support) products. [Note] Caution: If, for any reason, during an upgrade you need to create tagged files for a layered product, see "Tagged Files". o Sets the sysconfigtab variable rolls_ver_lookup=1 on all members except the lead member. When rolls_ver_lookup=1, a member uses tagged files. As a result, the lead member can upgrade while the remaining members run on the .Old.. files from the current release. o Prompts you to reboot all cluster members except the lead member. When the setup command completes, reboot these members one at a time so that the cluster can maintain quorum. This reboot is required for each member that will use tagged files in the mixed-version cluster. When the reboots complete, all members except the lead member are running on tagged files. 4.1.8.3 Preinstall Stage +--------------------------------------------------------+ | Command | Where Run | Run Level | |------------------------+-------------+-----------------| | clu_upgrade preinstall | lead member | multi-user mode | +--------------------------------------------------------+ The purpose of the preinstall stage is to verify that the cluster is ready for the lead member to run one or more of the installupdate, dupatch, or nhd_install commands. The clu_upgrade preinstall command performs the following tasks: o Verifies that the command is being run on the lead member, that the lead member is not running on tagged files, and that any other cluster members that are up are running on tagged files. o (Optional) Verifies that tagged files are present, that they match their product's inventory files, and that each tagged file's AdvFS property is set correctly. (This process can take a while, but not as long as it does to create the tagged files in the setup stage. Table 4.2 "Time Estimates for Rolling Upgrade Stages" provides time estimates for each stage.) o Makes on-disk backup copies of the lead member's member-specific files. 4.1.8.4 Install Stage +--------------------------------------------------------------+ | Command | Where Run | Run Level | |---------------+-------------+--------------------------------| | installupdate | lead member | single-user mode | |---------------+-------------+--------------------------------| | dupatch | lead member | single-user or multi-user mode | |---------------+-------------+--------------------------------| | nhd_install | lead member | single-user mode | +--------------------------------------------------------------+ If your current cluster is running TruCluster software Version 5.1B or Version 5.1A, you can perform one of the tasks or combinations of tasks listed in Table 4.1 "Rolling Upgrade Tasks Supported by Version 5.1A and Version 5.1B". The install stage starts when the clu_upgrade preinstall command completes, and continues until you run the clu_upgrade postinstall command. [Note] Note: If you run clu_upgrade status after running installupdate, clu_upgrade displays a message indicating that the install stage is complete. However, the install stage is not really complete until you run the clu_upgrade postinstall command. The lead member must be in single-user mode to run the installupdate command or the nhd_install command; single-user mode is recommended for the dupatch command. When taking the system to single-user mode, you must halt the system and then boot it to single-user mode. When the system is in single-user mode, run the init s, bcheckrc, and lmf reset commands before you run the installupdate, dupatch, or nhd_install commands. [Note] Notes: You can run the dupatch command multiple times in order to install multiple patches. Doing so may make isolating problems difficult if any arise after the patch process is completed and the cluster is in use. During the install stage, you cannot run a dupatch command followed by an installupdate command. To patch the current software before you perform a rolling upgrade, you must perform two complete rolling upgrade operations: one to patch the current software, and one to perform the update installation. If an NHD installation is part of a rolling upgrade that includes an update installation, you do not have to manually run nhd_install; the installupdate command will install the NHD kit. Otherwise, use the nhd_install command copied by clu_upgrade during the setup stage: /var/adm/update/NHDKit/nhd_install. 4.1.8.5 Postinstall Stage +---------------------------------------------------------+ | Command | Where Run | Run Level | |-------------------------+-------------+-----------------| | clu_upgrade postinstall | lead member | multi-user mode | +---------------------------------------------------------+ The postinstall stage verifies that the lead member has completed an update installation, a patch, or an NHD installation. If an update installation was performed, clu_upgrade postinstall verifies that the lead member has rolled to the new version of the base operating system. 4.1.8.6 Roll Stage +-----------------------------------------------------------+ | Command | Where Run | Run Level | |------------------+---------------------+------------------| | clu_upgrade roll | member being rolled | single-user mode | +-----------------------------------------------------------+ The lead member was upgraded in the install stage. The remaining members are upgraded in the roll stage. In many cluster configurations, you can roll multiple members in parallel and shorten the time required to upgrade the cluster. The number of members rolled in parallel is limited only by the requirement that the members not being rolled (plus the quorum disk, if one is configured) have sufficient votes to maintain quorum. Parallel rolls can be performed only after the lead member is rolled. The clu_upgrade roll command performs the following tasks: o Verifies that the member is not the lead member, that the member has not already been rolled, and that the member is in single-user mode. Verifies that rolling the member will not result in a loss of quorum. o Backs up the member's member-specific files. o Sets up the it(8) scripts that will be run on reboot to perform the roll. o Reboots the member. During this boot, the it scripts roll the member, build a customized kernel, and reboot with the customized kernel. [Note] Note: If you need to add a member to the cluster during a rolling upgrade, you must add the member from a member that has completed its roll. If a member goes down (and cannot be repaired and rebooted) before all members have rolled, you must delete the member to complete the roll of the cluster. However, if you have rolled all members but one, and this member goes down before it has rebooted in the roll stage, you must delete this member and then reboot any other member of the cluster. (The clu_upgrade command runs during reboot and tracks the number of members rolled versus the number of members currently in the cluster; clu_upgrade marks the roll stage as completed when the two values are equal. That is why, in the case where you have rolled all members except one, deleting the unrolled member and rebooting another member completes the roll stage and lets you continue the rolling upgrade.) 4.1.8.7 Switch Stage +------------------------------------------------------------------------+ | Command | Where Run | Run Level | |------------------------+----------------+------------------------------| | clu_upgrade switch | any member | multi-user mode | | | | | | | | All members must be up and | | | | running[a] | |------------------------------------------------------------------------| | [a] You can override this requirement by using the -f option to the | | switch command. However, all members' boot disks must be accessible | | for the -f option to work. | +------------------------------------------------------------------------+ The switch stage sets the active version of the software to the new version, which results in turning on any new features that had been deliberately disabled during the rolling upgrade. (See "Version Switch" for a description of active version and new version.) The clu_upgrade switch command performs the following tasks: o Verifies that all members have rolled, that all members are running the same versions of the base operating system and cluster software, and that no members are running on tagged files. o Sets the new version ID in each member's sysconfigtab file and running kernel. o Sets the active version to the new version for all cluster members. [Note] Note: After the switch stage completes, you must reboot each member of the cluster, one at a time. 4.1.8.8 Clean Stage +--------------------------------------------------+ | Command | Where Run | Run Level | |-------------------+------------+-----------------| | clu_upgrade clean | any member | multi-user mode | +--------------------------------------------------+ The clean stage removes the tagged (.Old..) files from the cluster and completes the upgrade. The clu_upgrade clean command performs the following tasks: o Verifies that the switch stage has completed, that all members are running the same versions of the base operating system and cluster software, and that no members are running on tagged files. o Removes all .Old.. files. o Removes any on-disk backup archives that clu_upgrade created. o If the directory exists, recursively deletes /var/adm/update/TruClusterKit, /var/adm/update/OSKit, and /var/adm/update/NHDKit. o If an update installation was performed, gives you the option of running the Update Administration Utility (updadmin) to manage the files that were saved during an update installation. o Creates an archive directory for this upgrade, /cluster/admin/clu_upgrade/history/release_version, and moves the clu_upgrade.log file to the archive directory. 4.1.9 Tagged Files A rolling upgrade updates the software on one cluster member at a time. To support two versions of software within the cluster during a roll, clu_upgrade creates a set of tagged files in the setup stage. A tagged file is a copy of a current file with .Old.. prepended to the copy filename, and an AdvFS property (DEC_VERSION_TAG) set on the copy. For example, the tagged file for the vdump command is named /sbin/.Old..vdump. Because tagged files are created in the same file system as the original files, you must have adequate free disk space before beginning a rolling upgrade. Whether a member is running on tagged files is controlled by that member's sysconfigtab rolls_ver_lookup variable. The upgrade commands set the value to 1 when a member must run on tagged files, and to 0 when a member must not run on tagged files. If a member's sysconfigtab rolls_ver_lookup attribute is set to 1, pathname resolution includes determining whether a specified filename has a .Old..filename copy and whether the copy has the DEC_VERSION_TAG property set on it. If both conditions are met, the requested file operation is transparently diverted to use the .Old..filename version of the file. Therefore, if the vdump command is issued on a member that has not rolled, the /sbin/.Old..vdump file is executed; if the command is issued on a member that has rolled, the /sbin/vdump file is executed. The only member that never runs on tagged files is the lead member (the first member to roll). [Note] Note: File system operations on directories are not bound by this tagged file restraint. For example, an ls of a directory on any cluster member during a rolling upgrade lists both versions of a file. However, the output of an ls -ail command on a member that has not rolled is different from the output on a member that has rolled. In the following examples the ls -ail command is run first on a member that has not rolled and then on a member that has rolled. (The awk utility is used to print only the inode, size, month and day timestamp, and name of each file.) The following output from the ls command is taken from a cluster member running with tags before it has rolled. The tagged files are the same as their untagged counterparts (same inode, size, and timestamp). When this member runs the hostname command, it runs the tagged version (inode 3643). # cd /sbin # ls -ail hostname .Old..hostname ls .Old..ls init .Old..init |\ awk '{printf("%d\t%d\t%s %s\t%s\n",$1,$6,$7,$8,$10)}` 3643 16416 Aug 24 .Old..hostname 3648 395600 Aug 24 .Old..init 3756 624320 Aug 24 .Old..ls 3643 16416 Aug 24 hostname 3648 395600 Aug 24 init 3756 624320 Aug 24 ls The following output from the ls command is taken from a cluster member running without tags after it has rolled. The tagged files now differ from their untagged counterparts (different inode, size, and timestamp). When this member runs the hostname command, it runs the non-tagged version (inode 1370). # cd /sbin # ls -ail hostname .Old..hostname ls .Old..ls init .Old..init |\ awk '{printf("%d\t%d\t%s %s\t%s\n",$1,$6,$7,$8,$10)}` 3643 16416 Aug 24 .Old..hostname 3648 395600 Aug 24 .Old..init 3756 624320 Aug 24 .Old..ls 1187 16528 Mar 12 hostname 1370 429280 Mar 12 init 1273 792640 Mar 12 ls After you create tagged files in the setup stage, we recommend that you run any administrative command, such as tar, from a member that has rolled. You can always run commands on the lead member because it never runs on tagged files. The following rules determine which files have tagged files automatically created for them in the setup stage: o Tagged files are created for inventory files for the following product codes: base operating system (OSF), TruCluster software (TCR), and Worldwide Language Support (IOS). (The subsets for each product use that product's three-letter product code as a prefix for each subset name. For example, TruCluster software subset names start with the TruCluster software three-letter product code: TCRBASE510, TCRMAN510, and TCRMIGRATE510.) o By default, files that are associated with other layered products do not have tagged files created for them. Tagged files are created only for layered products that have been modified to support tagged files during a rolling upgrade. [Caution] Caution: Unless a layered product's documentation specifically states that you can install a newer version of the product on the first rolled member, and that the layered product knows what actions to take in a mixed-version cluster, we strongly recommend that you do not install either a new layered product or a new version of a currently installed layered product during a rolling upgrade. The clu_upgrade command provides several tagged command options to manipulate tagged files: check, add, remove, enable, and disable. When dealing with tagged files, take the following into consideration: o During a normal rolling upgrade you do not have to manually add or remove tagged files. The clu_upgrade command calls the tagged commands as needed to control the creation and removal of tagged files. o If you run a clu_upgrade tagged command, run the check, add, and remove commands on a member that is not running on tagged files; for example, the lead member. You can run the disable and enable commands on any member. o The target for a check, add, or remove tagged file operation is a product code that represents an entire product. The clu_upgrade tagged commands operate on all inventory files for the specified product or products. For example, the following command verifies the correctness of all the tagged files created for the TCR kernel layered product (the TruCluster software subsets): # clu_upgrade tagged check TCR If you inadvertently remove a .Old.. copy of a file, you must create tagged files for the entire layered product to re-create that one file. For example, the vdump command is in the OSFADVFSxxx subset, which is part of the OSF product. If you mistakenly remove /sbin/.Old..vdump, run the following command to re-create tagged files for the entire layered product: # clu_upgrade tagged add OSF o The enable and disable commands enable or disable the use of tagged files by a cluster member. You do not have to use enable or disable during a normal rolling upgrade. The disable command is useful if you have to undo the setup stage. Because no members can be running with tagged files when undoing the setup stage, you can use the disable command to disable tagged files on any cluster member that is currently running on tagged files. For example, to disable tagged files for a member whose ID is 3: # clu_upgrade tagged disable 3 The enable command is provided in case you make a mistake with the disable command. 4.1.10 Version Switch 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. The purpose of a version switch in a cluster is to prevent the introduction of potentially incompatible new features until all members have been updated. For example, if a new version introduces a change to a kernel structure that is incompatible with the current structure, you do not want cluster members to use the new structure until all members have updated to the version that supports it. At the start of a rolling upgrade, each member's active version is the same as its new version. When a member rolls, its new version is updated. After all members have rolled, the switch stage sets the active version to the new version on all members. At the completion of the upgrade, all members' active versions are again the same as their new versions. The following simple example uses an active version of 1 and a new version of 2 to illustrate the version transitions during a rolling upgrade: All members at start of roll: active (1) = new (1) Each member after its roll: active (1) != new (2) All members after switch stage: active (2) = new (2) The clu_upgrade command uses the versw command, which is described in versw(8), to manage version transitions. The clu_upgrade command manages all the version switch activity when rolling individual members. In the switch stage, after all members have rolled, the following command completes the transition to the new software: # clu_upgrade switch 4.1.11 Rolling Upgrade and Layered Products This section discusses the interaction of layered products and rolling upgrades: o General guidelines ("General Guidelines") o Blocking layered products ("Blocking Layered Products") 4.1.11.1 General Guidelines The clu_upgrade setup command prepares a cluster for a rolling upgrade of the operating system. Do not use the setld command to load software onto the cluster between performing the clu_upgrade setup command and rolling the first cluster member to the new version. If you install software between performing the clu_upgrade setup command and rolling a cluster member to the new version, the new files will not have been processed by clu_upgrade setup. As a result, when you roll the first cluster member, these new files will be overwritten. If you must load software: o Wait until at least one member has rolled. o Install the software on a member that has rolled. 4.1.11.2 Blocking Layered Products A blocking layered product is a product that prevents the installupdate command from completing. Blocking layered products must be removed from the cluster before starting a rolling upgrade that will include running the installupdate command. You do not have to remove blocking layered products when performing a rolling upgrade solely to patch the cluster or install an NHD kit. Table 4.6 "Blocking Layered Products" lists blocking layered products for this release. Table 4.6 Blocking Layered Products +-------------------------------------------------------------+ | Product Code | Description | |--------------+----------------------------------------------| | 3X0 | Open3D | |--------------+----------------------------------------------| | 4DT | Open3D | |--------------+----------------------------------------------| | ATM | Atom Advanced Developers Kit | |--------------+----------------------------------------------| | DCE | Distributed Computing Environment | |--------------+----------------------------------------------| | DNA | DECnet | |--------------+----------------------------------------------| | DTA | Developer's Toolkit (Program Analysis Tools) | |--------------+----------------------------------------------| | DTC | Developer's Toolkit (C compiler) | |--------------+----------------------------------------------| | MME | Multimedia Services | |--------------+----------------------------------------------| | O3D | Open 3D | |--------------+----------------------------------------------| | PRX | PanoramiX Advanced Developers Kit | +-------------------------------------------------------------+ [Note] Notes: The three-letter product codes are the first three letters of subset names. For example, a subset named ATMBASExxx is part of the ATM product (Atom Advanced Developers Kit), which is a blocking layered product. However, a subset named OSFATMBINxxx contains the letters ATM, but the subset is not part of a blocking layered product; it is a subset in the OSF product (the base operating system). When a blocking layered product is removed as part of the rolling upgrade, it is removed for all members. Any services that rely on the blocking product will not be available until the roll completes and the blocking layered product is reinstalled. 4.1.12 Rolling Upgrade and RIS When performing the install stage of a rolling upgrade, you can load the base operating system subsets from a CD-ROM or from a Remote Installation Services (RIS) server. [Note] Note: You can use RIS only to load the base operating system subsets. To use RIS, you must register both the lead member and the default cluster alias with the RIS server. When registering for operating system software, you must provide a hardware address for each host name. Therefore, you must create a hardware address for the default cluster alias in order to register the alias with the RIS server. (RIS will reject an address that is already in either of the RIS server's /etc/bootptab or /var/adm/ris/clients/risdb files.) If your cluster uses the cluster alias virtual MAC (vMAC) feature, register that virtual hardware address with the RIS server as the default cluster alias's hardware address. If your cluster does not use the vMAC feature, you can still use the algorithm that is described in the vMAC section of the Cluster Installation manual to manually create a hardware address for the default cluster alias. A vMAC address consists of a prefix (the default is AA:01) followed by the IP address of the alias in hexadecimal format. For example, the default vMAC address for the default cluster alias deli whose IP address is 16.140.112.209 is AA:01:10:8C:70:D1. The address is derived in the following manner: Default vMAC prefix: AA:01 Cluster Alias IP Address: 16.140.112.209 IP address in hex. format: 10.8C.70.D1 vMAC for this alias: AA:01:10:8C:70:D1 Another method for creating a hardware address is to append an arbitrary string of eight hexadecimal numbers to the default vMAC prefix, AA:01. For example, AA:01:00:00:00:00. Make sure that the address is unique within the area served by the RIS server. If you have more than one cluster, remember to increment the arbitrary hexadecimal string when adding the next alias. (The vMAC algorithm is useful because it creates an address that has a high probability of being unique within your network.) 4.2 No-Roll Patching The no-roll patch process lets you install patches on a cluster without performing a rolling upgrade. This chapter provides the following information: o An overview of the no-roll patch process ("Overview") o A step-by-step description of the process as it differs from a normal dupatch session ("Steps for Running a No-Roll Procedure") o Throwing the version switch ("Throwing the Version Switch") o How to remove patches from a cluster using the no-roll patch method ("Removing Patches") [Note] Note: The no-roll technology is included in Rev. 34-00 and higher of the dupatch utility. You can find the revision number on the first output line you see when you run dupatch (see the example in "Steps for Running a No-Roll Procedure"). The first kit that includes this technology was issued in April 2002. 4.2.1 Overview A rolling upgrade lets you perform a software upgrade on a cluster while maintaining high availability of the cluster. To provide this high availability, a certain amount of setup work is required to build tagged files and to reboot the cluster members to use the tagged files. This can take a considerable amount of time. However, if you have a mission-critical environment and want to use a patch method that applies patches quickly, minimizes down time of the cluster, and reduces the number of reboots required, you might want to use the no-roll patch process. This process patches your cluster in one operation that requires only one or two reboots of the whole cluster to complete the operation. You will need the second reboot only if you install a patch that contains a version switch (see "Throwing the Version Switch"). The no-roll patch process is a modification of dupatch; that is, all patches are installed or removed entirely using the dupatch utility, as opposed to the clu_upgrade and dupatch utilities used in the rolling upgrade procedure. The no-roll process conducts significantly fewer operations than the rolling upgrade procedure. While a no-roll patch installation is in progress, no other critical operations should be running on the cluster because the cluster will change state and reboot automatically at various stages of the procedure. In addition, the no-roll patch procedure employs the use of the Tru64 UNIX Event Management System (EVM) to send cluster-wide events. As a result, patches must be applied to the system in multi-user mode. If you attempt to use the no-roll procedure while in single-user mode, you will be advised to change the cluster to multi-user mode before continuing. 4.2.2 Steps for Running a No-Roll Procedure The following steps describe how to patch your cluster using the no-roll procedure. [Note] NOTE: To use the no-roll patch method, you must not use the clu_upgrade utility to prepare the cluster, as you would for a rolling upgrade prior to running dupatch. If a rolling upgrade is in progress before attempting to run dupatch, then the no-roll option will not be available until the cluster is restored to the state prior to the roll attempt. 1. With your system running in multi-user mode, enter the dupatch command: # dupatch 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: 2. From the main menu select the patch installation or patch deletion option. (See "Installing Patches from Multi-User Mode".) 3. If dupatch determines it is running on a cluster that has not been prepared to do a rolling patch, it asks if you want to do the patch operation without rolling. You will see a message similar to the following: Checking Cluster State...done This system is part of a cluster which has not been prepared to do a rolling patch installation or deletion. Do you wish to perform this patch operation cluster-wide without using the rolling-patch mechanism? Please answer y or n ? [y/n]: If you choose y, dupatch proceeds by allowing you to do the analysis and selection of patches to be installed or removed, after which the whole cluster is brought down to init level 2 via an Event Management System event. If you are using dupatch from the command line and do not specify the -proceed option, you will need to press Return in order to transition the cluster from level 3 to level 2. If the -proceed option was set, the transition will occur automatically. After dupatch completes its patch analysis, it will perform the patch operation on the member on which you ran dupatch. After the patches are installed or removed, dupatch will issue a second event to the remaining cluster members that will instruct them to complete their patch operations in parallel. The dupatch utility then waits a calculated time-out period for all the other cluster members to complete their operations. The time-out period is based on the time it took to perform the patch operation on the member running dupatch. After the patch operation is completed on all other cluster members, dupatch will complete the procedure on the member on which the dupatch command was issued. If a cluster member times out or encounters an error, dupatch will report the problem, suspend the process, and send you a message to check the problematic member in order to resolve the problem. Once dupatch has resumed, it will complete the patch process on the rest of the cluster. If a cluster member is known to be down when you issue the dupatch command, an /sbin/it job will be posted for the member to run the cluster patch script upon reboot. (For more information, see the it(8) reference page.) Because all patches currently require a reboot, the whole cluster will reboot after all the members report back. 4.2.3 Throwing the Version Switch If a patch applied to the system requires the use of a version switch, you will see a message similar to the following at the end of the dupatch session: ********************************************************************* Patch OSFPAT00074200510 has been identified as needing a version switch. Once the following reboot is complete, please enter the "/var/adm/patch/noroll/noroll_versw" command from any cluster member. ********************************************************************* As indicated by the message, you must enter the /var/adm/patch/noroll/noroll_versw command from any cluster member. This is a manual operation that you must perform after the reboot is complete. All cluster members must be up prior to running the noroll_versw command. If they are not, the noroll_versw command will fail and the version switch will not take place. After issuing the noroll_versw command, reboot your system to ensure system integrity. 4.2.4 Removing Patches You cannot use the no-roll process to remove inclusive patch kits because you must run the versw_enable_delete script ("Run Mandatory Script Before Removing New Style Patch Kits"), which requires that you reboot each cluster member to remove the patch kit. Because the no-roll process automatically reboots the system after deleting the patches, you would not be able to reboot each member as required. 4.3 Using the dupclone Script You can install Version 5.1B-4 and higher on your cluster using an installation method generically referred to as cloning that uses a tool named dupclone . The process consists of two primary steps: o Creating an exact duplicate of an existing system on an alternate set of disk drives. o Using dupclone to install the patch kit to the alternate disk set. After completion, the system can immediately be rebooted using the alternate disks. [Note] Note: The examples in this section assume a two-node cluster that uses one disk drive each for the cluster-wide root, /usr, and /var file systems; one disk drive for each member boot disk; and 1 drive for the quorum disk. 4.3.1 Benefits and Detriments of Cloning The benefits of cluster cloning include the following: o The process can be performed in multi-user mode as a replacement for the no-roll installation method. o It does not require the shutdown of any cluster members while the patch kit is being installed o It provides an easy way to reverse the installation by simply rebooting on the original disk set. Reasons why cluster cloning may not be right for your cluster include the following: o It requires a complete cluster reboot and therefore will not be useful for systems required to be online 24/7 and rely on the rolling upgrade procedure. o It requires additional hardware. You must have enough spare disk drives that equals or exceeds the existing system disk set for the cluster root, /usr, /var, and member boot file systems. This includes the quorum disk. For example, if you have a three-member cluster and use one disk for the root and /var file systems, one disk for the /usr file system, and one disk for the quorum; you will need six additional disk drives to use cloning technology. 4.3.2 Performing the Cloned Installation To create an exact duplicate of your system on an alternate set of disk drives, you can find a third-party program that will do it for you, or you can use the following list of tasks as a guide for doing it yourself: o Identify the alternate set of disks you will use for the new software o Partition the alternate drives so those partitions are as large or larger than the current drive set o Duplicate all cluster file systems onto the alternate disk set. This includes cluster_root, cluster_usr, and cluster_var. o Duplicate all member-specific root partitions onto the alternate disk set. (that is, root1_domain, root2_domain, and so forth.) o Create the CNX partitions for all member root drives and the quorum disk (if it exists). Be careful to ensure that the alternate drive CNX partitions reference the disk device number of the alternate drives, not the drives used by the currently running operating system. For example: A cluster comprised of two members has the following disk setup. dsk0a: contains the cluster_root file system dsk0g: contains the cluster_var file system dsk1g: contains the cluster_usr file system dsk2a: contains the member1 root partition dsk2h: contains the member1 CNX partition dsk3a: contains the member2 root partition dsk3h: contains the member2 CNX partition dsk4h: contains the quorum disk partition Additionally, the cluster has five unused disks available to it (dsk10, dsk11, dsk12, dsk13, dsk14), which are as large as or larger than, the existing system disks. The spare drives are used as a duplicate, or "clone," of the existing operating system and they are mounted on a mount point called /clone" The steps are: 1. Partition dsk10a to be as large or larger than dsk0a 2. Partition dsk10g to be as large or larger than dsk0g 3. Partition dsk11g to be as large or larger than dsk1g 4. Partition dsk12a to be as large or larger than dsk2a 5. Partition dsk12h for the special size of a CNX partition 6. Partition dsk13a to be as large or larger than dsk3a 7. Partition dsk13h for the special size of a CNX partition 8. Partition dsk14h for the special size of a quorum disk 9. Build the CNX partitions for dsk12h, dsk13h, and dsk14h 10. Create AdvFS domains and file sets for all file systems (that is, alt_cluster_root, alt_cluster_usr, alt_cluster_var, alt_boot1, alt_boot2.) 11. Use common UNIX commands to exactly duplicate existing cluster and member file systems onto the alternate disks. 12. Mount all file systems in a hierarchical form on the mount point /clone. When these steps are complete, the mount command will display output similar to the following: # mount cluster_root#root on / type advfs (rw) root1_domain#root on /cluster/members/member1/boot_partition type advfs (rw) cluster_usr#usr on /usr type advfs (rw) cluster_var#var on /var type advfs (rw) root2_domain#root on /cluster/members/member2/boot_partition type advfs (rw) alt_cluster_root#root on /clone type advfs (rw) alt_cluster_usr#usr on /clone/usr type advfs (rw) alt_cluster_var#var on /clone/var type advfs (rw) alt_boot1#root on /clone/cluster/members/member1/boot_partition alt_boot2#root on /clone/cluster/members/member2/boot_partition The first five file systems in this output represent the current operating system version; the last five represent an exact duplicate of the current operating system mounted on an alternate root path named /clone." The final step is to apply the latest patch kit to the alternate root using the dupclone command. This will install the new patch kit onto the alternate set of drives, which can then be booted. If for any reason the installation or the reboot fails, you can simply reboot on the original set of disk drives. 4.3.2.1 dupclone(8) Reference Page This section reproduces the dupclone(8) reference page, which is installed on your system with the patch installation tools. NAME dupclone - Clone Tru64 UNIX cluster SYNOPSIS dupclone [-r rootpath] [-k kitpath] [-license] OPTIONS -r rootpath Identifies the root directory of the cloned operating system. -k kitpath Identifies the path to the patch kit being installed. -license Indicates that you accept the license agreement. A printed copy of the license agreement is included in the release notes that came with your patch kit. DESCRIPTION The dupclone command installs a Tru64 UNIX patch kit located at kitpath into an alternate root directory defined by rootpath. The specified rootpath must be the root directory of a complete identical copy of the existing Tru64 UNIX operating system, including all members of the cluster. The dupclone command can only be used on clusters. It is not supported for use on stand-alone systems. EXAMPLES The following example shows a typical cloning operation: # dupclone -r /clone -k /usr/T64/patch_kit -license You have accepted the license agreement. Cluster Name: jungle Member-1: apeman.zoo.com 10.0.0.1 Member-2: safari.zoo.com 10.0.0.2 Checking patch kit for transmission errors during download... Verifying current software on member 1 Verifying current software on member 2 Creating master inventory of current system... Getting list of patch subsets to install... . . . FILES cloneroot/usr/adm/dupatch/log/session.log This file captures dupclone activities. SEE ALSO Commands: dupatch(8) -------------- [1] The lead member was rolled during the install stage. Therefore, you do not perform the roll stage on the lead member. [2] The clu_upgrade version command displays the version number for clu_upgrade. The clu_upgrade version numbers do not correspond with the version numbers of the operating system. Appendix A Viewing Log files The dupatch utility captures patching activities in the following log files: o /var/adm/patch/log/session.log Every time you run dupatch it creates a session log that captures dupatch activities. The session.log files from the previous 25 sessions are saved. The order is first in, first out, with session.log.25 as the oldest file. o /var/adm/patch/log/Dupatch_load_Date.log When you run dupatch from the newly untarred kit or from the mounted Tru64 UNIX Patch CD-ROM, dupatch determines if the patch distribution contains new patch tools, and loads them if necessary. This log file has a name similar to this: Dupatch_load_2000Jul1:15:43:35.log o /var/adm/patch/log/baseline.log When you run the system baselining feature, dupatch creates a baseline log. The session.log files from the previous 25 sessions are saved. The order is first in, first out, with baseline.log.25 as the oldest file. o /var/adm/patch/log/event.log When patches are installed or removed, an event log captures that information. Only one copy of the file is updated each time patches are installed or removed. The information in the patch event log is not available through the dupatch user interface, but the log is a text file that you can view with a command such as more. The following list describes the types of information an event log provides, although the format and content are subject to change. Example A.1 " Sample Event Log" shows a typical event log. DUPATCH_REV> The revision of dupatch being used TYPE> The type of action that was taken; either install or remove NAME> The name entered by the user through a dupatch query USER> The name of the user performing the action NOTES> Notes that were entered by the user through a dupatch query KITLOC> The directory from which the patch kit was installed KITNAME> The name of the patch kit that was installed REVERT> The choice made on whether or not the patch installation is reversible BACKUP_DIRECTORY> A pointer to the directory that contains the original files before they were patched BACKUP_SETUP> A plain directory; not a mount point or a symbolic link SUCCEED> A list of patches for which the action succeeded FAIL> A list of patches for which the action failed Example A.1 Sample Event Log DUPATCH_REV>30-01 TYPE>install NAME>mstone USER>mstone DATE>Mon Jul 3 13:03:33 EST 2000 NOTES>Install BL13 patches from CD-ROM > KITLOC>/cdrom/DIGITAL_UNIX_V4.0F/patch_kit/DIGITAL_UNIX_V4.0F/kit KITNAME> OSF440 REVERT>Y BACKUP_DIRECTORY>//var/adm/patch/backup BACKUP_SETUP> SUCCEED>OSFPAT00001900440 Appendix B Common Error, Warning, and Informational Messages Table of Contents B.1 Patch Preinstallation Check and Installation Messages B.1.1 Patch Installation Blocked by Unknown System File B.1.2 Patch Installation Blocked by Missing System File B.1.3 Installation Blocked by Layered Product Collision B.1.4 Patch Installation Blocked by Dependencies on Other Patches B.1.5 Patch Installation Blocked by Missing Product Subset B.1.6 Patch Installation Blocked by Disk Space B.1.7 Patch Installation Blocked by Installed Patch or Subset B.1.8 Patch Installation Blocked by an Existing CSP B.1.9 The dupatch Tools Are Outdated B.1.10 Some Patches Must Be Made Reversible B.2 Patch Removal Messages B.2.1 Patch Removal Blocked by Missing Patch Backup Files B.2.2 Patch Removal Blocked by Dependencies on Other Patches B.2.3 No Original Files Restored When Patch Is Removed B.3 TruCluster Specific dupatch Messages B.3.1 System Not Adequately Prepared B.3.2 Rolling Upgrade in Progress (Installation) B.3.3 Rolling Upgrade in Progress (Baselining) B.3.4 Version 5.0 Wave 4 Cluster is Unsupported B.3.5 Patch Removal Fails Because Needed File Is Unavailable B.3.6 Patch Removal Fails Because of a Version Switch B.3.7 dupatch Cannot Create Needed File B.3.8 Insufficient Free Space (File System Full) This appendix describes error, warning, and informational messages for the dupatch utility. The following information is provided for each message: Source: The function that generates the message. Problem: A brief description of possible causes for the message. Causes: A summary of situations that cause the message. Action: General recovery guidance. Output: A sample of the message. B.1 Patch Preinstallation Check and Installation Messages The following sections describe messages you might see when running the dupatch preinstallation check or installation functions. B.1.1 Patch Installation Blocked by Unknown System File Source: dupatch preinstallation check or installation. Problem: The installation of a specific patch is blocked due to an existing system file that is unknown. Cause: This situation usually occurs when system files are placed on the system through manual intervention. For example, this may have been the result of installing a Customer-Specific patch received from HP Services or a system administrator's customization of a Tru64 UNIX file. Until you confirm otherwise, the unknown system files should be viewed as intentional customizations that are important for proper system operation. As such, care should be taken to understand why the system files have been customized. Action: Determine the origin of the existing unknown system files. The steps you take will be determined by the reason your system files were manually changed. See "Creating a Baseline" for more information. Output: Checking patch prerequisites and patch file applicability ... (depending upon the number of patches you select, this may take a while) ------------------------------------------------------------------------- Problem installing: - DIGITAL_UNIX_V4.0F / Common Desktop Environment (CDE) Patches: Patch 0326.00 - CDE Login Correction ./usr/dt/bin/dtwm: its origin cannot be identified. This patch will not be installed. ------------------------------------------------------------------------- * Following patch(es) failed in prerequisite/file applicability check: - TRU64_UNIX_V4.0D / Common Desktop Environment (CDE) Patches: Patch 0326.00 - CDE Login Correction B.1.2 Patch Installation Blocked by Missing System File Source: dupatch preinstallation check or installation. Problem: Installation of a specific patch is blocked due to missing system file. Causes: This situation usually occurs when a system file that was installed with setld is manually removed from the system. The file is marked as installed in the system inventory records. Action: Determine why the system file is missing and whether it is safe to enable dupatch to install the blocked patch. See "Creating a Baseline" for more information. Output: Checking patch prerequisites and patch file applicability... (depending upon the number of patches you select, this may take a while) ------------------------------------------------------------------------- Problem installing: - DIGITAL_UNIX_V4.0F / Commands, Shells, & Utility Patches: Patch 0236.00 - vi Editor Correction ./usr/bin/vedit: does not exist on your system, however, it is in the inventory of installed subsets. This patch will not be installed. ------------------------------------------------------------------------- * Following patch(es) failed in prerequisite/file applicability check: - DIGITAL_UNIX_V4.0F / Commands, Shells, & Utility Patches: Patch 0236.00 - vi Editor Correction B.1.3 Installation Blocked by Layered Product Collision Source: dupatch preinstallation check or installation. Problem: The installation of a specific patch is blocked due to an existing system file that is installed by a layered product. Causes: A small set of layered products deliver updated Tru64 UNIX operating system files. Action: To resolve this situation contact the Product Customer Services representative. Output: Checking patch prerequisites and patch file applicability... (depending upon the number of patches you select, this may take a while) ------------------------------------------------------------------------- Problem installing: - TRU_UNIX_V4.0F / Network Patches: Patch 0182.00 - xti/streams Interface Module Correction ./sys/BINARY/xtiso.mod: is installed by: BLTLPCONFLICTTEST410 and can not be replaced by this patch. This patch will not be installed. ------------------------------------------------------------------------- * Following patch(es) failed in prerequisite/file applicability check: - DIGITAL_UNIX_V4.0F / Network Patches: Patch 0182.00 - xti/streams Interface Module Correction B.1.4 Patch Installation Blocked by Dependencies on Other Patches Source: dupatch preinstallation check or installation. Problem: The installation of a specific patch is blocked due to its dependency on other uninstalled patches. Causes: This usually occurs when you miss the selection of all dependent patches. It only occurs in old style patch kits. Action: Through the dupatch Installation Menu, take one of the following actions: o Reselect the patches including the noted dependent patch and attempt reinstallation; dupatch will notify you of other missing dependent patches. o Select all patches and proceed with patch installation. Output: SAMPLE OUTPUT: Checking patch prerequisites and patch file applicability... (depending upon the number of patches you select, this may take a while) ------------------------------------------------------------------------- Problem installing: - DIGITAL_UNIX_V4.0F / Security Related Patches: Patch 0579.01 - Security, Various Kernel Fixes (SSRT0482U) requires the existence of the following un-installed/un-selected subset(s): - TruCluster_V1.6 / Filesystem Patches: Patch 0037.00 - Support For New AdvFS Mount Option "-o noatimes" - TruCluster_V1.6 / ASE Availability Manager (AM) Patches: Patch 0033.00 - Kern Mem Fault And simple_lock Panic Correction This patch will not be installed. ------------------------------------------------------------------------- * Following patch(es) failed in prerequisite/file applicability check: - TRU64L_UNIX_V4.0F / Security Related Patches: Patch 0579.01 - Security, Various Kernel Fixes (SSRT0482U) B.1.5 Patch Installation Blocked by Missing Product Subset Source: dupatch preinstallation check or installation. Problem: A specific patch cannot be installed because the product software subset is not installed on your system. Causes: This is usually an informational message and no further action is required. However, this message may also occur due to an internal patch kit error that results in an incorrectly specified patch dependency. Action: If the specific patch being blocked is the only patch being blocked you can assume this is an informational message. It may be an internal patch kit error if there are other patches whose installation is blocked by the patch whose subset is not installed. As a workaround, if you need one of the other patches whose installation is blocked, you can install the optional Tru64 UNIX or TCR release subset and reinstall the patches. Output: Checking patch prerequisites and patch file applicability... (depending upon the number of patches you select, this may take a while) ------------------------------------------------------------------------- Problem installing: - TruCluster_V1.6 / Cluster Kernel Patches: Patch 0035.00 - rm_spur Driver Correction requires the existence of the following un-installed/un-selected subset(s): - TruCluster_V1.6 - subset: TCRMCA141 This patch will not be installed. ------------------------------------------------------------------------- * Following patch(es) failed in prerequisite/file applicability check: - TruCluster_V1.6 / Cluster Kernel Patches: Patch 0035.00 - rm_spur Driver Correction B.1.6 Patch Installation Blocked by Disk Space Source: dupatch preinstallation check or installation. Problem: The system disk did not have enough space to install patches. Causes: This occurs when there is not enough disk space in /, /var, or /usr partitions for dupatch to archive the existing system files and move the patched files into place. Action: Provide the necessary disk space and reinstall patches. If you cannot provide enough system disk space through other means, you may want to make /var/adm/patch/backup a symbolic link to or NFS-mount another file system that is not related to the /, /var, or /usr partitions. Output: Checking patch prerequisites once more... (depending upon the number of patches you select, this may take a while) ./usr/lbin/fitset: file system /whd needs 65829 Kbytes more to install the software specified. There is not enough file system space to install all the patches. you have selected. Please press RETURN to start another selection. . . . B.1.7 Patch Installation Blocked by Installed Patch or Subset Source: dupatch preinstallation check or installation. Problem: The patch you are trying to install is built so it cannot supersede the later revision patch or subset that is installed on your system. Causes: This applicability feature is used to ensure that your system is not regressed through the installation of older code. Action: If the situation is caused by a Release patch being blocked by a layered product or other subsets, contact your service provider. Output: Problem installing: - DIGITAL_UNIX_V4.0D / Filesystem Patches: Patch 00016.01 - System Run Level Correction ./sbin/.new..bcheckrc: is installed by: - DIGITAL_UNIX_V4.0D: Patch C 00484.01 and can not be replaced by this patch. This patch will not be installed. B.1.8 Patch Installation Blocked by an Existing CSP Source: dupatch preinstallation check or installation. Problem: Release patches will not automatically supersede a Customer-Specific patch (CSP). Causes: A file you are trying to update with a Release patch has been previously updated through the installation of a CSP. The Release patch does not have any knowlege as to whether it contains fixes contained in CSPs. Action: Determine if the CSP is included in the Release Patch Kit: o If yes, then you can safely remove the CSP (via dupatch) and reinstall the Release patch . o If no, contact your service provider to determine how to proceed. Output: Problem installing: - DIGITAL_UNIX_V4.0F / Commands, Shells, & Utility Patches: Patch 00444.00 - Fixes sort problem when running in Japanese locale ./usr/bin/sort: is installed by Customer Specific Patch (CSP): - DIGITAL_UNIX_V4.0F: Patch C 00187.00 and can not be replaced by this patch. To install this patch, you must first remove the CSP using dupatch. Before performing this action, you should contact your Service Representative to determine if this patch kit contains the CSP. If it does not, you may need to obtain a new CSP in order to install the patch kit and retain the CSP fix. B.1.9 The dupatch Tools Are Outdated Source: dupatch preinstallation check or installation. Problem: Patch tool set residing on system are not the most recent version. Causes: If the dupatch utility delivered with the patch kit determines that the tools residing on the system are not consistent with the patch kit, it will copy over updated versions of utilities used by dupatch. Action: This is an informational message and no further action is required. Output: Patch tools need to be installed or updated on your system. Please invoke the command as the super-user (root) first. * A new version of patch tools required for patch management is now being installed on your system. B.1.10 Some Patches Must Be Made Reversible Source: dupatch preinstallation check or installation. Causes: The user tried to install a patch as nonreversible; however, the patch in question must be installed as reversible. Action: This is an informational message and no further action is required. Output: * The following patch(es) are required to be reversible and will be made reversible automatically: - DIGITAL_UNIX_V4.0F / Commands, Shells, & Utility Patches: Patch C 00187.00 - v 4.0f patch E C187.00 B.2 Patch Removal Messages The following sections describe messages you might see when running the dupatch patch deletion function. B.2.1 Patch Removal Blocked by Missing Patch Backup Files Source: dupatch deletion. Problem: An attempt to remove a specific patch or all patches fails because the backup of the prepatch system files is not available to dupatch. Causes: The /var/adm/patch/backup area does not contain the prepatch system files. Action: Ensure that dupatch can access the/var/adm/patch/backup area and that the area is set up as it was when the patches were installed. For example, if you were using /var/adm/patch/backup as a mount point for another file system, make sure that file system is mounted. Once you have solved the /var/adm/patch/backup access or content problem, remove patches through the dupatch Delete Menu. Output: Checking patch dependency... (depending upon the number of patches you select, this may take a while) ------------------------------------------------------------------------- - DIGITAL_UNIX_V4.0F / Commands, Shells, & Utility Patches: Patch 0019.00 - quota Command Correction cannot be deleted. Can not find the backup copy for this patch in /var/adm/patch/backup. ------------------------------------------------------------------------- * Following patch(es) failed in dependency check: - DIGITAL_UNIX_V4.0F / Commands, Shells, & Utility Patches: Patch 0019.00 - quota Command Correction B.2.2 Patch Removal Blocked by Dependencies on Other Patches Source: dupatch deletion. Problem: A specific patch cannot be removed because of its dependency on other installed patches. Causes: Generally this occurs when you miss the selection of all dependent patches. Action: Through the dupatch Delete Menu, reselect the patches including the noted dependent patch and try to remove them. The program will notify you of any other dependent patches you might have missed. Output: Checking patch dependency... (depending upon the number of patches you select, this may take a while) ------------------------------------------------------------------------- - DIGITAL_UNIX_V4.0F / Library Patches: Patch 0262.00 - libm Corrections can not be deleted unless the following patches are also selected or deleted first: - DIGITAL_UNIX_V4.0F / Library Patches: Patch 0676.00 - libm Corrections ------------------------------------------------------------------------- * Following patch(es) failed in dependency check: - DIGITAL_UNIX_V4.0F / Library Patches: Patch 0262.00 - libm Corrections B.2.3 No Original Files Restored When Patch Is Removed Source: dupatch deletion. Problem: The removal of a specific patch results in no original system files being restored. Causes: This occurs when a patch delivers files to your system that were not shipped in the initial release of the product. For example, the sample output shows the removal of Tru64 UNIX 4.0F Patch 314.00; the patch delivers files that were not shipped with the initial release of Tru64 UNIX 4.0F. Action: This is an informational message and no further action is required. Output: === Deleting "DIGITAL UNIX V4.0F": Deleting "Patch: AdvFS Command Correction " (OSFPAT00031400425). ------------------------------------------------------------------------- Patch OSFPAT00031400425 delivered all new files to your system so there are no original files to be restored. No user action is necessary. ------------------------------------------------------------------------- B.3 TruCluster Specific dupatch Messages The following sections show the output of informational messages you might see when running dupatch on a TruCluster system: B.3.1 System Not Adequately Prepared Output: This system is part of a V5.0 cluster which has not been prepared to do a rolling patch installation. Refer to the Patch Installation Guide as to the proper procedure to start a rolling patch. B.3.2 Rolling Upgrade in Progress (Installation) Output: This system is part of a V5.0 cluster which is currently in the process of being installed via the rolling upgrade/ rolling patch procedure. New patches cannot be installed on the system until the rolling installation procedure has completed on all cluster members. B.3.3 Rolling Upgrade in Progress (Baselining) Output: This Cluster is in the process of a roll. Baselining is not permitted until the cluster is out of the roll. B.3.4 Version 5.0 Wave 4 Cluster is Unsupported Output: This system is a Version 5.0 - Wave 4 Cluster. Dupatch cannot patch this type of cluster. This is an unsupported operation and dupatch will now exit. B.3.5 Patch Removal Fails Because Needed File Is Unavailable Source: dupatch deletion. Problem: An attempt to remove patches fails because the file /var/adm/patch/versionswitch.txt is not available to dupatch. Cause: At least one of the patches selected for deletion in dupatch has a version switch associated with it (defined by having the attribute PATCH_REQUIRES_VERSION_SWITCH set to "Y" in its patch.ctrl file). The versionswitch.txt file is necessary to determine whether the version switch has been thrown. Action: The dupatch utility returns to the main menu. In order to proceed with the delete operation, you need to determine if the version switch was updated. If it has been thrown, you must run the undo script included with the patch to enable patch deletion (see "Removing Patches Installed During a Rolling Upgrade"). If the switch has not been thrown, you can enable the deletion of this patch by reconstructing the versionswitch.txt file. You can also reselect patches for deletion, omitting the patch containing the version switch. Contact your Customer Service Representative for assistance. Output: /var/adm/patch/versionswitch.txt file not found! Cannot delete patches selected since patch_ID requires a version switch. Please reselect patches or resolve missing /var/adm/patch/versionswitch.txt Please contact your Customer Service Representative for assistance. B.3.6 Patch Removal Fails Because of a Version Switch Source: dupatch deletion. Problem: The deletion of a patch containing a version switch has been blocked because the switch has been thrown. Action: The dupatch utility returns to the main menu. In order to proceed with the delete operation, you need to determine if the version switch was indeed updated. You can also reselect patches for deletion, omitting the patch containing the version switch. Output: Version switch thrown for patch patch_ID You cannot delete patch patch_ID Please refer to the Patch Kit Release Notes for instructions on allowing the patch deletion to proceed. B.3.7 dupatch Cannot Create Needed File Source: Patch installation Problem: The dupatch utility cannot create the file /var/adm/patch/versionswitch.txt because it cannot obtain the version switch state from /etc/sysconfigtab. Cause: At least one of the patches selected for installation contains a version switch. dupatch records the current version switch state in the file /var/adm/patch/versionswitch.txt. In order to facilitate the installation of this patch, this file must be created. While attempting to create this file, dupatch could not read the /etc/sysconfigtab file Action: Verify that the file /etc/sysconfigtab contains the entry new_vers_low. Output: Cannot obtain version switch info from system files! Cannot create versionswitch.txt file Please contact your Customer Service Representative for assistance. B.3.8 Insufficient Free Space (File System Full) Source: clu_upgrade setup stage of the rolling upgrade procedure. Problem: The rolling upgrade cannot proceed because required space allocations are not met. Causes: The root (/), /usr, /var, and/or /i18n file systems do not have the required amount of free space. Action: Run the clu_upgrade -undo setup command, free up enough space in the affected file systems to meet the requirements listed in "Preparation Stage", and rerun the clu_upgrade -undo setup command. Output: *** Error *** The tar commands used to create tagged files in the '/' file system have reported the following errors and warnings: NOTE: CFS: File system full: / tar: sbin/lsm.d/raid5/volsd : No space left on device tar: sbin/lsm.d/raid5/volume : No space left on device Appendix C Using dupatch from the Command Line Table of Contents C.1 Installing and Removing Release Patch Kits C.2 Deleting a CSP C.3 dupatch Reference Page The dupatch utility provides a command-line interface that allows dupatch to be called by other programs. You can use the command line to invoke all functions except for baselining. The functions have the same operation and definition as the menu-driven interface. For information about using the command-line interface, see the dupatch(8) reference page, which is installed on your system when you install the patch-kit tools and is documented in this appendix. You must specify all mandatory options on the command line or in a data file. If any mandatory option is missing, the command will fail with an appropriate error message; it will not prompt you for the missing option and information. C.1 Installing and Removing Release Patch Kits The following example shows the use of the dupatch command and several of its options to install the Version 5.1B-3 patch kit: /usr/sbin/dupatch -install -kit - license /patch/pk5/patch_kit -name Betty -note \ "installing pk5" -product all -patch all When installing a new kit, the first time you invoke the dupatch command with the -installor -install -precheck_only options you will install the latest patch tools. The following example shows the use of the dupatch command to remove the Version 5.1B-3 patch kit: /usr/sbin/dupatch -delete -name Joe -note "removing pk" \ -product all -patch T64V51BB26AS0005-20050211 The new patch tools cannot be loaded using the delete command on the command line. Doing that will cause the following error to be displayed: product_map does not exist or is empty, Cannot continue. To install the new tools, first issue the install command with the -precheck_only option. This will load the tools and not cause changes to your system. You can then use the delete command. C.2 Deleting a CSP You delete a CSP the same way you delete a release patch. The patch number you specify with the -patch option is the CSP's PatchID. The following steps describe how to find the PatchID: 1. Determine which kit the patch was delivered in. For example, T64KIT0020665-V51BB22-ES-20031113.tar. (For information about identifying the fields in this CSP name, see the Patch Kit Overview and Naming document at http://h30097.www3.hp.com/docs/patch/naming/TITLE.HTM.) 2. View the text file that ships with kit. For example: # more /var/adm/patch/doc/T64KIT0020665-V51BB22-ES-20031113.txt The text files for CSP kits are also available on the Web at the patch kit download site, http://www.itrc.hp.com/service/patch/mainPage.do . 3. Find the section of the text file that lists the PatchID. For example: 3 Summary of CSPatches contained in this kit Tru64 UNIX V5.1B PatchId Summary Of Fix ---------------------------------------- C386.00 Fix for SSRT3653, BIND v8 4. Type the dupatch command line, using the CSP patch ID. For example: # /usr/sbin/dupatch -delete -name "Sally G" -note \ "delete CSP" -product TRU64_UNIX_V5.0B -patch C386.00 [Note] Notes: o Although a CSP kit can contain multiple patches, not all of them may be installed on your system. o When deleting a CSP patch, also delete any patches that are required by the patch. C.3 dupatch Reference Page This section reproduces the dupatch(8) reference page, which is installed on your system with the patch installation tools. Name dupatch - Installs, deletes and maintains software patch updates to the Tru64 UNIX operating system, the TruCluster software products, and (in later kits) the Worldwide Language Support (WLS) subset. Synopsis /usr/sbin/dupatch /usr/sbin/dupatch -help [-data_file ] [-kit kit_location] [-patch_id ] [-rev] [-product_id] /usr/sbin/dupatch -install -kit kit_location -license -name user_name -note user_note -patch all | patch_id [patch_id ...] [-cfgfile config_file] [-data data_file] [-noauto ] [-nobackup ] [-nolog ] [-noroll ] [-precheck_only ] [-proceed ] [-root root_path] -product [ all | product_id ] [-single_user ] /usr/sbin/dupatch -delete -name user_name -note user_note -patch all | patch_id [patch_id ...] [-cfgfile config_file] [-data data_file] [-noauto] [-nolog] [-noroll ] [-proceed ] [-root root_path ] [-product all | product_id ] [-single_user ] /usr/sbin/dupatch -track -type [ patch_level | file | kit | patch ] [-data data_file] [-kit kit_location ] [-nolog] [-root root_path ] Command Keywords -install install-options Installs a software patch or patch kit. -delete delete-options Removes an installed patch or patches from the operating system. Patch deletion requires that the patch was installed as a reversible patch. -track track-options Constructs a history of patch installations and deletions. Information can be patch-kit specific or patch-file specific. -help help-options Requests quick help on dupatch. Supplying an argument will provide help specifically on that argument. Options Required -install Options -kit kit_location Specifies the location of the patch kit from which patches will be installed onto the system. kit_location is a full path to the directory containing the patch kit. -license Specifies that you have read and agreed to the license required to install the patch kit. This option is required for Version 5.1B-3 and higher. If you do not specifiy this option when required, you will see the following message: "Please read the license agreement (license.txt) in the top level directory of the patch kit. To accept the license agreement, include the -license option in the command line." You can also read the license in the Patch Summary and Release Notes document that is included with your kit. When you specify this option, the following message is displayed: "You have accepted the license agreement." -name user_name Specifies the name to be recorded in event.log. Enclose the user_name in quotation marks if it contains space characters. -note user_note Records user-supplied text in the event log. The user_note is a text string enclosed in quotation marks. -product all | product_id [product_id]... Required when more than one product is installed. Specifies the installed operating system and TruCluster software when installing patches from an old style patch kit. Product ID specifications are not case sensitive. Wildcard characters are not permitted. When installing an inclusive patch kit, the use of all is mandatory. See "Specifying a Product ID with -product". -patch all | patch_id [patch_id]... Directs dupatch to install all (all) patches or specific (patch_id) patches from the specified patch kit. When installing an inclusive patch kit, the use of all is mandatory. See "Specifying a Patch ID with -patch". Optional -install Options -cfgfile config_file Specifies a configuration file for rebuilding the kernel. See "Specifying a Configuration File". -data data_file Specifies a file that contains arguments (in the form argument = value) to the dupatch command. See "Using a Data File". -noauto Directs dupatch to not automatically rebuild the kernel if indicated by the patches installed. In addition, if running dupatch to install the patches in single-user mode, the system will not automatically reboot after the patch process is complete. -nobackup Directs dupatch to not retain backup information during a patch installation. This will remove the ability to back out an installed patch. -nolog Directs dupatch to not record actions in a session.log file. -noroll Directs dupatch to install patches on a cluster using the no-roll procedure rather than the default rolling-upgrade procedure. -precheck_only Directs dupatch to perform the preinstallation check but to not proceed with the patch installation. If -precheck_only is omitted, dupatch begins the installation process after the preinstallation check has been completed, as long as no patch failed the preinstallation check. The preinstallation check determines whether new patches that depend on the presence of other patches or software subsets can be installed. It does this by verifying that the required patches or software subsets are already installed onto the system. -proceed Directs dupatch to install any patches that passed the preinstallation check, even if one or more patches failed the preinstallation check. If -proceed is omitted, dupatch will not install any patches if at least one patch fails the preinstallation check. The preinstallation check determines whether new patches that depend on the presence of other patches or software subsets can be installed. It does this by verifying that the required patches or software subsets are already installed onto the system. -root root_path Specifies an alternate root location. The default root_path is / for all operations. -single_user If the system is presently in multi-user mode, brings the system down to single-user mode prior to installing patches. -rev Prints the current dupatch revision. Required -delete Options -name user_name Specifies the name to be recorded in event.log. Enclose the user_name in quotation marks if it contains space characters. -note user_note Records user-supplied text in the event log. The user_note is a text string enclosed in quotation marks. -product all|product_id [product_id]... Mandatory when more than one product is installed. Specifies the installed operating system and TruCluster software when removing patches from an old sytle patch kit. Product ID specifications are not case sensitive. Wildcards are not permitted. When removing an inclusive patch kit, the use of all is mandatory. See "Specifying a Product ID with -product". -patch all | patch_id [patch_id]... Directs dupatch to remove all (all) patches or specific (patch_id) patches from the specified patch kit. When removing an inclusive patch kit, the use of all is mandatory. See "Specifying a Patch ID with -patch". Optional -delete Options -data data_file Specifies a file that contains arguments (in the form argument = value) to the dupatch command. See "Using a Data File". -nolog Directs dupatch to not record actions in a session.log file. -noroll Directs dupatch to remove patches on a cluster using the no-roll procedure rather than the default rolling-upgrade procedure. -proceed Directs dupatch to delete any patches that passed the predeletion check, even if one or more patches failed the predeletion check. If -proceed is omitted, dupatch will not delete any patches if at least one patch failed the predeletion check. The predeletion check determines whether any installed patches have dependencies on any of the patches listed for removal. If such dependencies exist, dupatch blocks the removal of any required patch. -root root_path Specifies an alternate root location. The default root_path is / for all operations. Required -track Options -type patch_level, -type file, -type kit, -type patch Provides a single command (patch_level) that lists a full description of the patch kits, CSPs, and ERPs installed on your system, or lists all patched files (-file), installed patch kits (-kit), or installed patches (-patch). Optional -track Options -data data_file Specifies a file that contains arguments (in the form argument = value) to the dupatch command. See "Using a Data File". -kit kit_location Identifies the location of the patch kit for which the reports will cover. kit_location is a full path to the directory containing the patch kit. -nolog Directs dupatch to not record actions in a session.log file. -root root_path Specifies an alternate root location. The default root_path is / for all operations. Description The dupatch utility is an interactive program used to install and delete software patches to the Tru64 UNIX operating system and systems running TruCluster software products. With dupatch you can baseline your system to incorporate any system files that may have been manually installed. You can also use dupatch to obtain a list of installed patches or view the system history of patch installations and deletions. When invoked without arguments, dupatch is run interactively by providing menus that step you through the patching procedure while prompting you for necessary information. Alternatively, you can invoke dupatch from the command line, whereby you supply required arguments to the dupatch command. Although you can install patches in either single-user or multi-user mode, the use of single-user mode is strongly recommended. In multi-user mode, libraries and system files that are in use by active processes may be affected by the new patches. The patching of any active library or system files may result in unexpected consequences. Beginning with Version 5.1B Patch Kit 4 (base level 25), patch kits are packaged as "inclusive patch kits," which require all patches in the kit to be installed or removed together. Therefore, you cannot use the following options with an inclusive patch kit: o /usr/sbin/dupatch -install -patch patch_id o /usr/sbin/dupatch -delete -patch patch_id Attempting to use the patch_id option will cause the command to fail. Inclusive patch kits will also install patches for the Worldwide Language Support (WLS) subset if the WLS subset is installed on your system. On clustered systems running TruCluster software Version 5.0A or higher, the dupatch utility is run in conjunction with the rolling upgrade procedure. (See the Patch Kit Installation Instructions or the Cluster Installation manual for information about performing a rolling upgrade.) Using a Data File The data_file that you specify with the -data option is a fully qualified file location and a file that contains command-line options with the following format: option1 = value option2 = value :3 option3 = n For example: kit = /mnt name = Joe note = Installing April patch kit product = Tru64_UNIX_V5.1 patch = 27.01 63.00 74 83.01 product = TruCluster_V5.1 # multiple patches are separated by space characters patch = 21.01 27.01 40 precheck_only nobackup Blank lines and comments (preceded with #) are allowed. Line continuation (\) is required if a specification spans multiple lines. Only one data_file is permitted per command line and nested data_file specifications are not allowed. Specifying a Product ID with -product When installing or removing an inclusive patch kit, you must specify all with the -product option. For example: ./dupatch -install -product all -patch all -name Joe -note \ "installing pk4" -kit . For old style patch kits, the product_id you specify with -product is one of the following: TRU64_UNIX_V5.1B TRU64_UNIX_V5.1A TRU64_UNIX_V5.1 TRU64_UNIX_V5.0A TRU64_UNIX_V5.0 TRU64_UNIX_V4.0G TRU64__UNIX_V4.0F DIGITAL_UNIX_V4.0D TruCluster_V5.1B TruCluster_V5.1A TruCluster_V5.1 TruCluster_V5.0A TruCluster_V1.6 TruCluster_V1.5 o A product_id specification is not necessary when the system being patched has only one product installed; for example, Tru64 UNIX Version 4.0F with no TruCluster software product. o A product_id specification only applies to the patch_id specifications that follow it and ends when another product_id is specified. o Because the purpose of the product_id is to clarify the patch_id specification, the product_id must precede the patch_id. o Product strings are not case sensitive. Wildcard characters are not permitted. The following example shows the use of a product string with an old style patch kit: /pk3/patch_kit/dupatch -install -product DIGITAL_UNIX_V4.0F -patch 1.1 \ -product TruCluster_V1.6 -patch 35 -name Joe -note \ "installing patch 1.1" -kit /pk3/patch_kit Specifying a Patch ID with -patch You must specify all with the -patch option when installing or removing an inclusive patch kit. For example: ./dupatch -install -product all -patch all \ -name Joe -note "installing pk4" -kit . For old style patch kits, the patch_id you specify with the -patch option has the following format: xxxx[.yy] For example: 15 200.11 10.2 00111.02 o Both xxxx and yy are numeric values; leading zeros can be omitted. o Patch revision (yy), when left unspecified, maps to wildcarded "??" o Multiple patch_id specifications are separated by white space. o The keyword all cannot be combined with other patch IDs. o If product_id is used, patch_id must come after it. The following example shows the use of the -patch option with an old style patch kit: /pk3/patch_kit/dupatch -install -product DIGITAL_UNIX_V4.0F -patch 1.1 \ -product TruCluster_V1.6 -patch 35 -name Joe -note \ "installing patch 1.1" -kit /pk3/patch_kit Specifying a Root Path The root_path you specify with the -root option specifies an alternative root for the specified operation. (The -root option is similar to the -D option of setld.) The following list describes characteristics of the -root option. o The root path must be the root of a complete UFS file system or AdvFS domain. o The default root path is / for all operations. o If -root is the only argument on the command line, dupatch will proceed in interactive mode; this is an exception to the command-line rule previously mentioned. o When performing an alternate root installation, the -noauto flag is set implicitly. Specifying a Configuration File The -cfgfile option to the -install and -delete command options allows you to call in the system configuration file (/usr/sys/conf/config_file). For information about creating or modifying a config_file, see the doconfig(8) and sizer(8) reference pages. Restrictions The following restrictions apply to the dupatch utility. You must be logged in as root to run dupatch. The system must be running in single-user mode when removing patches. The -product option must precede the -patch option on the command line. Exit Status 0 (Zero) Success. >0 An error occurred. Errors See the Patch Kit Installation Instructions for a detailed list of dupatch error messages. Examples 1. The following interactive example shows how to invoke the menu-driven interface of dupatch: # dupatch Tru64 UNIX Patch Utility (Rev. 46-00) ========================== - This dupatch session is logged in /var/adm/patch/log/session.log Main Menu: --------- 1) Patch Installation 2) Patch Deletion 3) Patch Documentation 4) Patch Tracking 5) Patch Baseline Analysis/Adjustment h) Help on Command Line Interface q) Quit Enter your choice: 1 2. The following interactive example shows how to perform a preinstallation check on patch 00183.00 contained in the kit located at /mnt/patch_kit. This will verify that the specified patch can be installed onto the system without actually proceeding with the installation: # dupatch -install -kit /mnt/patch_kit -name Jessica -note \ "Pre-Installation check only on 183.00" -patch 183.00 -precheck_only 3. The following interactive example shows how to install all patches in kit located at /mnt/patch_kit: # dupatch -install -kit /mnt/patch_kit -name Jessica \ -note "install all patches" -patch all 4. The following interactive example shows how to identify all patches installed on system: # dupatch -track -type patch 5. The following interactive example shows how to list all system files updated by installed patches: # dupatch -track -type file 6. The following interactive example shows how to remove patch 00183.00 from the system. Note that the system will automatically be rebooted upon patch deletion because -noauto was not specified: # dupatch -delete -patch 183.00 -name Joe \ -note "delete patch 00183.00 from system" 7. The following interactive example shows how to obtain help on specifying patch_id usage: # dupatch -help patch_id Environment Variables The following environment variables affect the execution of dupatch: MAX_LOGS Specifies the maximum number of session logs to be retained on the system. The default number is 25. If, for example, MAX_LOGS is set to 25, the oldest session log would be named session.log.24 and the current would be named session.log, with no number affixed. _ROOT Overrides the location of the root directory. The default value is /, the system root directory. This value must be the top-level directory of a file system (or an AdvFS domain). PATCHDIR Specifies the path to the patch tools repository. The default value is $_ROOT/var/adm/patch. Files /var/adm/patch/log/session.log.n This file captures dupatch activities. A separate session log is written with each dupatch session and log files from the previous sessions are saved. The order is first in, first out, with session.log.$MAX_LOGS as the oldest file. /var/adm/patch/log/Dupatch_load_Date.log This file specifies the date when the patch tools were loaded or updated onto the system. /var/adm/patch/log/baseline.log.n This file records the screen output from the baselining session. A separate baseline log is written for each baselining session and log files from previous sessions are saved. The order is first in, first out, with session.log.$MAX_LOGS as the oldest file. /var/adm/patch/log/event.log.n This file captures information regarding patch installation and removal operations. A separate event log is written each time patches are installed or removed. Log files from previous sessions are saved. The order is first in, first out, with session.log.$MAX_LOGS as the oldest file. /var/adm/patch/backup The files in this directory are used to restore the system to its former state if patches are deleted. /var/adm/patch/doc/OSFPAT*patch_no.abs Provides brief summary of what a patch fixes. /var/adm/patch/doc/OSFPAT*patch_no.txt Provides detailed discussion of what a patch fixes. root-path/usr/.smdb./OSFPAT*.inv Lists the subset inventory files. root-path/usr/.smdb./OSFPAT*.ctrl Lists the subset control files. root-path/usr/.smdb./OSFPAT*.scp Lists the subset inventory programs. root-path/usr/.smdb./OSFPAT*.lk Lists the subset installed lock files. See Also Commands: setld(8), clu_upgrade(8) Documents: Patch Kit Installation Instructions Patch Summary and Release Notes for the patch kit to be installed Tru64 UNIX Installation Guide Tru64 UNIX Cluster Administration guide TruCluster Software Products Software Installation guide TruCluster Software Products Cluster Installation guide Appendix D Prior Patch Installation Changes Table of Contents D.1 Changes Made in Version 5.1B-2 D.2 Changes Made in Version 5.1B-3 Beginning with Version 5.1B-2, we changed to the way Tru64 UNIX patch kits are installed and and removed, and Version 5.1B-3 introduced additional changes. The following sections describe these changes. D.1 Changes Made in Version 5.1B-2 If you did not install Version 5.1B-2 but have installed earlier kits, you will see the following differences in the kitting process: o All or none installation When you install an inclusive patch kit, you must install all patches; you can no longer select specific patches to install. By making the installation of all patches mandatory, you can patch with greater confidence that the process will be problem free. Before a patch kit is released, it is tested on many types of systems and system configurations. This testing continues until we are assured that the patches perform the tasks they were designed for and do not introduce new problems. It is not possible to achieve this type of testing on every possible combination of individually selected patches. o Substantially reduced installation time The installation process for inclusive patch kits can reduce the time it takes to install the patches by as much as half from what you are used to. For large, clustered systems, the difference can be several hours faster. o Fewer patches displayed Because of the way these new patch kits are designed, you will see many fewer patches listed by dupatch during the installation process. For example, a partial listing you see will be similar to the following: - Tru64_UNIX_V5.1B / Security Related Patches: * Patch 27001.00 - SP04 OSFACCT540 * Patch 27002.00 - SP04 OSFADVFS540 (SSRT2275) * Patch 27003.00 - SP04 OSFADVFSBIN540 In the old-style patch kits, these three patches might have consisted of perhaps 20 individual patches being displayed. The difference is not in the content of the kits, but rather in the way the patches are packaged and installed. In this example, the SPO4 identifies the patch as belonging to Version 5.1B-2 (Patch Kit 4), the OSF...540 identifies the subset the patch is included in, and the SSRT2275 indicates a type of security patch. o All or none patch removal As with the installation process, if you want to remove a patch, you must remove all of them. That is, you can no longer select individual patches for removal. o Patches for Worldwide Language Support (WLS) subset The inclusive patch kits deliver patches that may be required for the WLS subset. As with the TruCluster Server patches, the WLS patches will only be installed if you have the WLS subset installed. D.2 Changes Made in Version 5.1B-3 If you did not install Version 5.1B-2 but have installed earlier kits, you will see the following differences in the kitting process: o Before you can install this kit you must accept the conditions included in the license that the dupatch utility displays. o You can delete the patch kit by kit name rather than by specifying individual patches. With the introduction of this feature, you can easily delete patches interactively using the dupatch utility or from the dupatch command line. This feature also works on on pre-Version 5.1B-4 kits. o You can delete patches in multi-user mode. o You can force the installation of the patch kit even if file conflicts exist. This feature is an extension of the dupatch baselining feature. o A new command-line option, Patch Level, provides a single command that provides a full description of the patch kits, CSPs, and ERPs installed on your system. Glossary baselining A dupatch feature that 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. Customer-Specific Patch (CSP) Kit A patch kit that is developed and made available to resolve a problem for a specific customer. A Customer-Specific patch is developed with prior knowledge of that customer's unique hardware and software configuration and environment. Customer-Specific patches may not be useful for another customer's system. An Early Release patch is a type of CSP. See also Early Release Patch (ERP) Kit, Release Patch Kit. dupatch A utility included in a patch kit that installs, removes, and manages patches for Tru64 UNIX and TruCluster software products. This utility is installed and left on the system through the successful installation of a patch kit. Early Release Patch (ERP) Kit A patch kit that contains a patch or patches that will be included in a Release Patch Kit that is still under development. ERPs, which are a type of Customer-Specific patch, are provided by HP to help customers who have an immediate need for some specific functionality that will be included in an upcoming Release Patch Kit. See also Customer-Specific Patch (CSP) Kit, Release Patch Kit. force install A term somtimes used to describe the abilility of the baselining procedure to enable the installation of patches that are blocked by the intallation procedure. inclusive patch kit See new style patch kit. new style patch kit Also called an inclusive patch kit, a new style patch kit is a Release Patch Kit that provides an improved way of delivering patches. Among the ways that a new style patch kit differs from its predecessors is that it requires an all or none installation and removal of the patches in that kit. The first Tru64 UNIX new style patch kit was Version 5.1B Patch Kit 4 (Base Level 25). See also Release Patch Kit. no-roll patching A process that patches your cluster in one operation and requires only one reboot of the whole cluster to complete the operation. This method was developed for mission-critical environments to provide a way to apply patches quickly, with a minimum amount of down time. The no-roll patch process is a modification of dupatch; that is, all patches are installed or removed entirely using the dupatch utility, as opposed to the clu_upgrade and dupatch utilities used in the rolling upgrade procedure. The no-roll process conducts significantly fewer operations than the rolling upgrade procedure. See also rolling upgrade. official patch See Release Patch Kit. old style patch kit See new style patch kit. patch A file or a collection of files that contain fixes to problems. When possible, patches are merged together into one patch if they have intersecting files or codependencies. A patch may correct one or more problems. Each patch is packaged in its own setld subset. The subsets are managed by a utility named dupatch. patch applicability A file-by-file check of system files to determine whether a patch might cause a system to be degraded or crash. The installation of a patch is blocked if any system files to be replaced by that patch are not valid predecessors of the patch files. Release Patch Kit A patch kit that HP provides to modify a specific version of the Tru64 UNIX operating system and TruCluster software. Sometimes referred to as official patch kits, Release Patches Kits are intended for worldwide distribution and can be safely used on any customer's system within the guidelines documented in the kit. The patches in a Release Patch Kit are referred to as Release patches. See also Customer-Specific Patch (CSP) Kit, Early Release Patch (ERP) Kit, new style patch kit. rolling upgrade A software upgrade of a cluster that is performed while the cluster is in operation. One member at a time is rolled and returned to operation while the cluster transparently maintains a mixed-version environment for the base operating system, cluster, and Worldwide Language Support (WLS) software. Clients accessing services are not aware that a rolling upgrade is in progress. On Version 5.0A and higher systems, you use a rolling upgrade to patch a cluster or to update the Tru64 UNIX operating system or TruCluster software on a cluster. The procedure is the same for both types of upgrades - the only difference is the command you run during the install stage of the rolling upgrade procedure. See also no-roll patching. setld An interactive program for installing and managing software subsets. Software products are organized into subsets that can be loaded, deleted, inventoried, and configured. The load operation reads software from disk, tape, CD-ROM, or an Internet installation server. The patch installation tool, dupatch, is based on the setld program. tar file A file created with the tar command that saves and restores multiple files in a single file. Tru64 UNIXpatch kits are provided as tar files (except for kits included on a Patch CD-ROM). version switch During a rolling upgrade, 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. The purpose of a version switch in a cluster is to prevent the introduction of potentially incompatible new features until all members have been updated. See also rolling upgrade. Index Symbols .Old.. files, Tagged Files /usr file system rolling upgrade space requirement, Preparation Stage /var file system rolling upgrade space requirement, Preparation Stage /var/adm/patch/backup, Patch Reversibility, Limitation for /var/adm/patch/backup Directory Handling, Performing a Patch Preinstallation Check, Common Installation Steps, Patch Installation Blocked by Disk Space, Patch Removal Blocked by Missing Patch Backup Files A applicability of patches, Patch Applicability applications (see layered products) B backup default location for installed patches, Performing a Patch Preinstallation Check during a rolling upgrade, Preparation Stage performing before baselining, Creating a Baseline relation to patch reversibility, Patch Reversibility backup directory using as mount point for separate disk partition, Performing a Patch Preinstallation Check baseline.log, Viewing Log files baselining handling manually installed system files with, Creating a Baseline reporting information on layered products, Phase 2 - Patch Layered Product Conflicts, Steps for Running the Baseline Procedure warnings when using, Creating a Baseline bcheckrc command single-user mode on single system, Installing Patches from Single-User Mode single-user mode with cluster, Rolling Upgrade Procedure use to roll cluster member, Rolling Upgrade Procedure blocking layered products, Blocking Layered Products C CAA testing lead member during a rolling upgrade, Rolling Upgrade Procedure caution blocking layered products and rolling upgrade, Tagged Files creating tagged files, Setup Stage not deleting files in /var/adm/update, Setup Stage cfsmgr command, Rolling Upgrade Procedure clean stage, Clean Stage clu_upgrade command check setup command, Rolling Upgrade Procedure, Preparation Stage clean command, Rolling Upgrade Procedure, Clean Stage commands for, Displaying the Status of a Rolling Upgrade completed command, Displaying the Status of a Rolling Upgrade log file, Setup Stage log file for, Clean Stage postinstall command, Rolling Upgrade Procedure, Postinstall Stage preinstall command, Rolling Upgrade Procedure, Preinstall Stage roll command, Rolling Upgrade Procedure, Roll Stage setup command, Rolling Upgrade Procedure, Setup Stage switch command, Rolling Upgrade Procedure, Switch Stage tagged add command, Tagged Files tagged check command, Tagged Files tagged disable command, Tagged Files tagged enable command, Tagged Files undo command, Undoing a Stage version command, Rolling Upgrade Commands cluamgr command, Rolling Upgrade Procedure cluster alias RIS registration, Rolling Upgrade and RIS testing lead member during a rolling upgrade, Rolling Upgrade Procedure cluster creation patching prior to, Patching a System Prior to Creating a Cluster clusterwide file systems free space required for a rolling upgrade, Preparation Stage command line installing and removing patches from, Using dupatch from the Command Line restriction on loading new dupatch tools from, Using dupatch from the Command Line common installation steps, Common Installation Steps CSP deleting using command line, Deleting a CSP dependence on patch kit, Overview file found when baselining, Creating a Baseline information about when patch tracking, Using the Patch Tracking Menu installing and removing, Patch Installation and Removal Instructions installing with dupatch, dupatch Overview patch applicability of, Patch Applicability patch installation blocked by, Patch Installation Blocked by an Existing CSP problem during preinstallation check, Common Installation Steps removing, Removing Patches reversibility of, Patch Reversibility superseded in Release kits, Release Patches Do Not Automatically Supersede CSPs Ctrl/c restriction on using during patch installation, Do Not Enter Ctrl/c During Installation Phase Customer-Specific patch kit (see CSP) customized files message in session log, Removing Patches Containing Customized Files D Dataless Management Services (see DMS) DEC_VERSION_TAG property, Tagged Files default cluster alias testing lead member during a rolling upgrade, Rolling Upgrade Procedure deleting patches (see removing patches) disk space requirement for a rolling upgrade, Preparation Stage where to find required amount for patch installation, Before You Begin the Installation DMS restriction using, RIS and DMS Unsupported for Patch Installation documentation available on the Web, Patch Process Resources in files used by dupatch, Using the Patch Documentation Menu dupatch calling from other programs, Using dupatch from the Command Line command-line interface, Using dupatch from the Command Line described, dupatch Overview in rolling upgrade install stage, Install Stage loading new patch tools with, Invoking dupatch and Installing New Patch Tools log files created by, Viewing Log files menu determined by login location, Performing a Patch Preinstallation Check reference page for, dupatch Reference Page restriction on loading new dupatch tools from command line, Installing and Removing Release Patch Kits tracking information with, Using the Patch Tracking Menu viewing patch documentation with, Using the Patch Documentation Menu dupatch tools installing from command line, Installing and Removing Release Patch Kits restriction on loading from command line using delete, Installing and Removing Release Patch Kits Dupatch_load_date.log, Viewing Log files dupclone benefits of using, Benefits and Detriments of Cloning overview, Using the dupclone Script performing the installation using, Performing the Cloned Installation reference page for, dupclone(8) Reference Page E Early Release Patch Kit (see ERP) ERP, Patch Installation and Removal Instructions (see also CSP) information about when patch tracking, Using the Patch Tracking Menu installing and removing, Patch Installation and Removal Instructions installing with dupatch, dupatch Overview removing, Removing Patches error messages, Common Error, Warning, and Informational Messages event.log, Viewing Log files F force install, Glossary H halting an installation, Do Not Enter Ctrl/c During Installation Phase I i18n (see WLS) init command single-user mode on single system, Installing Patches from Single-User Mode single-user mode with cluster, Rolling Upgrade Procedure use to roll cluster member, Rolling Upgrade Procedure install stage, Install Stage installing successive patch kits, Expanding the Patch Kit Tar File installupdate command, Rolling Upgrade Procedure, Install Stage K kernel rebuilding, Rebuilding the Kernel kloadsrv command single-user mode on single system, Installing Patches from Single-User Mode L layered products blocking, Blocking Layered Products error caused by product collision, Installation Blocked by Layered Product Collision general guidelines for rolling upgrade, General Guidelines potential problems when upgrading system, Impact on System Upgrades to Later Versions of Tru64 UNIX report on when baselining, Phase 2 - Patch Layered Product Conflicts, Steps for Running the Baseline Procedure lead member, Preparation Stage, Tagged Files lmf reset command single-user mode on single system, Installing Patches from Single-User Mode single-user mode with cluster, Rolling Upgrade Procedure use to roll cluster member, Rolling Upgrade Procedure log files, Viewing Log files baseline.log, Viewing Log files clu_upgrade command, Setup Stage Dupatch_load_date.log, Viewing Log files event.log, Viewing Log files untar.log, Expanding the Patch Kit Tar File M member boot disk rolling upgrade space requirement, Preparation Stage menu (see dupatch) messages (see error messages) multi-user mode restriction on patching from, When Single-User Mode Is Recommended multiple (parallel) rolls, Rolling Upgrade Procedure N Network File System (see NFS) New Hardware Delivery kits (see NHD) NFS support for patch installation, RIS and DMS Unsupported for Patch Installation NHD installing kits during a rolling upgrade, Rolling Upgrade Supported Tasks nhd_install command, Rolling Upgrade Procedure, Install Stage no-roll patching, Overview (see also rolling upgrade) introduction to, No-Roll Patching overview, Overview steps for performing, Steps for Running a No-Roll Procedure P parallel rolls, Rolling Upgrade Procedure patch kit directory removing after patch installation, Remove Temporary Directory patch management utility (see dupatch) patch tools (see dupatch) patches cluster, Rolling Upgrade Supported Tasks patching prior to cluster creation, Patching a System Prior to Creating a Cluster postinstall stage, Postinstall Stage preinstall stage, Preinstall Stage preinstallation checklist, Before You Begin the Installation creating a baseline, Creating a Baseline preinstallation check example of patch that fails, Performing a Patch Preinstallation Check performing, Performing a Patch Preinstallation Check preparation stage, Preparation Stage procedure for using dupatch, Running dupatch to Remove Patches R rebooting system in multi-user mode, In Multi-User Mode in single-user mode, In Single-User Mode reference page for dupatch, dupatch Reference Page Remote Installation Services (see RIS) removing patches during a rolling upgrade, Removing Patches Installed During a Rolling Upgrade example of from command line, Installing and Removing Release Patch Kits overview, Removing Patches, Overview restriction on using ALL of the above menu item, Overview that contain customized files, Removing Patches Containing Customized Files using dupatch deletion option, Running dupatch to Remove Patches removing temporary patch kit directory, Remove Temporary Directory resources (see support) reversibility of patches (see reverting systems to prior state) reverting systems to prior state, Patch Reversibility RIS registering the default cluster alias, Rolling Upgrade and RIS restriction using, RIS and DMS Unsupported for Patch Installation roll stage, Roll Stage parallel rolls, Rolling Upgrade Procedure rolling patch (see rolling upgrade) rolling upgrade, Rolling Upgrade (see also no-roll patching) backups during, Preparation Stage checking the status of, Displaying the Status of a Rolling Upgrade disk space requirements, Preparation Stage lead member, Preparation Stage, Tagged Files NHD, Rolling Upgrade Supported Tasks parallel rolls, Rolling Upgrade Procedure patch, Rolling Upgrade Supported Tasks procedure, Rolling Upgrade Procedure stages of (see rolling upgrade stages) tagged files, Tagged Files testing the lead member with CAA, Rolling Upgrade Procedure testing the lead member with cluster alias, Rolling Upgrade Procedure undoing a stage, Undoing a Stage unsupported tasks, Unsupported Tasks updating the Tru64 UNIX operating system disk, Rolling Upgrade Supported Tasks version switch, Version Switch rolling upgrade stages clean, Clean Stage install, Install Stage postinstall, Postinstall Stage preinstall, Preinstall Stage preparation, Preparation Stage roll, Roll Stage setup, Setup Stage switch, Switch Stage rolls_ver_lookup attribute, Setup Stage, Tagged Files root file system rolling upgrade space requirement, Preparation Stage S session log, Viewing Log files message in when removing a patch, Removing Patches Containing Customized Files setld command restriction when adding or removing patches, Direct setld Installation and Removal of Patch Subsets Is Not Allowed setup stage, Setup Stage simultaneous (parallel) rolls, Rolling Upgrade Procedure single-user mode recommendation on patching from, When Single-User Mode Is Recommended stages checking the status of, Displaying the Status of a Rolling Upgrade parallel rolls, Rolling Upgrade Procedure time required to perform, Rolling Upgrade Procedure undoing, Undoing a Stage storage space (see disk space) support, Patch Process Resources switch stage, Switch Stage system upgrades potential problems with, Impact on System Upgrades to Later Versions of Tru64 UNIX T tagged files, Tagged Files creating during setup stage, Setup Stage creating for OSF, TCR, and IOS product codes, Tagged Files removing during clean stage, Clean Stage rules for creating, Tagged Files verifying during preinstall stage, Preinstall Stage verifying existence of, Displaying the Status of a Rolling Upgrade tar file expanding, Expanding the Patch Kit Tar File tools (see dupatch tools) tracking information, Using the Patch Tracking Menu U unsupported tasks during a rolling upgrade, Unsupported Tasks untar.log, Expanding the Patch Kit Tar File updadmin command, Clean Stage V version switch, Version Switch enabling new functions with, Enabling the Version Switch After Installing a New Style Patch Kit in no-roll patch procedure, Throwing the Version Switch overview, Version Switches versw command, Version Switch vMAC algorithm for creating a hardware address, Rolling Upgrade and RIS W Web sites (see support) WLS installing on patched system, Adding the Worldwide Language Support rolling upgrade space requirement, Preparation Stage