2 Features and Restrictions

This chapter introduces you to the dupatch utility for installing, removing, and managing patches. It also provides information you must be aware of when installing patches.

2.1 Patch Management Utility

All official Tru64 UNIX, ASE, and TCR patches are installed, removed, and managed through the setld-based patch management utility dupatch. Because dupatch manages patch interdependencies, direct setld installations and deinstallations (setld -l -d) are disabled.

Directions for enabling or disabling patches are provided after the successful installation or removal of all selected patches (for example, kernel rebuild and system reboot).

With dupatch, you can perform the following actions:

Install and remove all or selected patches.

View the patch-specific documentation.

View patch tracking and management information.

Establish a baseline for systems that have had manually installed system files placed on them.

The dupatch utility captures patching activities in the following log files:

Every time dupatch is run a session log that captures dupatch activities is created. It is located in /var/adm/patch/log/session.log. Up to 25 copies of the session log are saved. The order is first in, first out -- with session.log.25 as the oldest file.

When you run dupatch from the newly untarred kit or from the mounted Tru64 UNIX Patch CD-ROM, dupatch will determine if the patch distribution contains new patch tools and load them if necessary. The patch tools loading is captured in the log file /var/adm/patch/log/Dupatch_load_Date.log:
For example: Dupatch_load_1998Oct21:15:43:35.log

When you run the system baselining feature, a baseline log is created in /var/adm/patch/log/baseline.log. Up to 25 copies of the baseline log are saved. The order is first in, first out -- with baseline.log.25 as the oldest file.

When patches are installed or removed, an event log that captures installation and removal information is created. It is located in /var/adm/patch/log/event.log. Only one copy of the file is updated every time patches are installed or removed.

The dupatch utility also manages the system inventory for Tru64 UNIX, ASE, and TCR patches. This enables patch tracking and management of patch activity such as:

Tracking current dupatch-installed patches.

Ensuring 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..).

Validating patch applicability to existing system files (collision detection).

2.2 Patch Installation and Removal

Patch installation and removal is accomplished through the dupatch utility. For patch installation and removal dupatch manages the following:

Patch applicability

Patch dependencies

Patch reversability

System inventory changes for patches

Capturing patch activities in log files

2.2.1 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, ASE, and TCR patches.

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

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

The underlying software product subset is not installed. For example if the applicable Tru64 UNIX, ASE, or TCR release subset is not installed.

The setld inventory is inconsistent with the existing system files. This occurs when an operating system, ASE, or TCR setld subset is installed and individual operating system files that are part of that subset are moved, deleted, or replaced.

Any of the 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 or prerelease patch installations) are not inadvertently overwritten. You must take special action, through the baseline feature, to enable patch installation in this situation.

2.2.2 Patch Dependency Management

Selective patch installation and removal is allowed in the Tru64 UNIX, ASE, and TCR patch kits. When patches are selectively chosen, dupatch provides warning messages regarding other dependent patches requiring installation or removal for correct system operation.

The dupatch utility manages the dependencies between patches within each product patch kit and across product patch kits. For example, dupatch manages the following kinds of dependencies when patches on systems where both Version 4.0B and TCR1.4A are installed or removed:

Patch dependencies within a product patch kit
If, for example, DIGITAL UNIX 4.0B Patch 1.00 is chosen for installation and it depends upon DIGITAL UNIX 4.0B Patch 5.00, which is not already installed or chosen for installation, the dupatch preinstallation check will warn you of the dependency and prevent the installation of DIGITAL UNIX 4.0B Patch 1.00.
If the patch selections are reversed, dupatch will warn you and prevent installation of the chosen patch.

Patch dependencies across product patch kits
If, for example, DIGITAL UNIX 4.0B Patch 1.00 is chosen for installation and it depends upon TruClusters 1.4A Patch 17.00, which is not already installed or chosen for installation, the dupatch preinstallation check will warn you of the dependency and prevent the installation of the DIGITAL UNIX 4.0B Patch 1.00.
If the patch selections are reversed, dupatch will warn you and prevent installation of the chosen patch.

