2    TruCluster Server Patches

This chapter provides information about the patches included in Patch Kit 2 for the TruCluster Server software.

This chapter is organized as follows:

• Section 2.1 provides release notes that are specific to the TruCluster Server software patches in this kit.

• Section 2.2 provides brief descriptions of the TruCluster Server patches included in this kit.

2.1    Release Notes

This section provides release notes that are specific to the TruCluster Server software patches in this kit.

2.1.1    Required Storage Space

The following storage space is required to install the base and TruCluster Server components of this patch kit:

• Approximately 250 MB of temporary storage space is required to untar this patch kit (base and TruCluster). We recommend that this kit not be placed in the /, /usr, or /var file systems because doing so may unduly constrain the available storage space for the patching activity.

• Approximately 89.3 MB of storage space in /var/adm/patch/backup may be required for archived original files if you choose to install and revert all patches. See the Patch Kit Installation Instructions for more information.

• Approximately 90.7 MB of storage space in /var/adm/patch may be required for original files if you choose to install and revert all patches. See the Patch Kit Installation Instructions for more information.

• Approximately 1224 KB of storage space is required in /var/adm/patch/doc for patch abstract and README documentation.

• Approximately 176 KB of storage space is needed in /usr/sbin/dupatch for the patch management utility.

See Section 1.1.1 for information on space needed for the operating system patches.

2.1.2    AlphaServer ES47 or AlphaServer GS1280 Hangs When Added to Cluster

If after running clu_add_member to add an AlphaServer ES47 or AlphaServer GS1280 as a member of a TruCluster the AlphaServer hangs during its first boot, try rebooting it with the original V5.1B generic cluster kernel, clu_genvmunix.

Use the following instructions to extract and copy the V5.1B cluster genvmunix from your original Tru64 UNIX kit to your AlphaServer ES47 or AlphaServer GS1280 system. In these instructions, the AlphaServer ES47 or AlphaServer GS1280 is designated as member 5. Substitute the appropriate member number for your cluster.

1. Insert the Tru64 UNIX Associated Products Disk 2 into the CD-ROM drive of an active member.

2. Mount the CD-ROM to /mnt. For example:

   # mount -r /dev/disk/cdrom0c /mnt
   

3. Mount the bootdisk of the AlphaServer ES47 or AlphaServer GS1280 on its specific mount point; for example:

   # mount root5_domain#root /cluster/members/member5/boot_partition
   

4. Extract the original clu_genvmunix from the CD-ROM and copy it to the bootdisk of the AlphaServer ES47 or AlphaServer GS1280 member.

   # zcat < TCRBASE540 | ( cd /cluster/admin/tmp; tar -xf - ./usr/opt/TruCluster/clu_genvmunix)
   # cp /cluster/admin/tmp/usr/opt/TruCluster/clu_genvmunix \
   /cluster/members/member?/boot_partition/genvmunix
   # rm /cluster/admin/tmp/usr/opt/TruCluster/clu_genvmunix
   

5. Unmount the CD-ROM and the bootdisk:

   # umount /mnt
   # umount /cluster/members/member5/boot_partition
   

6. Reboot the AlphaServer ES47 or AlphaServer GS1280.

2.1.3    No-Roll Procedure Cannot Be Used to Remove Patch Kit

To remove Patch Kit 2, you must run the /etc/dn_fix_dat.sh script after rebuilding the kernel and before rebooting the system. If the script is not executed before rebooting, the system will fail to boot.

Because the no-roll procedure automatically reboots the system after deleting the patches, you would not be able to run the script as required. Therefore, the no-roll procedure cannot be used to remove the patch kit.

The workaround is to use the rolling upgrade procedure to remove the patch kit. See Section 1.1.3 for more information.

2.1.4    Updates for Rolling Upgrade Procedures

The following sections provide information on rolling upgrade procedures.

2.1.4.1    Noncritical Errors

During a rolling upgrade to installing Patch Kit 2, you may encounter the following noncritical situations:

• The tagged file for ifaccess.conf (.Old..ifaccess.conf) may disappear. This error will not cause any problems with the rolling upgrade procedure or the installation of the kit. A message would alert you to this condition if you use the clu_upgrade undo command. Running the clu_upgrade -v check setup at the start of the procedure will fix this error.

