Patch Kit Updates

You cannot remove a patch kit on systems that have New Hardware Delivery 7 (NHD-7) kit installed when either of the following conditions exist:

If you must remove the patch kit, the only solution is to rebuild your system environment by reinstalling the Version 5.1B operating system and then restoring your system to its state before you installed NHD-7 with the unwanted patch kit.

The Tru64 UNIX CAM subsystem now supports a LUN size of up to 2 TB from the previous maximum limit of 1 TB. This allows Tru64 UNIX to take advantage of the increased LUN size supported by the storage arrays.

This note describes how to manually clone a cluster prior to using the dupclone procedure included on the Version 5.1B-4 CD. See the Patch Kit Installation Instructions (PDF version) for information on using the dupclone script.

Before you being the cloning procedure, ensure that the cluster passes all dupatch pre-installation checks. If a pre-installation check fails, correct the problem. Failing to do so will prevent dupclone from installing the patch kit. The following example shows how to perform the pre-installation check:

	NOTE: In the examples presented in this note, text that is preceded by <–– are comments, and should not be entered.

# pwd
/usr/pk6/patch_kit

# ./dupatch
Enter path to the top of the patch distribution, or enter "q" to quit : /usr/pk6/patch_kit

        * Previous session logs saved in session.log.[1-25]

Tru64 UNIX Patch Utility (Rev. 52-00)
==========================
        - This dupatch session is logged in /var/adm/patch/log/session.log

    Main Menu:
    ---------

    1)  Patch Installation
    2)  Patch Deletion
    3)  Patch Documentation

    4)  Patch Tracking
    5)  Patch Baseline Analysis/Adjustment

    h)  Help on Command Line Interface

    q)  Quit
Enter your choice: 1

Checking Cluster State...done

This system is part of a cluster which has not been prepared to do a 
rolling patch installation or deletion. Do you wish to perform this 
patch operation cluster-wide without using the rolling-patch mechanism?

Please answer y or n ? [y/n]: y

You have chosen to perform this patch operation using the no-roll patch 
method.No-roll patch is designed to patch the cluster as a unit. As a 
result, the entire cluster will be brought to init state 2. After the 
patch operation is completed, the entire cluster will be rebooted. In 
order for the reboot operation to complete correctly, it is necessary 
that cluster quorum be configured to allow for members to be rebooted 
without losing quorum. Do you wish to continue?

Please answer y or n ? [y/n]: y

Tru64 UNIX Patch Utility (Rev. 52-00)
 ==========================
         - This dupatch session is logged in /var/adm/patch/log/session.log

     Patch Installation Menu:
     -----------------------

    1)  Pre-Installation Check ONLY

    3)  Check & Install in Multi-User mode

    b)  Back to Main Menu
    q)  Quit

Enter your choice: 1

	NOTE: The “Pre-Installation Check ONLY” procedure does not force the cluster to run-level 2; it remains at run-level 3 (Multiuser mode).

The following steps show you how to clone a two-member cluster with a quorum disk. The cluster is configured as follows:

Current disk set:

Alternative disk set:

The steps for the procedure follow:

To use the dupatch root option to install Version 5.1B-4 to an alternate root path, you must first install the latest patch tools. To do this:

When installing a Tru64 UNIX patch kit using the no-roll procedure and a cluster member is down, the noroll_versw script may display a message containing a nonexistent command to be used for removing a cluster member.

This occurs if the patch kit installs a patch that requires the use of a version switch. In that case, you would see a message similar to the following at the end of dupatch session:

Patch OSFPAT00074200510 has been identified as needing a version
switch. Once the following reboot is complete, please enter the
"/var/adm/patch/noroll/noroll_versw" command from any cluster member.  

Because the noroll_versw script expects all members to be up, running it when a member is down causes a message similar to the following to be displayed:

The noroll_versw command cannot continue because members 'member1' 
of this  cluster are not up. Please reboot these members before 
re-attempting this  command or remove the members using the 
clu_remove_member(8) command

However, there is no clu_remove_member command. The message should refer to the clu_delete_member member.