Note

Even though selective patch installation capabilities exist, Compaq recommends that you install all patches for Tru64 UNIX, ASE, and TCR to prevent the occurrence of known and corrected software problems.

2.2.3 Patch Reversibility

Enabling patch reversibility during patch installation allows you to revert the system to its state prior to the installation of a particular patch.

By default, the reversibility installation option is set to enable reversibility for patches. If you choose to make patch subsets nonreversible, then those patches will become nonremovable upon the successful installation of those patches.

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.

To further reduce the storage space required to save existing system files, the patch kits for Tru64 UNIX, ASE, and TCR save the files in a compressed tar image for each patch. Tru64 UNIX Version 4.n releases do this with the gzip utility. This results in a file with a name like filename.tar.gz.

DIGITAL UNIX Version 3.2G uses the compress utility to save the files in a compressed tar image for each patch; this results in a file with a name like filename.tar.Z. The file name is the patch subset name that replaced the system files.

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

2.2.4 Patch Installation and Removal Event Log

Patch installation and removal activities are logged in the patch event log located in /var/adm/patch/log/event.log. The information in the patch event log is not yet available through the dupatch user interface. However, the file is plain text and can be viewed manually.

The following list describes the content of the event log. Note that the format and content are subject to change.

DUPATCH_REV>	Revision of `dupatch` being used
TYPE>	Type of action, install or remove
NAME>	Name entered by user through `dupatch` query
USER>	User name of user performing the action
NOTES>	Notes entered by user through `dupatch` query
SUCCEED>	List of patches for which the action succeeded
FAIL>	List of patches for which the action failed

2.3 Viewing Patch Documentation

The dupatch utility allows you to view the patch documentation for installed patches and for the patches available from a specified patch kit. This documentation includes the following:

Patch Abstracts
These provide summaries of the problems corrected by the patches. You can view the problems corrected by installed patches or by patches available from a specific kit.

Patch README files
These files 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.

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

2.4 Viewing Patch Tracking Information

The dupatch utility allows you to view the following patch installation and removal information:

List of dupatch-installed patches on the system

List of patched files on the system

DIGITAL UNIX Patch Utility (Rev. 25-10) ========================== - This dupatch session is logged in /var/adm/patch/log/session.log Patch Tracking Menu: ------------------- 1) List installed patches 2) List installed patch files 3) List patch kit information on installed patches b) Back to Main Menu q) Quit Enter your choice: 2 The list of all patched files on your system: -------------------------------------------- (depending upon the number of patches you installed, this may take a while) ./sbin/dd (DIGITAL_UNIX_V4.0B Patch 0101.01) ./sbin/ls (DIGITAL_UNIX_V4.0B Patch 0136.01) ./sbin/mount (DIGITAL_UNIX_V4.0B Patch 0136.01) ./sbin/ufs_fsck (DIGITAL_UNIX_V4.0B Patch 0157.01) ./sbin/umount (DIGITAL_UNIX_V4.0B Patch 0136.01) ./shlib/libc.so (DIGITAL_UNIX_V4.0B Patch 0136.01) ./shlib/libc_r.so (DIGITAL_UNIX_V4.0B Patch 0136.01) ./sys/BINARY/arch_alpha.mod (DIGITAL_UNIX_V4.0B Patch 0157.01) ./sys/BINARY/arch_alphapmap.mod (DIGITAL_UNIX_V4.0B Patch 0157.01) ./sys/BINARY/cam.mod (DIGITAL_UNIX_V4.0B Patch 0157.01) ./sys/BINARY/cam_disk.mod (DIGITAL_UNIX_V4.0B Patch 0157.01) ./sys/BINARY/cam_isp1020.mod (DIGITAL_UNIX_V4.0B Patch 0157.01) ./sys/BINARY/cam_sim.mod (DIGITAL_UNIX_V4.0B Patch 0157.01) ./sys/BINARY/ether.mod (DIGITAL_UNIX_V4.0B Patch 0157.01) ./sys/BINARY/ffm_fs.mod (DIGITAL_UNIX_V4.0B Patch 0157.01) ./sys/BINARY/inet.mod (DIGITAL_UNIX_V4.0B Patch 0157.01) ./sys/BINARY/loop.mod (DIGITAL_UNIX_V4.0B Patch 0157.01) ./sys/BINARY/nfs.mod (DIGITAL_UNIX_V4.0B Patch 0157.01) ./sys/BINARY/presto.mod (DIGITAL_UNIX_V4.0B Patch 0157.01) ./sys/BINARY/procfs.mod (DIGITAL_UNIX_V4.0B Patch 0157.01) ./sys/BINARY/re_xcr.mod (DIGITAL_UNIX_V4.0B Patch 0157.01) Press RETURN to get back to the Patch Tracking Menu...

