HP-UX 10.0 Patch Program White Paper HP 9000 Series 700/800 Computers Printed in U.S.A. Sept 1995 Third Edition E0995 LEGAL NOTICES The information in this document is subject to change without notice. Hewlett-Packard makes no warranty of any kind with regard to this manual, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. Hewlett-Packard shall not be held liable for errors contained herein or direct, indirect, special, incidental or consequential damages in connection with the furnishing, performance, or use of this material. Warranty. A copy of the specific warranty terms applicable to your Hewlett-Packard product and replacement parts can be obtained from your local Sales and Service Office. Restricted Rights Legend. Use, duplication, or disclosure by the U.S. Government Department is subject to restrictions as set forth in subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 for DOD agencies, and subparagraphs (c) (1) and (c) (2) of the Commercial Computer Software Restricted Rights clause at FAR 52.227-19 for other agencies. HEWLETT-PACKARD COMPANY 3000 Hanover Street Palo Alto, California 94304 U.S.A. Copyright Notices. (C)copyright 1995 Hewlett-Packard Company, all rights reserved. Reproduction, adaptation, or translation of this document without prior written permission is prohibited, except as allowed under the copyright laws. Trademark Notices. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company Limited. First Edition: April 1995 (HP-UX Release 10.0) Second Edition: April 1995 (HP-UX Release 10.0) Third Edition: September 1995 (HP-UX Release 10.0) ========================================================================= Section Index: 1.1 10.0 PATCHING 1.2 NFS DISKLESS (NFSD) 1.3 PATCH STRUCTURE 1.4 INSTALLING PATCHES 1.5 GETTING PATCHES 1.6 PATCHING BEHIND THE SCENES 1.7 CHECKING PATCHES AFTER INSTALLATION 1.8 PATCH REMOVAL 1.9 DEPOT MANAGEMENT ========================================================================= HP-UX 10.0 Patch Program White Paper ==================================== The intended audience is customers who install HP-UX 10.X patches. 1.1 10.0 PATCHING: === ============= The HP-UX 10.X patching scheme, though similar to the pre-10.0 scheme, requires some additional attention. On pre-10.0 HP-UX, /etc/update is used as the patch installation tool. On 10.X HP-UX, there is no /etc/update program. All software, including patches, will be installed on 10.X systems using SD (Software Distributor). SD is an acronym used to denote a family of programs which manages software on 10.X systems. A group of tools residing in /usr/sbin compose the SD utilities. The utilities most often used to manage software are swinstall, swcluster, swlist, swremove, and swverify. There are other sw* tools in the directory, but these are the most important in regards to the patch program. It is highly recommended that the user become familiar with the operation of the product installation tool, SD, before attempting patch installation. The documentation for becoming familiar with SD is the: "Managing HP-UX Software with SD-UX", part number: B2355-90054, orderable directly from HP. 1.2 NFS DISKLESS (NFSD): === =================== As of HP-UX 10.01, HP supports diskless clusters using the NFS protocol. The addition of NFSD clusters impacts patch management operations. Patch management differences between NFSD clusters and standalone systems are the principal additions to this 3rd edition. All SD commands execute on an NFSD cluster must be executed on the server and not on the individual NFSD clients. This includes tasks such as installing, removing, listing, and verifying patches. Installing patches on an NFSD cluster results in two different path names for the log files and software being patched. The location of the files and directories is different between the NFSD server and NFSD clients. The log files and patch directories for the NFSD clients are usually located in the /export/shared_roots/OS_700 directory. For example, to examine the patch log file: /var/adm/sw/patch/PATCH.log for NFSD clients, the following file should be examined from the NFSD server: /export/shared_roots/OS_700/var/adm/sw/patch/PATCH.log If this is a homogeneous NFSD cluster, then /export/shared_roots/OS_700 is a symbolic link to / and the PATCH.log files are the same. On a heterogeneous NFSD cluster, the files are different. A new command "swcluster" does the job of both installing and deinstalling (-r option) patches on an NFSD cluster, except when a patch is installed on an NFSD server for a heterogeneous cluster. The "NFS Diskless Concepts and Administration White Paper" covers NFS diskless in detail and is available on-line in the /usr/share/doc/NFSD_Concepts_Admin.ps file. 1.3 PATCH STRUCTURE: === =============== A standard patch package for a pre-10.X system is a shar file which contains a .text file and a tar image from which /etc/update can install directly. On 10.X, the patch package is basically the same, but the designation for the tar image is now the depot. A 10.X patch package will be a shar file containing a .text file and an SD software depot from which swinstall can directly install a patch. An example of an SD patch depot is PHSS_5714.depot. Depots are SD's way of storing software for future installation. They can be a single file in tar(1M) format or a hierarchical directory structure rooted in a directory with the name of the depot. SD understands both formats without special designation. Depots obtained from HP in a shar patch package can be used directly for patch installation with no modifications. This paper will discuss combining patch depots into custom depots to better serve your needs. Patches for 10.X are stored in exactly the same manner as pre-10.X patches, and thus can be retrieved in the same manner. The structure of the patch will vary depending on how the patch is obtained. Patches obtained via electronic distribution always contain the entire shar file. This is true for ftp, mosaic, e-mail, kermit, and uucp. Patches distributed via tape from the worldwide HP Response Centers will be in one of two formats: 1. SD format - The patch tape will be an actual SD depot and you can swinstall directly from the tape. The tape will be labeled SD format. 2. tar format - The patch tape will contain the .text and .depot files. The files will need to be extracted from the tape via tar(1) and then installed individually via the standard installation instructions. The tape will be labeled archive format. Along with a patch depot, each patch will have supplied with it a .text file. The following describes the contents of the .text file which will appear in the current directory along with the depot after the patch package is unshared: ---------------------------- .text file format -------------------------- Patch Name: The name of the patch. Format is: PHxx_yyyy where: PH = Patch HP-UX. xx = area patched: CO - general HP-UX commands. KL - kernel patches. NE - network specific patches. SS - all other subsystems: X11, Starbase, etc. yyyy = a unique number Example: PHSS_4014 - an HP-UX subsystem patch name. Patch Description: A one-line description that describes this cumulative patch. Creation Date: The date that the patch was created. Post Date: The date that the patch was posted for general distribution. Hardware Platforms - OS Releases: The hardware platforms and HP-UX OS releases on which this patch can be installed. Products: This field lists the product name and all product revisions to which this patch applies if it is a patch for an optional product, i.e. a non-core operating system product. If the patch is for the core operating system, the value in this field is "N/A". Filesets: This is a list of all the filesets which contain one or more files included in this patch. Automatic Reboot?: Yes/No (whether or not this patch requires a reboot after installation). Status: This is the support status of the patch. GR | SP where: GR = General Release: patch should be installed on all systems meeting the OS, product, and dependency requirements. SP = Special Release: site-specific patches for installation at one specific customer or set of customers, and other non-GR patches. Critical: Yes/No followed by text. This flags the Critical status of this patch and all superseded patches. A patch is considered "critical" if it fixes a critical problem or it supersedes a patch fixing a critical problem. A problem is critical if it: o Causes the system (OS/kernel) to fail/crash/panic. o Causes a major application to fail such that the system's operation is severely impacted. o Causes data loss or corruption. Path Name: The path name is the patch's storage location on the HP SupportLine system. The current choices for 10.X are: /hp-ux_patches/s700/10.X/PHxx_yyyy /hp-ux_patches/s700_800/10.X/PHxx_yyyy /hp-ux_patches/s800/10.X/PHxx_yyyy Symptoms: The external symptoms of the problem, specifically, what a user would experience. Defect Description: A detailed description of the defect that specifically addresses the explicit conditions which caused the problem (if known), and how to reproduce the problem (if known). Also include methods to verify if the patch needs to be installed. SR: All SR numbers addressed by this patch and all its predecessors. A Service Request (SR) is a formal request from a customer to have a defect resolved or a feature added to HP software. Patch Files: The full installed path name of all files in this patch. If the patch replaces an object module in a library, the full path of the library is listed with the object module following in parentheses. For example, if a patch replaces the object module "vers.o" in the library "/usr/conf/lib/libhp-ux.a" the path listed would be "/usr/conf/lib/libhp-ux.a(vers.o)". what(1) Output: The output from what(1) for each file or library object file listed in the Patch Files field. The 'what' string is a way to identify the software version, and thereby, verify that the patch is installed. Example : $Revision: 1.13 $ Patch Conflicts: All known patch conflicts, both on a file basis as well as on a behavioral basis. Patch Dependencies: All patches that must be installed to insure proper operation of this patch. Hardware Dependencies: Specific system models to which this patch is limited. Other Dependencies: Any non-patch and non-hardware dependencies that may exist. Supersedes: A list of all patches superseded by this patch. Equivalent Patches: All equivalent patches for other hardware platforms and OS releases not including this patch. Patch Package Size: The SD depot size in Kbytes. Installation Instructions: The standard installation instructions common to all patches. These instructions have been included in this white paper. Special Installation Instructions: Any special instructions not included in those mentioned above. ----------------- end of .text file format ---------------------------- 1.4 INSTALLING PATCHES: === ================== The following procedure is referred to throughout this paper as the Installation Instructions. This is a specific example of the installation instructions for a patch named PHSS_5105. Please substitute the name of the patch you're trying to install wherever you see an occurrence of the word "PHSS_5105". NOTE: SD is not supported in single-user mode, therefore patches should be installed in multi-user mode. Why? The swagentd daemon process must be running on the system. 1. Back up your system before installing a patch. 2. Login as root. 3. Copy the patch to the /tmp directory. 4. Move to the /tmp directory and unshar the patch: cd /tmp sh PHSS_5105 NOTE: There are three system types: standalone, homogeneous, heterogeneous. A standalone system is non-clustered 700 or 800 system. Homogeneous diskless clusters have a 700 server and 700 clients. Heterogeneous diskless clusters have an 800 server and 700 clients. On diskless clusters, the swcluster command must be executed only on the server. Step 5) varies depending on the system type. 5a. For a standalone system, run swinstall to install the patch: swinstall -x autoreboot=true -x match_target=true \ -s /tmp/PHSS_5105.depot 5b. For a homogeneous NFS diskless (NFSD) cluster, run swcluster on the server to install the patch on the server and the clients: swcluster -i -b This invokes swcluster in interactive mode and forces a shutdown of all clients. This shutdown requirement of all patches and is not limited to just kernel patches. Why? When installing a patch on the server, the corresponding executable file on a server's disk associated with a process running on a client can be over written, which can result in the client process dying with the error: Pid killed due to text modification or page I/O error Bus error(coredump) Shutting down clients prevents this error. In a homogeneous NFS Diskless cluster, the patch information for the NFSD server will be the same as the NFSD clients. Patch information for the NFSD server and clients will be maintained in the /var/adm/sw directory. 5b. (continued) The swcluster command will invoke an swinstall session in which you must specify: alternative root patch - default is /export/shared_roots/OS_700 source depot patch - /tmp/PHSS_5105.depot To complete the installation, select the patch by choosing "Actions -> Match What Target Has" and then "Actions -> Install" from the Menubar. 5c. For a heterogeneous NFSD cluster: run swinstall on the server as in step 5a) to install the patch on the cluster server. run swcluster on the server as in step 5b to install the patch on the cluster clients. In a heterogeneous NFS Diskless cluster, the patch information for the NFSD server will differ from the NFSD clients. Patch information for the NFSD server will be maintained in the /var/adm/sw directory. Patch information for the NFSD clients will be maintained in the /export/shared_root/OS_700/var/adm/sw directory. NOTE: The above commands can fail and exit with little explanation as to the cause. The log files /var/adm/sw/swinstall.log and /var/adm/sw/swcluster.log can always be consulted for a detailed description of any errors. The most common cause for the swinstall process to abruptly exit is the prevention of installation of an improper patch to the system. The required option "match_target=true" signals SD to refuse installation of all patches which don't match the system's software layout (i.e. If patch PHSS_5105 patches the product X11 and X11 is not installed on the target system, then swinstall will refuse to allow this patch to be installed, thus aborting the installation process). NOTE: A pair of messages will occur in the output from swinstall: * "hostname:/tmp/PHSS_5105.depot": This source is a tape device. * "hostname:/tmp/PHSS_5105.depot": Cannot open the logfile on this target or source. Possibly the media is read-only or there is a permission problem. Check the daemon logfile and "/var/tmp/swagent.log" on this host for more information. These messages can be misleading. Do not let them worry you. There is nothing wrong with the patch depot if these messages appear. By default swinstall will archive the pre-patch files in /var/adm/sw/patch/PHSS_5105. This is done so that the patch can be removed from the system at any time in the future and return the system to its pre-patched state. If you do not wish to retain a copy of the pre-patch files, you can create an empty file named /var/adm/sw/patch/PATCH_NOSAVE prior to installing the patch. Warning: If this file (/var/adm/sw/patch/PATCH_NOSAVE) exists when a patch is installed, the patch cannot be uninstalled. Please be careful when using this feature. It is recommended that you move the PHSS_5105.text file to /var/adm/sw/patch for future reference. To put this patch on a magnetic tape to allow installation from the tape drive, use the command: dd if=/tmp/PHSS_5105.depot of=/dev/rmt/0m bs=2k ------------------------------------------------------------ All SD commands are extremely verbose in their logging of any actions performed. All output from SD commands is logged in the appropriate file in the directory /var/adm/sw. For example /var/adm/sw/swinstall.log for the swinstall command. These logfiles may be examined at any time for specific NOTES/WARNINGS/ERRORS logged during the operation of any SD command. These files have a tendency to become extremely large in very short periods of heavy SD use. Never remove any SD log file to reduce its size. Doing so will cause all future output to that log file to be lost until the SD daemon is restarted. A tool named cleanup (see PATCH REMOVAL) is provided which, among other things, will trim all SD logfiles in an approved manner. If you don't have access to this tool, or would like to cleanup the logfiles manually, this can be done in one of two methods: 1) edit the logfile and delete any or all of the lines in it, then exit the editor in a way so that the file is saved. 2) As root, type: echo > LOGFILE_NAME Where "LOGFILE_NAME" is the name of the SD log file you wish to clear. This will destroy all contents of the logfile. Both methods will preserve the original logfile in the file system while reducing/removing its contents. ------------------------------------------------------------ The swinstall command allows the match_target option to be specified on the command line, thereby allowing a non-interactive SD install session. swcluster can only be used to install patches interactively, because the match_target option cannot be specified on the command line. If an interactive swinstall session is preferred over a non-interactive swinstall session, then repeat steps 1-4 as in the patch installation instructions above and then running "swinstall -i". This invokes the interactive Terminal User Interface (TUI) version. If the "-display" option is used or the DISPLAY environment variable is set, then an interactive Graphical User Interface (GUI) version appears. This will bring up SD's graphical interface to the swinstall command. When in the graphical interface: - Specify the patch depot: The first menu displayed will be the "Specify Source" menu. Move the typing cursor into the "Source Depot Path" input area and enter the complete path to the patch depot. For example: /tmp/PHSS_5101.depot then choose the "OK" button. If an informational dialog box appears telling the user that the software view is specified in bundles, but no bundles were located, it can be dismissed and ignored. Now the "Software Selection" window will have the patch displayed. - Match the patch with the software on the system: A new feature in 10.X patching allows the system (SD) to determine which patches are appropriate for installation on the target system. This feature is the "Match What Target Has" option in SD. This option should now be picked from the "Actions" pull-down menu. This option will determine for each patch in the patch depot (only one patch in our current example) whether or not that patch matches a piece of software currently installed on the system. If the software to be patched does not exist on the system, the patch(es) listed in the window will not be selected for installation. For example: Patch PHSS_5105 patches the X11 product. If the X11 product is installed on the target system, choosing the "Match What Target Has" option will automatically select patch PHSS_5105 for installation. If the X11 product is not installed on the target system, then PHSS_5105 will not be selected for installation. Each patch has its own product/fileset information which each patch stores internally. Therefore, not having X11 installed on the system will preclude installation of patch PHSS_5105, but will have no effect on other patches listed which patch different products. As with most SD features, the "Match What Target Has" option can be circumvented and any/all patches can manually be selected for installation regardless of the software requirements for each patch. Manual selection of patches for installation is NOT RECOMMENDED and may cause unexplained behavior in the target system after patch installation is complete. - Perform patch installation: Now that all pertinent patches have been selected for installation, they may be installed by going to the "Actions" pull-down menu and selecting "Install(analysis)". This will initiate a very verbose session which will follow each patch from analysis phase through final installation phase. There will be several informational dialog boxes displayed as the process progresses. All will have to be responded to with a button pick of "okay", "yes", or "continue". Any errors that occur during the installation process will be flagged and may stop the process. If you require more detailed information on any of the dialog boxes presented by SD, please refer to: "Managing HP-UX Software with SD-UX" part number: B2355-90054, orderable directly from HP. Disk space calculations are made at three separate times during the patch installation process: 1) SD will calculate the estimated increase in disk space needed in the target directory where the original files will be patched. SD will abort if there isn't enough disk space to install the patch. 2) SD will also report on the amount of disk space it estimates will be consumed in the /var/adm/sw directory due to an increase in size of all the SD logfiles and other software tracking data. Please don't confuse this with the additional disk space calculation which is made while each patch is to be installed. 3) Each patch which will have its original files saved so that it may be backed off the system at a later date will also make a disk space calculation separate from the two mentioned above. This calculation is for the directory /var/adm/sw/patch. This is where all original files to be patched will be saved. This calculation will not be performed if the PATCH_NOSAVE option has been enabled. If any of the 3 disk space calculations mentioned here fail, then the patch will not be installed. 1.5 GETTING PATCHES: === =============== If the patch was obtained via e-mail from HP SupportLine (HPSL) or on a tape from one of the worldwide HP response centers the installation procedure will vary slightly. --------------------------------------------------------------------- These special instructions are required if the patch was delivered via e-mail from HPSL. For further information on HPSL's e-mail service, please send e-mail to support@support.mayfield.hp.com with a message body of 'send guide' (without the quotes). Ignore these instructions if you did not receive your patch via e-mail from HPSL. Patches are chopped up into pieces for electronic mailing to avoid problems with external mailers rejecting large messages. Upon your first e-mail request you will receive a patch_maker script to piece together the patch from your mailbox. If you do not receive the patch_maker script, you can send an e-mail message to support@support.mayfield.hp.com with a text message of 'send patch_maker'. Here are the steps: 1) Save the patch_maker mail message as a file named patch_maker. 2) Edit the patch_maker file to eliminate the mail header. 3) Make the patch_maker file executable with the chmod command. 4) Run the the patch_maker script. Options to this script are: -t type hpux or domain -m mailbox location of the mailbox for which you are pulling the patch - defaults to /usr/mail/`whoami` -p patchname the name identified in the subject line within mail should be used here. In other words, if just the PHxx_yyyy patchname is used, that is what must be specified here. If the full pathname of the patch is used, that is what must be specified here. Example of using the patch_maker script to extract and piece together patch PHSS_5105 from the default mailbox: patch_maker -p PHSS_5105 -t hpux This will create the file PHSS_5105 in the current working directory. At this point, proceed with the standard installation instructions listed in the "INSTALLING PATCHES" section. --------------------------------------------------------------------- If you obtained your patch via tape from the worldwide HP Response Centers, installation can begin using one of the processes outlined below: If the patch is delivered on tape media in SD format: Follow the printed instructions that come with the media. The patches have been loaded onto the media as one SD depot. You can run swinstall with the source file pointing to the media to load one or more patches in a single SD session. 1) login as root 2) run swinstall swinstall -x autoreboot=true -x match_target=true -s /dev/rmt/0m where /dev/rmt/0m should be replaced by the device file for the tape drive containing the patch tape. NOTE: Please use swcluster if installing patches on a NFSD cluster as described in the "INSTALLING PATCHES" section. 3) proceed with the standard installation instructions listed in the "INSTALLING PATCHES" section. If the patch is delivered on tape media in tar format: Follow the printed instructions that come with the media. When the archive media is created the patches are expanded into their .text and .depot portions and are tar-ed off to the media. 1) login as root 2) cd /tmp 3) tar xvf /dev/rmt/0m where /dev/rmt/0m should be replaced by the device file for the tape drive containing the patch tape (This loads all the .text and .depot files into the /tmp directory. The .depot files will be the source(s) for swinstall.) 4) run swinstall swinstall -x autoreboot=true -x match_target=true -s /tmp/PHxx_yyyy.depot NOTE: Please use swcluster if installing patches on a NFSD cluster as described in the "INSTALLING PATCHES" section. 5) continue with the standard installation instructions listed in the "INSTALLING PATCHES" section. 1.6 PATCHING BEHIND THE SCENES: === ========================== SD handles patching files which are busy (executing). It does this by moving the busy file to # and then installing the patch to . When this occurs, the patch will generally not be noticed as taking effect until the original process that was patched is restarted. However, the server cannot always determine whether a file is in use by a NFSD client process. Therefore, HP recommends a shutdown of all NFSD clients prior to installing any patch. In the .text file which accompanies each patch, there is a section for Special Installation Instructions. If this section instructs you to be in single-user mode when applying your patch, and the patch installation involves using swinstall, then please contact your HP support representative for clarification of the instructions. This may simply be a carry-over from the pre-10.X case where single-user mode is recommended. Your HP support representative may tell you to simply ignore it. NOTE: As recommended, when you set the "autoreboot=true" option in the command-line interface, swinstall will force a reboot to happen if necessary for patch installation. If you're in the swinstall interactive interface, swinstall will prompt for and then execute the reboot, if necessary. Only one reboot will be performed (if directed) for each swinstall session, regardless of how many patches require it. All patch activity is logged in the /var/adm/sw/patch/PATCH.log file. It contains a history of all patches which have been installed, superseded, and removed from the target system. Each action is logged with the time and date it was performed. This file should never be manually modified as it is a traceback of all patch activity which has transpired on the target system rather than a snapshot of what is currently installed on the system. This is a sample of a PATCH.log file: PHCO_0001 Installed 02/22/95 10:43:34 PHCO_0002 Installed 02/22/95 10:43:52 PHCO_0001 Superseded by PHCO_1111 02/22/95 10:44:10 PHCO_0002 Superseded by PHCO_1111 02/22/95 10:44:10 PHCO_1111 Installed 02/22/95 10:44:10 PHCO_1111 Superseded by PHCO_2222 02/22/95 10:44:40 PHCO_2222 Installed 02/22/95 10:44:40 PHCO_1111 Un-Superseded 02/22/95 10:45:05 PHCO_2222 Removed 02/22/95 10:45:10 This logfile reads in chronological order starting with the first line. If trying to determine exactly which patches are installed on a system, it will be much clearer to run "swlist -l product PH*". Reading the above logfile will explain the steps taken which left your system in its current state (with PHCO_1111 installed). Because of the requirement to allow any patch to be removed from the system, thus restoring it to its previous state, several pieces of data from each patch need to be saved including the original files that were patched. This data will be stored in the directory /var/adm/sw/patch. This directory should be treated with the same care extended any system directory. Files in this directory may be examined at any time, but no file in this directory should ever be modified or removed, especially if you want to be able to back out patches. Because the amount of data saved in this directory can eventually consume a large amount of disk space (due to storage of original patch files), a tool has been created to manage the disk space in this directory. The tool, cleanup, should be used as the ONLY method for file management of this directory. The cleanup tool will allow a root-user to remove backup copies of the original patch files which consume most of the disk space. Please consult the cleanup(1M) man page that is distributed with the tool. The cleanup tool and man page are available from HP SupportLine (HPSL). Type "echo send PHCO_5400 | mailx support@support.mayfield.hp.com" to get the patch. Please backup the directory /var/adm/sw/patch before using cleanup. A directory for each installed patch will be created in /var/adm/sw/patch. For example, the directory PHSS_5105 will be created for the patch of the same name. In this directory will reside all information necessary to successfully back the patch off of the system and return it to its pre-patched state. If the patch PHSS_5105 is removed, then its corresponding directory in /var/adm/sw/patch will be removed. If the patch PHSS_5105 is superseded by another patch, then the PHSS_5105 directory will be renamed %PHSS_5105. At this point the %PHSS_5105 directory is still an important part of the patch strategy and must be left on the system. --------------------------------------------------------------------- When you install a patch requiring the kernel to be rebuilt, reboots are delayed until all patches selected for installation have been installed, then a single reboot will occur regardless of how many individual patches specified a reboot to take place. When using the command-line method to invoke swinstall, the option "-x autoreboot=true" must be used to allow an automatic reboot of the system immediately after patch installation. If this option isn't used and the patch requires a reboot, then the patch is not installed. If the autoreboot option is not used and the patch does require a system reboot, the following error is generated, and the patch is not installed: ERROR: Installation of software requiring a reboot is, by default, not allowed from the command line. You must specify -x autoreboot=true on the command line to change the default for this session. When using the graphical user interface to swinstall, it will interactively ask for confirmation of a system reboot if it encounters a patch requiring it. --------------------------------------------------------------------- It is not possible to install an older patch over a newer patch as long as a patch has been properly created. All patching is cumulative. That is to say that when a patch supersedes another patch or group of patches, it MUST contain all changes from the patch(es) it supersedes as well as the changes it will introduce to the system itself. Also, when a patch is created, a list of all patches it supersedes must be stored in the patch. So, when the patch is installed the older installed patch(es) are marked as superseded and removed from the IPD, and the new patch added to the IPD. Semaphores are created in subdirectories in /var/adm/sw/patch which will prevent old, superseded patches from being installed over new patches. The mechanism for this is as follows: a directory in /var/adm/sw/patch which stores only semaphores for superseded patches is created, then a file named after the patch is stored there once the patch is superseded. For example, if patch PHCO_0001 is superseded by PHCO_2122, then a file named /var/adm/sw/patch/.SUPERSEDED/PHCO_0001 will contain the text "PHCO_2122". If installation of patch PHCO_0001 is ever attempted, the file PHCO_0001 will be found in the superseded directory and the installation of patch PHCO_0001 will immediately abort warning that PHCO_2122 has superseded it. Caution: If the contents of the /var/adm/sw/patch directory are manually modified, then this checking may not work properly. Data integrity will be maintained in the patch directory with each patch that is installed, but there is no way to protect from deliberate or otherwise unintentional tampering with the data in the /var/adm/sw/patch directory. Please explore this directory in a read-only mode at all times. If you find it necessary to install an older patch over a newer patch that has superseded it, use swremove to remove the superseding patch(es) (see PATCH REMOVAL) then use swinstall to install the older patch (see INSTALLING PATCHES). This method will fail if the superseding patch(es) was installed with the PATCH_NOSAVE option. --------------------------------------------------------------------- It is possible to reinstall the same patch twice. As with most operations in SD, you can force it to do just about anything, but all defaults are set in a logical manner to prevent users from harming the system. If the user specifically tries to install PHSS_5105 and PHSS_5105 is already on the system, the default action for SD is to abort with an error informing the user of their mistake. If the user forces re-installation of a patch and it already resides on the system, data collisions may occur in the /var/adm/sw/patch directory. This may cause unpredictable behavior. If a patch must be re-installed that is currently listed by swlist as being installed, remove the patch first using swremove or swcluster -r, then re-install the patch. It is possible to install a patch that does not apply, but this can easily be avoided. The option: -x match_target=true (command line mode) Actions/Match What Target Has (interactive menu pick) will preclude installing any patch which doesn't belong on the system. This match feature for patch selection should ALWAYS be used when selecting patches for installation. When this feature is used, SD examines each patch and determines if the software that is about to be patched exists on the system. If it does, the patch is selected for installation. If not, the patch will not be selected. As always with SD, you may override this and manually select any patch for installation. This is not recommended, and unpredictable results may occur. 1.7 CHECKING PATCHES AFTER INSTALLATION: === =================================== To show patches currently installed on the system use the SD command swlist(1M). SD keeps an IPD (Installed Products Database) which reflects the current state of the system it is on. This database does not have any kind of record of what transpired to put the system in the state it's in. Referring to the file /var/adm/sw/patch/PATCH.log can give a history of the patches installed to the system in the order they were installed. The SD command which interfaces with the IPD to give reports on current software installation is swlist(1M). Please see the man page, swlist(1M), for a detailed description of the command. To obtain a listing of ALL software products installed on the system type "swlist -l product". To obtain a listing of ALL the software products installed on the heterogeneous NFSD clients type "swlist -r -l product" on the NFSD server. The above option is an "ell", not a one. This list will contain entries for all patches installed on the system as well. To obtain a listing of ALL software patches installed on the system type "swlist -l product PH*". To obtain a listing of ALL the software patches installed on the heterogeneous NFSD clients type "swlist -r -l product PH*" on the NFSD server. This command works because all patch names begin with PH, as in PHSS_5105, and all patches are installed to the system as products. So, the above command will list, at a product-level, all installed products which begin with PH. As each patch is installed, the IPD is modified to reflect the new state of the system. PHSS_5105 will appear in the swlist output as soon as it has been installed, and will disappear from the listing after its removal. Should PHSS_5105 ever be superseded, the superseding patch will appear in the IPD and all references to PHSS_5105 will be removed. If the patch that superseded PHSS_5105 is ever removed, it will disappear from the IPD and PHSS_5105 will reappear. All errors and warnings and notes encountered during patch installation will be logged to the SD logfiles in /var/adm/sw. The logfile containing the most important information sampling from all the other logfiles is swagent.log. Other logfiles important to the patch process are swinstall.log, swcluster.log, swmodify.log, swremove.log, and swverify.log. swinstall.log is the most relevant of the logfiles, because swinstall is the principal underlying SD tool used to install patches. Unless the patch installation process aborted with errors, it is a fairly safe assumption the patch installed correctly. But whenever there is doubt, four things can be done to verify patch installation: 1) Visually inspect the logfiles in /var/adm/sw looking for the keywords ERROR: WARNING: NOTE: Common warnings/errors encountered during patch installation: WARNING: the 'NOSAVE' option (/var/adm/sw/patch/PATCH_NOSAVE) was set to true. Therefore, the patch 'PHSS_5105' cannot be backed off the system. This message can be averted in future installations by removing the file /var/adm/sw/patch/PATCH_NOSAVE. WARNING: couldn't locate ''. File not backed up. This message occurs when a patch is introducing a new file to the system (i.e. a file that was not there at patch installation time). WARNING: The file '' was busy when it was patched. A copy of the file named '#' is still on the system and needs to be removed manually. Also, the system MAY need to be rebooted before the changes to this file take effect. Any file that is in use when a patch is applied to it will generate this message. Don't look for the patch to take effect until the busy process is stopped and then restarted. In some cases this may entail a reboot. WARNING: The file '' could not be located within the filesets listed as affected by this patch. This means the file is being newly introduced to the system via this patch. Therefore, a best guess of '' is being targeted as the destination for this file. This will have no direct impact on the installation of the patch as long as the in question is being newly introduced to the system via this patch (the 90% case). There is a small chance the patch had an error in it when it was created and a fileset was not listed as being effected by this patch. The patch should still install just fine, although it is possible a file will be listed as belonging to a different fileset than was originally intended. WARNING: The patch '' has been manually selected for installation when the product it patches does not currently exist on the system. Installing ''. You have not used the "Match What Target Has" option and instead had manually overridden this safety check and forced SD to install the patch anyway. Results of this could be unpredictable. ERROR: Can't find /usr/lbin/sw/control_utils This message should only appear if SD has been incorrectly installed on the system or is partially missing. ERROR: the patch '' has been superseded by the following patch : >>>> This patch MUST NOT be installed. <<<< This message appears if you try to install a patch that has already been superseded by another patch loaded on the system. ERROR: There is not enough disk space available on /var/adm/sw/patch to save the files to be patched. Installation will not proceed. Either free up disk space on /var/adm/sw/patch and re-install this patch, or touch the file '/var/adm/sw/patch/PATCH_NOSAVE' which will eliminate the backing-up of the original patch files. A lack of disk space has caused the patch process to abort. 2) Run the SD utility swverify to verify the patch has been installed properly. The swverify utility checks what actually exists on the target system with what is reported to exist in the IPD (Installed Products Database). If there is a discrepancy, it will be reported. When a patch is installed, measures are taken to make sure the IPD stays synchronized to reflect exactly what is on the system at any given time. Since patches are installed as their own product, there are two areas of verification that can take place. A) Verify the patch. For example: swverify PHSS_5105 ( for standalone, NFSD servers ) swverify -r PHSS_5105 ( executed on NFSD server to verify NFSD clients ) NOTE: If this method is used for any library patch, it will report an error even though the patch was installed properly. The reason is explained below. Patches exist as separate products when installed on the target system and are listed as such in the IPD (viewed as output of the swlist command). Therefore you may verify a patch directly since it is represented in the IPD as a product. A problem will be encountered when verifying a patch which has patched a library. For example, PHSS_5105 contains a patch to the object modules obj1.o and obj2.o in the library /usr/lib/lib1.a which is a part of the X11 product. After patch installation, the product X11 should swverify just fine, but verification of the patch PHSS_5105 will result in two errors being reported. swverify will report that the files /usr/lib/obj1.o and /usr/lib/obj2.o are missing from the system. This is because the patch installed the two object files, archived them automatically into the library /usr/lib/lib1.a, then removed the object files from disk. After patch installation, the patched object files exist inside the library /usr/lib/lib1.a and not as separate files in the directory /usr/lib. This is a known problem in the patch verification process. This reported verification error in no way compromises the integrity of library patches. B) Verify the fileset(s) that were patched. For example, PHSS_5105 patches the X11.X11-RUN fileset. After patch installation, you may run: swverify X11.X11-RUN (for standalone or NFSD servers ) swverify -r X11.X11-RUN ( executed on NFSD server to verify NFSD clients ) to verify the X11.X11-RUN fileset. swverify makes sure the fileset installed on the system matches up with the IPD. This method of fileset verification should always work and should be the secondary method used to verify patch installation if the verification of the patch itself failed due to the reasons mentioned above. To determine which fileset(s) to verify, look in the PHSS_5105.text file (for example) at the field "Filesets". Run swverify once for each fileset listed in this section of the .text file. 3) Execute the what(1) command on each file replaced by the patch and compare it to the information included in the .text file. The .text file for each patch lists the files replaced by the patch, as well as the expected what(1) output for each of the files. Execute the what(1) command on each file listed in the .text file to insure that the output matches what is documented in the "what(1) Output section" in the .text file. For example, assume PHSS_5105 patches the file /usr/bin/X11/X. To see if the patched version of /usr/bin/X11/X is installed type: what /usr/bin/X11/X and compare the output to the information included in PHSS_5105.text. If the patch replaces an object module in a library, run the what(1) command on the library file instead of the object module. The library file may contain multiple object modules that will report output to the what(1) command, so you may need to filter the output using a command like grep(1). For example, assume PHSS_5105 contains a patch to the object module "obj1.o" in "/usr/lib/lib1.a" you should type: what /usr/lib/lib1.a | grep obj1 and compare the output to the information included in PHSS_5105.text. If the .text file states that the patched file does not generate any output for the what(1) command this verification method should not be used. For heterogeneous NFSD clusters, the what command should be executed on one of the NFSD clients. If executed on the NFSD server, the file path name will have to be pre-pended with /export/shared_roots/OS_700, for example: what /export/shared_roots/OS_700/usr/bin/X11/X 4) Execute the cksum(1) command on each file replaced by the patch and compare it to the information included in the .text file. The .text file for each patch lists the files replaced by the patch as well as the expected cksum(1) output for each of the files. Run the cksum(1) command on each file listed in the .text file to insure that the output matches what is documented in the "cksum(1) Output section" in the .text file. For example, assume PHSS_5105 patches the file /usr/bin/X11/X. To see if the patched version of /usr/bin/X11/X is installed type: cksum /usr/bin/X11/X and compare the output to the information included in PHSS_5105.text. If the patch replaces an object module in a library, the object module will have to be extracted from the library before using the cksum(1) command. For example, assume PHSS_5105 contains a patch to the object module obj1.o in /usr/lib/lib1.a. To check the checksum of obj1.o type: ar -x /usr/lib/lib1.a obj1.o cksum obj1.o and compare the output to the information included in PHSS_5105.text. After the comparison is made, remove the object module that was extracted from the library: rm obj1.o For heterogeneous NFSD clusters, the cksum command should be executed on one of the NFSD clients. If executed on the NFSD server, the file path name will have to be pre-pended with /export/shared_roots/OS_700, for example: cksum /export/shared_roots/OS_700/usr/bin/X11/X 1.8 PATCH REMOVAL: === ============= All patches installed on a 10.X system will appear when the user does an "swlist -l product". Only patches currently installed on the system, and thus appearing in the output from swlist, can be removed. To remove a patch, enter "swremove PHSS_5105" for example, and the patch will be removed from the system. The system will be restored to its pre-patch state by returning pre-patched files to their original locations. These pre-patch files are stored in directories in the /var/adm/sw/patch file structure. The /var/adm/sw/patch directory will also be returned to its pre-patch state. The patch directory created to store all pre-patch data for the given patch will be removed and all semaphores relating to the removed patch will also be removed. Finally, the PATCH.log file will be updated to reflect the recent patch removal. In the Case of NFSD cluster, all commands must be executed on the server. On a homogeneous NFSD cluster, the swcluster -r -i should be used to remove patches. If the DISPLAY environment variable is set, the GUI version of the SD remove utility is launched. From the "View" pull-down menu select "Change Software View" and click on the "Products" radio button. Select the patch PHSS_5105 by clicking on it. From the "Actions" pull-down menu select "Mark for Remove". Next, from the "Actions" pull-down menu select "Remove (analysis)". Once analysis is complete, click on the "OK" button and the Confirmation window will appear with the following message: Pressing "Yes" will exit the swremove preview session. Do you wish to exit swremove and continue with the operation that invoked it? Click "OK" and all the GUI windows will disappear. This results in the patch being removed from the client systems first and then from the server. On a heterogeneous NFSD cluster, the swcluster -r -i command must be executed on the 800 server to remove software from the /export/shared_roots/OS_700 directory, and the "swremove PHSS_5105" must be executed on the 800 server to remove the software from /. In the case of kernel software, SD does not regenerate a kernel, so manual generation is required using the mk_kernel command. If, when the patch was installed, you selected the NOSAVE option by creating the file /var/adm/sw/patch/PATCH_NOSAVE, then no original pre-patch files were saved at patch installation time. This precludes the patch from being removed, that is, the patch is permanently installed. The removal process is smart enough to detect this and will abort patch removal if this is the case. If a patch is being removed which superseded one or more patches, those patches will re-appear in the IPD after the given patch has been removed. Since the superseding patch no longer is on the system, those patches which were superseded must be restored to the database. This is merely an accounting process so you will know what the state of the system is. The superseded patches aren't actually re-installed when the superseding patch is removed, but their functionality is restored when the pre-patched files are moved back to their original locations. The 10.X implementation of patching supports patch removal back as far as you allow. That is, as long as you did not override the automatic save feature of the original pre-patch files during any patch installation, patch removal can proceed back an unlimited number of levels. For example: Base product X11 patched by: PHSS_1000 Patched again and superseded by: PHSS_2000 Patched again and superseded by: PHSS_3000 Patched again and superseded by: PHSS_4000 At this point, an "swlist -l product" will show X11 and PHSS_4000 as both being installed, but PHSS_3000, PHSS_2000, PHSS_1000 will not appear in the listing. "swremove PHSS_4000" will restore the system to the state created by installing PHSS_3000 and PHSS_3000 will now appear in the output of swlist and PHSS_4000 will not. "swremove PHSS_3000" will restore the system to the state created by installing PHSS_2000, etc... All errors and warnings and notes encountered during patch removal will be logged to the SD logfiles in /var/adm/sw (/export/shared_roots/OS_700/var/adm/sw for heterogeneous NFSD clients). The logfile containing the most important information sampling from all the other logfiles is swagent.log. Other logfiles important to the patch process are swinstall.log, swcluster.log, swmodify.log, swremove.log, and swverify.log. swremove.log is the most relevant of the logfiles, because swremove is the principal underlying SD tool used to remove patches. Unless the patch removal process aborted with errors, it is a fairly safe assumption the patch removed correctly. But whenever there is doubt, two things can be done to verify patch removal: 1) Visually inspect the logfiles in /var/adm/sw looking for the keywords ERROR: WARNING: NOTE: Common warnings/errors encountered during patch removal: WARNING: The file '' was busy when the patch '' was removed. Therefore, a copy of the file '#' is still on the system and needs to be removed manually. Also, the system MAY need to be rebooted before the changes to this file take effect. Any patched file that is in use when a patch is removed will generate this message. Don't look for the patch removal to take effect until the busy process is stopped and then restarted. In some cases this may entail a reboot. WARNING: The file '' could not be located within the filesets listed as affected by this patch. This is almost certainly due to this file being newly added to the fileset via this patch. The file's definition will be removed from the fileset ''. After patch removal, the IPD must be updated to reflect what is installed on the system. If a file was added to the system via a patch, then that file's definition needs to be removed from the IPD after the patch which introduced it is removed. No further action is necessary. WARNING: The patch '' was either a kernel patch or required a reboot when it was installed. After removing this patch, SD will NOT automatically reboot the system. The system will have to be MANUALLY rebooted before it returns to its previous behavior before this patch had been installed. There is no mechanism in SD to signal an automatic reboot after patch removal. Therefore, removing a patch which required a reboot after its installation will require a reboot after its removal. Unfortunately, this reboot must be accomplished manually. Also, if the patch was a kernel patch, a new kernel must be regenerated and moved into place before the reboot. ERROR: Couldn't locate the file: ''. Since the file wasn't saved, the patch '' cannot be backed off of the system. This error will occur if a patch was installed with the NOSAVE option enabled. This means there are no original files to replace patched files once they are removed. Therefore, removal must abort. This condition can also occur if, due to disk space constraints, the user has used the cleanup tool to eliminate saved files in the /var/adm/sw/patch directory. The NOSAVE option may be enabled by the following command: echo > /var/adm/sw/patch/PATCH_NOSAVE The NOSAVE option may be disabled by the following command: rm /var/adm/sw/patch/PATCH_NOSAVE Enabling the NOSAVE option guarantees that no original files to be patched are saved. This will conserve disk space, but will disable removal of any patches installed while this option is in effect. The default when installing patches is to save all files to be patched. Careful consideration should be taken before enabling the NOSAVE option. Files saved during patching can always be removed at a later date, using cleanup, after you have installed the patch and are satisfied with the behavior of your applications thus determining the patch should never be removed. 2) Use swverify to insure that the patched product is installed correctly. For details, see the "CHECKING PATCHES AFTER INSTALLATION" section in this paper. You can use swverify on the original product which was patched and also on the un-superseded patches if you like, though the latter is not necessary. With each patch installed, a small group of small data files are generated and stored in the directory /var/adm/sw/patch in a directory with the same name as the patch itself. These files use such a small amount of disk space, that even when multiplied by 100 or 1000, the total is still measured in K-bytes rather than M-bytes. However, in order to implement patch removal, it is necessary to save all original files which will be patched. That way, if the patch is removed from the system, the files which were patched can be restored to their original state. Saving these files in /var/adm/sw/patch/ can eventually consume large quantities of disk space. In order to manage the disk space in /var/adm/sw/patch, a tool has been provided: cleanup. The following information appeared earlier: The cleanup tool and man page are available from HP SupportLine (HPSL). Type "echo send PHCO_5400 | mailx support@support.mayfield.hp.com" to get the patch. Please backup the directory /var/adm/sw/patch before using cleanup. The cleanup tool is the ONLY supported method of disk space management in the /var/adm/sw/patch directory. If files are removed from this directory by any means other than the cleanup tool, results will be unpredictable and unsupportable. NOTE: It is strongly suggested you create a backup of the /var/adm/sw/patch directory before using cleanup in case you accidentally remove more than you intended or you change your mind and would like to undo the cleanup action. The default action for cleanup is to remove all the backup files for superseded patches. This will still allow the user to use swremove to remove the latest patches installed on the system. This default action will not recover disk space if no patches installed on the system have ever been superseded. A more drastic action performed by "cleanup -F" is to remove ALL backup data for all patches installed on the system. This will commit the patches to the system as none can be backed off after this action is performed. All actions performed by cleanup ask for confirmation before proceeding. SD logfiles tend to grow at a rather fast rate due to the amount of information logged to them for each SD action performed. "cleanup -t" can be used to trim these files as well. Please do not trim SD logfiles manually. Please refer to the cleanup(1M) man page which can be obtained with the cleanup program for a more complete description of cleanup. 1.9 DEPOT MANAGEMENT: === ================ SD uses software depots as a way of storing software for future installation. They can be a single file in tar(1M) format or a hierarchical directory structure rooted in a directory with the name of the depot. The format of the depot is of no direct concern as SD understands both formats without special designation and the only real difference between the two formats is how they were created using the swpackage utility. Depots obtained from HP in a shar patch package can be used directly for patch installation once they are unshared. Individual patches will contain a single patch depot. If you want to install several patches, it can be cumbersome to do this from several individual patch depots. Therefore, you may want to create a new depot which contains several patches. Patches going into new depots do not have to be grouped according to which products they patch because the "Match What Target Has" functionality will select only those for installation which apply to each target system. To create a new depot, execute the following command once for each patch which is to be placed into the depot: swcopy -s @ Example: swcopy -s /tmp/PHSS_5105.depot PHSS_5105 @ /tmp/new_depot.depot This will put the patch PHSS_5105 into the new depot at /tmp/new_depot.depot. Now each time swcopy is executed for a different patch, that patch will be added to the new depot. Where the new depot(s) are created and stored depends on your individual needs, but a convenient location might be a new directory named /var/spool/sw/patch. If the interactive interface to swinstall is being used, a convenient way to access patch depots from within swinstall is to register them. To register a depot, use the swreg(1) command: swreg -l depot For example: swreg -l depot /tmp/PHSS_5105.depot When a depot is registered, it is recognized in the interactive interface to swinstall under the Source Depot Path button. Pick this button and a menu will appear listing all depots which are currently registered on the system. The depot can then be picked with the cursor rather than having to be manually typed in. A depot does not have to be registered before it can be used. It only has to be registered to appear in the registered depot list. The command to unregister any patch depot on the target system is: swreg -l depot -u For example: swreg -l depot -u /tmp/PHSS_5105.depot