• When the world-wide language subset is installed, the file wwinstall will attempt to be tagged, and will fail. This error will not affect the operational status of the cluster.

2.1.4.2    Procedure for Simultaneous Upgrades

When doing a simultaneous rolling upgrade of NHD6 and the Version 5.1B Patch Kit 2, you must install the NHD6 kit first. If this is not done, you may get a number of installation errors, although you can safely ignore them.

2.1.4.3    Unrecoverable Failure Procedure

The procedure to follow if you encounter unrecoverable failures while running dupatch during a rolling upgrade has changed. The new procedure calls for you to run the clu_upgrade -undo install command and then set the system baseline. The procedure is explained in the Patch Kit Installation Instructions as notes in Section 5.3 and Section 5.6.

2.1.4.4    Do Not Add or Delete OSF, TCR, IOS, or OSH Subsets During Roll

During a rolling upgrade, do not use the /usr/sbin/setld command to add or delete any of the following subsets:

• Base Operating System subsets (those with the prefix OSF).

• TruCluster Server subsets (those with the prefix TCR).

• Worldwide Language Support (WLS) subsets (those with the prefix IOS).

• New Hardware Delivery (NHD) subsets (those with the prefix OSH).

Adding or deleting these subsets during a roll creates inconsistencies in the tagged files.

2.1.4.5    Undo Stages in Correct Order

If you need to undo the install stage, because the lead member is in an unrecoverable state, be sure to undo the stages in the correct order.

During the install stage, clu_upgrade cannot tell whether the roll is going forward or backward. This ambiguity incorrectly allows the clu_upgrade undo preinstall stage to be run before clu_upgrade undo install. Refer to the Patch Kit Installation Instructions for additional information on undoing a rolling patch.

2.1.4.6    Ignore Message About Missing ladebug.cat File

When installing the patch kit during a rolling upgrade, you may see the following error and warning messages. You can ignore these messages and continue with the rolling upgrade.

Creating tagged files.
 
...............................................................................
.....
 
*** Error ***
The tar commands used to create tagged files in the '/usr' file system have
reported the following errors and warnings:
     tar: lib/nls/msg/en_US.88591/ladebug.cat : No such file or directory
.........................................................
 
*** Warning ***
The above errors were detected during the cluster upgrade. If you believe that
the errors are not critical to system operation, you can choose to continue.
If you are unsure, you should check the cluster upgrade log and refer
to clu_upgrade(8) before continuing with the upgrade.

2.1.4.7    clu_upgrade undo of Install Stage Can Result in Incorrect File Permissions

This note applies only when both of the following are true:

• You are using installupdate, dupatch, or nhd_install to perform a rolling upgrade.

• You need to undo the install stage; that is, to use the clu_upgrade undo install command.

In this situation, incorrect file permissions can be set for files on the lead member. This can result in the failure of rsh, rlogin, and other commands that assume user IDs or identities by means of setuid.

The clu_upgrade undo install command must be run from a nonlead member that has access to the lead member's boot disk. After the command completes, follow these steps:

1. Boot the lead member to single-user mode.

2. Run the following script:

   #!/usr/bin/ksh -p
   #
   #    Script for restoring installed permissions
   #
   cd /
   for i in /usr/.smdb./$(OSF|TCR|IOS|OSH)*.sts
   do
     grep -q "_INSTALLED" $i 2>/dev/null && /usr/lbin/fverify -y <"${i%.sts}.inv"
   done
   

3. Rerun installupdate, dupatch, or nhd_install, whichever is appropriate, and complete the rolling upgrade.

For information about rolling upgrades, see Chapter 7 of the Cluster Installation manual, installupdate(8), and clu_upgrade(8).

2.1.4.8    Missing Entry Messages Can Be Ignored During Rolling Patch

During the setup stage of a rolling patch, you might see a message like the following:

Creating tagged files.
............................................................................
 
clubase: Entry not found in /cluster/admin/tmp/stanza.stdin.597530
 
clubase: Entry not found in /cluster/admin/tmp/stanza.stdin.597568

An Entry not found message will appear once for each member in the cluster. The number in the message corresponds to a PID.

You can safely ignore this Entry not found message.

2.1.4.9    Relocating AutoFS During a Rolling Upgrade on a Cluster