List of patch kit information on installed patches

If no patches are installed on the system, you will receive a message similar to the following:

There are no patches installed on your system.

2.5 Optional Multiuser Patch Installation Preparation

You must be in single-user mode to install and remove Tru64 UNIX, ASE, and TCR patches. However, the following activities can be done in multiuser mode:

Untar or mount the patch kit.

View patch documentation, special instructions, and existing dupatch-installed patches on your system when logged in as root.
Viewing documentation, special instructions, or installed patches can be done by root and non-root users. When these functions are executed by a root user, the session is logged in a new session.log. The session is not logged when the functions are executed by a non-root user.
The tracking list of patched files now includes the patch subset from which they were installed. When a file is patched multiple times, all instances will be listed.

Select and verify patch installation when logged in as root.
Note that while in multiuser mode, you cannot verify the space needed to rebuild the kernel nor whether the kernel rebuild will be successful.

Set the system baseline when logged in as root.

2.6 Handling Manually Installed System Files with Baselining

The dupatch utility adheres to installation conflict management rules that prevent it from installing patches when the system files have been changed through manual installation methods.

System files with unknown origins result from manually installing prerelease patches; replacement of Tru64 UNIX commands and utilities with system administrator customized versions or freeware versions of those commands or utilities; or movement of files between various systems.

Missing system files result from a root user manually deleting system files that were installed via setld. The file is removed but the system inventory records are still in place.

The dupatch baselining feature allows you to enable dupatch to override the collision detection mechanisms so it will selectively install patches over system files that are unknown or missing. It is important that you understand the origin of the changed system files prior to enabling dupatch to overwrite them through patch installation.

For example, a file whose origin is unknown may be part of a manually installed prerelease patch which is not contained in the current official patch kit. Allowing dupatch to overwrite one file of a prerelease patch will leave your operating system software environment in an inconsistent and nonoperational state.

Warning

Enabling dupatch baselining to update your system sets a new baseline for your operating system, ASE, or TCR 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. Compaq recommends that you backup your /, /usr, and /var file systems before enabling system updates through dupatch baselining.

When you run the dupatch system baseline feature, a baseline log file is captured in /var/adm/patch/log/baseline.log. Up to 25 copies of the baseline log are saved. The order is first in, first out -- with baseline.log.25 as the oldest file.

Manually installed system customizations will block patch installation until corrective action is taken and you enable dupatch to override the installation conflict mechanisms.

You will 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.

Baselining is broken into five phases that provide system information and optionally allow you to take actions that change the patch baseline of your system. You can run through all phases of baselining to get the system analysis without enabling changes to your system.

You can run baselining in multiuser mode when you are the root user.

2.6.1 Phase 1 - System Evaluation

The primary goal of Phase 1 is to evaluate your system relative to the patch kit that is being installed. However, the baselining feature will report all missing and unknown files to assist you in better understanding the state of the changed files on the system.