Login failures may occur as a result of a rolling upgrade of on systems with Enhanced Security (C2) enabled. The failures may be exhibited in two ways:

The problem may occur after the initial reboot of the lead cluster member or after the rolling upgrade is completed and the clu_upgrade switch procedure has been run. The following sections describe the steps you can take to prevent the problem or correct it after it occurs.

Preventing the problem

You can prevent this problem by performing the following steps before beginning the rolling upgrade:

Correcting the problem

If you have already encountered the problem, perform the following steps to clear it:

Section 2.1.3.6 in the Patch Summary and Release Notes for Patch Kit 4 document says that you can ignore an error message about a missing ladebug.cat file and the warning message that follows. We now suggest that if you see these messages during the setup stage, that you verify that the tagged files were properly created when you execute the preinstall stage.

In cases where the tagged files are not created, you can repeat the setup stage.

During the preinstall stage of a rolling upgrade you have the option of checking tagged files. We suggest that you override the default setting and select the check tag option.

Do not install the NHD–5 or NHD–6 kits on your TruCluster system if you have installed this patch kit or earlier patch kits. Doing so may cause an incorrect system configuration. The installation code for these new hardware delivery kits does not correctly preserve some cluster subset files.

The sticky connection feature included in this kit enables cluster members to remember the servicing cluster member of a connection requested from a specific client. Whenever a new connection comes from an existing client, the cluster router recognizes the client and dispatches that packet to the same member that was previously servicing this client. In this way, all connections from a single client are serviced on a single cluster member.

By default, the sticky connection feature is disabled. You enable it by specifying the following tuning attribute in the /etc/sysconfigtab file:

clua: sticky_net_enabled=1

When enabled, this feature is configured to perform per connection port. You can then configure each port by specifying the “sticky” option in the /etc/clua_services file. For example, the following line in the /etc/clua_services file configures TCP port 3000 to be a sticky port:

    echome          3000/tcp        in_multi,static,sticky

This feature is described in the clua_services(4) and sys_attrs_clua(5) reference pages, which you can download by clicking on the following link:

Save this file to a directory of your choice; for example, /tmp. The tar file contains both reference pages in gzip format.

To install them on your system, untar the file and move the gzip files to the appropriate reference page location. The default location is /usr/share/man/man4 and /usr/share/man/man5. The procedure is as follows:

After moving the files to the reference page directory, they should be available to your system using the man command. You can then remove the sticky_manpage.tar file and its contents from the /tmp directory.

If your system was upgraded to Version 5.1B and higher using the update installation procedure, attempts to install Version 5.1B patch kits may fail on a standalone (non-cluster) system. The problem is that some expected values may be missing or incorrectly in the /etc/sysconfigtab file.

When you run the dupatch utility, the installation process may run through its preliminary stages, and may erroneously leave the impression that the patch kit has been installed.

To work around this problem, take the following steps

You should then be able to install the patch kit.

Keypad Input Fails in Mozilla (Sept. 21, 2004)

Turning on NumLock on a PC keyboard causes Mozilla to not accept input from the keypad. To correct the problem, turn off NumLock when you use Mozilla.

caa_stat Command Request from Non-Root User Fails with Error (Aug 2004)

Attempting to run the caa_stat command as a non-root user fails with the following error message:

    The CAA message catalog entry is missing.   

The installation of Version 5.1B-3 corrects this problem.

The following reference pages were not included in this patch kit, but are available for downloading:

To download these reference pages, save the file pk4_manpages.tar to a directory of your choice; for example, /tmp. The pk4_manpages.tar file contains all ten reference pages in gzip format.

To install them on your system, untar the file and move the gzip files to the appropriate reference page location. The default location on your Tru64 UNIX system is /usr/share/man, which contains subdirectories such as man1, man2, and so on to correspond to the volume of the reference pages. The procedure is as follows:

Once you have moved the files to the reference page directory, they should be available to your system using the man command. You can then remove the pk4_manpage.tar file and its contents from the /tmp directory.