This note applies only to performing rolling upgrades on cluster systems that use AutoFS.

During a cluster rolling upgrade, each cluster member is singly halted and rebooted several times. The Patch Kit Installation Instructions direct you to manually relocate applications under the control of Cluster Application Availability (CAA) prior to halting a member on which CAA applications run.

Depending on the amount of NFS traffic, the manual relocation of AutoFS may sometimes fail. Failure is most likely to occur when NFS traffic is heavy. The following procedure avoids that problem.

At the start of the rolling upgrade procedure, use the caa_stat command to learn which member is running AutoFS. For example:

# caa_stat -t
Name           Type           Target    State     Host
------------------------------------------------------------
autofs         application    ONLINE    ONLINE    rye
cluster_lockd  application    ONLINE    ONLINE    rye
clustercron    application    ONLINE    ONLINE    swiss
dhcp           application    ONLINE    ONLINE    swiss
named          application    ONLINE    ONLINE    rye

To minimize your effort in the following procedure, perform the roll stage last on the member where AutoFS runs.

When it is time to perform a manual relocation on a member where AutoFS is running, follow these steps:

1. Stop AutoFS by entering the following command on the member where AutoFS runs:

   # /usr/sbin/caa_stop -f autofs
   

2. Perform the manual relocation of other applications running on that member:

   # /usr/sbin/caa_relocate -s current_member -c target_member
   

After the member that had been running AutoFS has been halted as part of the rolling upgrade procedure, restart AutoFS on a member that is still up. (If this is the roll stage and the halted member is not the last member to be rolled, you can minimize your effort by restarting AutoFS on the member you plan to roll last.)

1. On a member that is up, enter the following command to restart AutoFS. (The member where AutoFS is to run, target_member, must be up and running in multi-user mode.)

   # /usr/sbin/caa_startautofs -c target_member
   

2. Continue with the rolling upgrade procedure.

2.1.5    Additional Steps Required When Installing Patches Before Cluster Creation

This note applies only if you install a patch kit before creating a cluster; that is, if you do the following:

1. Install the Tru64 UNIX base kit.

2. Install the TruCluster Server kit.

3. Install the Version 5.1B patch kit before running the clu_create command.

In this situation, you must then perform three additional steps:

1. Run versw, the version switch command, to set the new version identifier:

   # /usr/sbin/versw -setnew
   

2. Run versw to switch to the new version:

   # /usr/sbin/versw -switch
   

3. Run the clu_create command to create your cluster:

   # /usr/sbin/clu_create
   

2.1.6    When Taking a Cluster Member to Single-User Mode, First Halt the Member

To take a cluster member from multiuser mode to single-user mode, first halt the member and then boot it to single-user mode. For example:

# shutdown -h now
>>> boot -fl s

Halting and booting the system ensures that it provides the minimal set of services to the cluster and that the running cluster has a minimal reliance on the member running in single-user mode.

When the system reaches single-user mode, run the following commands:

# /sbin/init s
# /sbin/bcheckrc
# /usr/sbin/lmf reset

2.1.7    Problems with clu_upgrade switch Stage

If the clu_upgrade switch stage does not complete successfully, you may see a message like the following:

versw: No switch due to inconsistent versions

The problem can be due to one or more members running genvmunix, a generic kernel.

Use the command clu_get_info -full and note each member's version number, as reported in the line beginning

Member base O/S version

If a member has a version number different from that of the other members, shut down the member and reboot it from vmunix, the custom kernel. If multiple members have the different version numbers, reboot them one at a time from vmunix.

2.2    Summary of TruCluster Software Patches

This section provides brief descriptions of the patches in Patch Kit 1 for the software products.

This section provides descriptions of the patches in Patch Kit 2 for the TruCluster Server software products. Because Tru64 UNIX patch kits are cumulative, each patch lists its state according to the following criteria:

• New

  Indicates a patch that is new for this release.

• New (Supersedes Patches ...)

  Indicates a patch that is new to the kit but was combined (merged) with one or more patches during the creation of earlier versions of this kit, before it was publicly released.

• Existing (Kit 1)

  Indicates a patch that was new in the previous Version 5.1B patch kit.

• Supersedes Patches ...

  Indicates a patch that was combined (merged) with other patches.