The rest of the baselining phases use the information gathered in Phase 1 to inform you of any installation conflicts for patches contained in the patch kit.

The amount of time needed to evaluate the state of the system varies greatly depending on the size of the patch kit, the version of the software product, and the performance of the system.

2.6.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 render the layered product or application nonoperational.

To resolve this situation contact your layered product or application Customer Services or Compaq Services if you have purchased Business Critical Services.

2.6.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, until recently ASE and TCR official patches were installed manually. This phase will report any manually installed official patch files that exactly match a patch contained in the current dupatch-based ASE or TCR 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.6.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.6.4.1 Manually Installed Prerelease Patches

In response to a problem report, you may receive a prerelease patch from Compaq Services. Prerelease patches (also called a point patch or test patches) are a set of compatible files that deliver fixes to the problems you reported. Additionally the patch may include instrumentation necessary for debugging purposes.

If your system was customized through a manual installation of prerelease patches, you must ensure that the fixes delivered by the prerelease patches are included in the current official patch kit before enabling dupatch to overwrite any unknown or missing system files.

Warning

If you are unsure if the prerelease patch is included in the official patch kit, do not enable dupatch to overwrite the manually installed prerelease patch. If you must install the official patch being blocked by a prerelease patch, contact your service provider for assistance.

If the unknown or missing files are attributable to manually installed prerelease patches that are included in the official patch kit, perform one of the following steps:

If all prerelease patch files are overwritten by the patches noted in Phase 5, you can safely enable dupatch to overwrite applicable missing or unknown system files.

If some of the prerelease patch files are not overwritten by the patches noted in Phase 5, contact your service provider for assistance.