Do not set the sysconfigtab variable Max_LSM_IO_PERFORMANCE = 1 when the root or cluster root domain is under LSM control. Doing so will cause the system to hang during the boot process. To enable this feature, which was added to improve performance on multiprocessor systems running heavy I/O loads, remove the root or cluster root domain from LSM control before setting the Max_LSM_IO_PERFORMANCE variable.

See sys_attrs_lsm(5) for more information.

See “Login Failure Possible with Rolling Upgrade and C2 Security Enabled (Mar. 2005)” for information about this problem.

See “Do Not Install Prior NHD Kits on a Patched System (Feb. 2005)” for information about this problem.

Do not set the sysconfigtab variable Max_LSM_IO_PERFORMANCE = 1 when the root or cluster root domain is under LSM control. Doing so will cause the system to hang during the boot process. To enable this feature, which was added to improve performance on multiprocessor systems running heavy I/O loads, remove the root or cluster root domain from LSM control before setting the Max_LSM_IO_PERFORMANCE variable.

When installing a Release patch kit using dupatch from the command line, rather than using the dupatch menus, you may see a message such as /sbin/ls: arg list too long. This occurs because the large number of patches, when concatenated on the command line, exceed the shell's arg limit. To work around this problem, temporarily change the sysconfigtab value by entering the following command:

# sysconfig -r proc exec_disable_arg_limit=1 

You can then continue the command-line patch installation.

This patch kit contains a version of the sys_check utility that may be a lower version than the one installed on your system if you downloaded and installed the sys_check Web kit. If that is the case, installing this patch kit will downgrade the version of sys_check that is being used by the system. You can, however, restore the later version.

To determine the version recognized by your system, run the following command:

# /usr/sbin/use_sys_check -v

Note: You will be required to create a login account if you have not already done so. If you use the site's search facility, do not specify the .tar file extension.

This problem will be fixed in the next Version 5.1B patch kit.

If this version displayed is lower than the version you downloaded from the Web, you can set the system default to the higher version. In the following example, the sys_check version you installed from the Web is 126:

# /usr/sbin/use_sys_check 126 

If you plan to remove the patch kit, make sure that the system default version of sys_check is set to the version installed with the patch kit before removing the patch kit. After you delete the patch kit, the system default version of sys_check will automatically be set to the version of sys_check that you downloaded from the Web. This is because dupatch saves the symbolic links that point to the Web kit location when the patch gets installed and will restore these symbolic links when the patch gets deleted.

You will encounter problems if you delete the sys_check Web kit and then delete this patch kit, because dupatch will restore the symbolic links to the Web kit location when the patch is deleted. If you have deleted the Web kit, then the symbolic links will point to nonexistent files. You can fix this problem by reinstalling the sys_check Web kit.

Regression in find Command (Nov. 2003)

The find command delivered in Patch 1197.00 contains a regression that affects the traversing of very large directory structures. The following is an example of the error message generated if you should experience the problem:

$ find . -name abc
find: Cannot open file ./path/filename/ 
: Too many open files 

find: cannot open < ./aa5142>
find: cannot open < ./aa5143>
find: cannot open < ./aa5144>
find: cannot open < ./aa5144>

To correct this problem, you must install the following Early Release Patch (ERP) kit:

    T64KIT0020545-V51BB24-E-20031104.tar

You can find this ERP kit on the following Web site:

http://www.itrc.hp.com/service/patch/mainPage.do

The pfilt_loopback and pfilt_physaddr tunable variables (delivered in Patch 1414.00) are only accessible in the kernel by using the dbx debugger.

In a future patch kit, these tunable variables will be implemented as kernel subsystem configurable attributes, accessible through the sysconfig command.

TruCluster Patch 7.00 will not be installed if you install Patch Kit 2 on a TruCluster system running Patch Kit 1. To work around this problem, take one of the following actions:

Patch 685.00 in Patch Kit 2 installs Version 5.1 of the vdump and vrestore utilities. If you use that version to create an archive and then uninstall that patch, attempting to restore the archive will fail with the following message:

   vrestore: Need vrestore V5.1 to restore contents: terminating