To determine if your prerelease patch is included in the official patch kit, refer to the Patch Summary and Release Notes for the official patch kit, the Compaq Services Web-based patch search engine (http://www.support.compaq.com/patches/index.html), your service provider, or your Compaq Services representative (if you have purchased Business Critical Services).

2.6.4.2 Manually Installed Official Patches

For some software products, manual installation has been the practiced method for patch installation. For example, up to now official patches for ASE and TCR have been manually installed.

You must determine whether the fixes delivered by the manually installed official patches are included in the current dupatch-based official patch kit before enabling dupatch to overwrite any unknown or missing system files. Once you have made this determination, proceed as follows:

If the unknown or missing system files are attributable to manual installation of official patches and the patches are included in the current dupatch-based official patch kit, you can safely enable dupatch to overwrite applicable missing or unknown system files.

If the unknown or missing system files are not attributable to manual installation, you must understand the origin of the unknown or missing system files by reviewing the information reported in Phase 4 against your log of manual system changes to ensure you understand why the system was intentionally customized, and to determine how to proceed.

2.6.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.6.5 Phase 5 - Enabling dupatch to Overwrite Changed System Files

The fifth phase reports patches that are blocked due to missing or unknown system files, and optionally allows you to override the dupatch conflict management mechanism so the dupatch-based patch may be installed.

For each patch that is blocked by a missing or unknown system file you are presented with the following information:

Software product identifier

Patch category

Patch identifier

Patch subset description

The list of unknown and missing files that block the patch installation

The origin of all other files contained in the patch

Optionally, you can enable dupatch to override the collision detection mechanisms and install any of these patches. Use the missing and unknown file information presented in Phase 4 and your system administration log of manual system changes to make Phase 5 patch installation enabling decisions.

Warning

Do not enable dupatch to install patches over missing or unknown system files for which you do not know the origin. Doing so may cause your operating system, ASE, and TCR software environment to be in an inconsistent and nonoperational state.

2.7 Command Line User Interface

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.

The following example shows the use of the dupatch command and several of its options to install DIGITAL UNIX 4.0B Patch 8.01:

/usr/sbin/dupatch -install -kit /var/bl11/patch_kit -name Mary -note \ "install patch" -product DIGITAL_UNIX_V4.0B -patch 08.01

The following example shows the use of the dupatch command and several of its options to install DIGITAL UNIX 4.0B Patch 8.01:

/usr/sbin/dupatch -delete -name Mary -note "delete patch" \ -product DIGITAL_UNIX_V4.0B -patch 08.01

2.7.1 Using Command Line Options

You must specify all mandatory options on the command line or in the data_file 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.

Remember, there is no reason to delete old official patches on you system before installing the new official patches.

Note

When using the command line, the -product option must proceed the -patch option.

2.7.2 Restriction for Loading New dupatch Tools from the Command Line

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.

If you want to use the delete from the command line, you can first load the new tools, without impacting the system, by issuing the install command with the -precheck_only option. This will load the tools and not cause changes to your system.

2.7.3 Command line Interface Options

The following list shows all of the command line interface options (typing dupatch -help provides the same information):

dupatch -delete

       [Mandatory options]
        -name user_name
        -note user_note
        -patch all | patch_id{patch_id...]

        [Optional options]
        -data data_file
        -nolog (No session logging)
        -proceed ( Proceed with patches that passed predeletion check)
        -product all | product_id*
        -root root_path

*Mandatory when more than one product is available for operation

dupatch -help

           [Optional options]
        -data_file   (Specifiesdata_file use)
        -kit kit_location
        -patch_id    ( Specifiespatch_id use)
        -rev   (Lists dupatch version)
        -product_id  (Specifiesproduct_id use)

dupatch -install

        [Mandatory options]

        -kit kit_location
        -name user_name*
        -note user_note*
        -patch all | patch_id[patch_id...]
  *Optional when -precheck_only is specified

       [Optional options]

        -data data_file
        -nobackup
        -nolog (No session logging
        -precheck_only (Check patch applicability without installing)
        -proceed  (Proceed with patches that passed preinstallation check)
        -product all | product_id*
        -root root_path
*Mandatory when more that one product is available for operation.

dupatch -track

        [Mandatory options]

        -typefile | kit | patch

       (Use file to list all patched files.)
       (Use kit to list installed patch kits.)
       (Use patch to list installed patches.)

       [Optional options]
        -datadata_file
        -nolog (No session logging.)
         -rootroot_path

Using a Data_file

When using the -data option, you must specify a data_file, which is a file path that contains specifications with the following format:

switch1=value
switch2=value
       .
       .
       .
switch3

For example:

kit = /mnt
name = John Doe
note = install April patch kit
patch = all

precheck_only
nobackup

The following list describes characteristics of a data_file:

Blank lines and comments (preceded with #) are allowed.

Line continuation (\) is required if a specification spans multiple lines.

When a option is specified both on the command line and in the data_file, the value specified on the command line overrides that specified in the data-file.

Using a patch_id

The following list describes the characteristics of a patch_id:

A valid patch_id specification has the following format:
all
xxxx[.yy]

For example:
15
200.11
10.2
00111.02

Both xxxx and yy are numeric values; leading zeros can be omitted.

Patch revision (yy), when left unspecified, maps to wildcarded "??"

Multiple patch_id specifications are separated by white space.

The keyword all cannot be combined with other patch_ids.

Using a product_id

The following list describes the characteristics of a product_id.

A valid product_id specification is in the format of:

all
description_version

where description is the product description, and version is the product version.
For example:
DIGITAL_UNIX_V4.0
TruCluster_V1.4A

Product_id specifications are case insensitive.

Wildcards are not allowed in product_id specifications.

Multiple product_id specifications are separated by white space.

The keyword all cannot be combined with other product_ids.

Using a root_path

The following list describes the characteristics of a root_path:

The -root option, which is similar to the -D option of setld, specifies an alternative root for the specified operation.

The root_path must be the root of a complete Tru64 UNIX file system.

The default root_path is / for all operations.

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.

Using Product Strings

The following list provides valid Tru64 UNIX product strings:

  DIGITAL_UNIX_V4.0F
  DIGITAL_UNIX_V4.0E
  DIGITAL_UNIX_V4.0D
  DIGITAL_UNIX_V4.0C
  DIGITAL_UNIX_V4.0B
  DIGITAL_UNIX_V4.0A
  DIGITAL_UNIX_V3.2G
  ASE_V1.3
  TruCluster_V1.5
  TruCluster_V1.4A
  TruCluster_V1.0

The following list describes characteristics of product strings:

A product_string specification only applies to the patch_id specifications that follow it and ends when another product_string is specified.

A product_string specification is not necessary when the system being patched has only one product installed. For example, Version 4.0B with no TCR.

Because the purpose of the product_string is to clarify the patch_id specification, its specification must precede that of the patch_id.

The following example shows the product_string:

dupatch -install -product DIGITAL_UNIX_V4.0D -patch 1.1 -product TruCluster_V1.5 -patch 35 \
-name Mary -note "installing patch 1.1" -kit

2.8 Restrictions

The following sections describe information you must be aware of when installing or removing.

2.8.1 Tru64 UNIX Operating System Patches Must Be Applied in Single-User Mode

The installation and removal phases of Tru64 UNIX operating system, ASE, and TCR patch kits require the system to be in single-user mode to ensure computing environment integrity. You can have the network started if you need to access your patch kits. Patch selection and preinstallation checking can be accomplished in multiuser mode. However, the actual installation must be done in single-user mode.

Minimally, a system reboot is required to complete the installation and bring the system to a consistent running environment. Certain file types, such as libraries, are not moved into place until you reboot the system.

Depending upon the patches installed, a kernel rebuild and a system reboot are both required to enable the use of newly installed patches.

2.8.2 Impact on System Upgrades to Later Versions of Tru64 UNIX

In the presence of patches or layered products, certain procedures used to upgrade a system to a later version of Tru64 UNIX can lead to an inconsistency among operating system and layered product objects. For more information see Chapter 6 for general Tru64 UNIX system upgrade information.

Note

After successfully installing a new version of DIGITAL UNIX, you should obtain and install the latest patch kit that is applicable to that version of Tru64 UNIX.

2.8.3 Root Access Is Required to Install and Remove Patch Kits

Installation and removal of patches requires root or superuser access to the system.

2.8.4 No RIS or DMS Installation of Patches

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.

2.8.5 Direct setld Installation and Removal of Patch Subsets Is Not Allowed

You can install and remove Tru64 UNIX, ASE, and TCR patches only through dupatch. You cannot directly install or reinstall the patch subsets with setld. This ensures that patch tracking and management is not compromised.

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

2.8.7 No Ctrl/c During Installation Phase

Do not enter a Ctrl/c command during the installation phase of the patch kit.

Warning

As with any system update, entering a Ctrl/c during this phase will leave the operating system software environment in an inconsistent and nonrecoverable state.

2.8.8 Deleting Patches Containing Customized Files

If you use dupatch to delete a patch containing a customized file, messages similar to the following may appear in the session log file, /var/adm/patch/log/session.log:

Customization found in /<path>/filename
 
Before the backup was restored, we had saved a copy of this file in:
 
   /<path>/filename.PreDel_OSFPATyyy
 
Please compare /<path>/filename with this saved copy.
 
If there are extra customizations you want to keep, you would need
to merge them into <path>/filename manually.
 
/<path>/filename.PreDel_OSFPATyyy
can be removed afterwards.

In this message, /<path>/filename is the full path of the customized file being replaced, and yyy is the patch subset ID number. This message warns you to examine the deleted patch for any customized files it may contain. In order to keep those customizations, you will have to manually add them.

The following are examples of such customized files:

/usr/var/spool/cron/crontabs/root

/etc/sysconfigtab

/usr/var/adm/sendmail/sendmail.cf