This occurs because by removing the patch, vdump and vrestore revert to an earlier version, which does not recognize the Version 5.1 archive.

To restore the archive, you will have to reinstall Patch 685.00 or install the binary file for vrestore included in Patch Kit 2.

When downgrading to an earlier version of the Tru64 UNIX operating system (for example, by uninstalling a patch kit or installing an earlier version of the operating system), an older version of the device special files manager, dsfmgr, may have problems reading the newer version the dsfmgr .dat files. When that happens, you will see a message such as the following during the boot process:

   dsfmgr: Error: cannot open and read file /etc/dfsc.dat
   Bad status file data/format
   dsfmgr: Error: cannot open and read file /etc/dfsl.dat
   Bad status file data/format
   bcheckrc: Device naming failed to boot configure or verify.
   Please correct the problem and continue or reboot.

Uninstalling the Patch Kit

If you made the following changes to your system after installing the patch kit, you will have to undo those changes before you can uninstall the patch kit:

To uninstall the patch kit, do the following:

You can now add the cluster members you removed and reinstall the hardware you removed, as long as the support for it existed in the pre-patched system. You can also reinstall the patch kit.

Actions You Can Take

The following list describes several actions you can take, followed by detailed steps for performing those actions:

Typically, /etc/dfsc.dat is a clusterwide file, while /etc/dfsl.dat is a per-member Context Dependent Symbolic Link (CDSL). For example:

#  ls -l /etc/dfs?.dat
/etc/dfsc.dat
/etc/dfsl.dat -> ../cluster/members/{memb}/etc/dfsl.dat

The sbin/dsfmgr command makes backup copies that have the same file name but a new file extension: .h00, .h01, and so on, where .h00 is the latest backup. For example:

/etc/dfsc.h00
/etc/dfsl.h00 -> ../cluster/members/{memb}/etc/dfsl.h00

Backing Up Original Files

To make backup copies of the original Version V1.0 files before installing the kit, you must be logged in as root. Then proceed as follows:

Determining Which Files Are Version 1.0

The script /etc/dn_fix_dat.sh is intended to restore Version 1.0 of dfsc.dat and dfsl.dat on the member on which it is run. Run /etc/dn_fix_dat.sh on each cluster member before you reboot the member. If /etc/dn_fix_dat.sh is missing or is failing, you will have to perform the following manual steps.

You will then have to configure your system.

An interaction problem with New Hardware Delivery Kit 6 (NHD6) and Patch Kit 2 may cause the patch kit to not install correctly if the following conditions exist:

To work around this problem, install the software as follows:

This problem will be corrected in the NHD7 release.

The installation of this kit causes a problem with the /etc/.mrg..protocols.sh script, in which the script creates a temporary protocols file in /tmp and moves it to /etc instead of copying it to /etc. The result is a change in the file permission for /etc/protocols; for example, the permission might change from 755 to 600.

The workaround is to check and, if necessary, change the permissions on /etc/protocols after installing Patch Kit 1.

After installing this patch kit, the envmond daemon will be disabled on ES47, GS80, and GS1280 AlphaServers..

To enable environmental monitoring, change the entry ENVMON_CONFIGURED=0 to ENVMON_CONFIGURED=1 in the /etc/rc.config file. You can do this using one of the following commands:

See “Problems with /sbin/dsfmgr Versions (Mar. 2003)” for details.

In Section 1.1.5 of the release notes that shipped with kit, the reference to “audit's -m switch” is incorrect. The reference should be to the auditd -d option. The workaround to the problem described in that section should read as follows:

“...boot to single-user mode and remove the -d option from the audit configuration stored in /etc/rc.config.common or /etc/rc.config. “

When you install ssh V3.2 (Patch 389.00) you may see a message similar to the following. You can ignore this message:

AllowCshrcSourcingWithSubsystems is not valid
ForcePTTYAllocation is not valid
IdentityFile is not valid
AuthorizationFile is not valid
Secure Shell daemon (sshd2) started.