1    Release Notes

This chapter provides important information that you need in order to work with the Tru64 UNIX 5.1 and TruCluster 5.1 Patch Kit-0004.

1.1    Patch Process Resources

Compaq provides Web sites to help you with the patching process:

1.2    Required Storage Space

The following storage space is required to successfully install this patch kit:

Base Operating System

TruCluster Server

Note

A rolling upgrade has specific disk space requirements. Be sure to check your disk space before starting a rolling upgrade. Make sure that your system contains the required space in all file systems before you begin the setup stage of the roll. If any file system fails to meet the minimum space requirements, the program will fail and generate an error message similar to the following:

***Error***
The tar commands used to create tagged files in the '/' file system have
reported the following errors and warnings:
NOTE: CFS: File system full: /
 
        tar: sbin/lsm.d/raid5/volsd : No space left on device
        tar: sbin/lsm.d/raid5/volume : No space left on device
NOTE: CFS: File system full: /
 
.NOTE: CFS: File system full: /

If you receive this message, run the clu_upgrade -undo setup command, free up or add the required amount of space on the affected file systems, and then rerun the clu_upgrade setup command.

Rolling upgrade disk space requirements are described in Section 7.4.1 of the TruCluster Server Software Installation manual.

1.3    Inclusion of Baselevel in tar File Name

With this release, the name of the tar file containing the patch distribution has been expanded to include the baselevel for which this kit was built. This formerly internal baselevel number has become a common way of identifying kits. For complete information, see Section 1.3 of the Patch Kit Installation Instructions.

1.4    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 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
    

1.5    Release Note for KZPCC

Under heavy I/O conditions, an open() call to the KZPCC driver can return an I/O error. If this occurs, add the following stanza to your sysconfigtab file:

I2O:
    Max_Job_Pool_Size=1024

In addition, a KZPCC system can hang if you do a physical I/O greater than 4 MB. This is more likely to occur doing I/O to a raw disk with large block size transfers, but can also occur on block devices.

1.6    Release Note for Tru64 UNIX Patch 647.00

1.6.1    Removal of the directio Cloning Patch

This patch provides a script that will allow a user to remove the directio cloning patch after the version switch has been thrown by running clu_upgrade -switch. This script will set back the version identifiers, request a cluster shutdown, and reboot to finish the deletion of the patch. Another rolling upgrade will be required to delete the patch with dupatch.

The /usr/sbin/clone_versw_undo script must be run by root in multiuser mode after the directio cloning patch has been completely rolled in and before another rolling upgrade has begun. A system or cluster shut down will be required to remove the directio cloning patch.

Note

Since the removal of a version switched patch requires a cluster shutdown, only run this script when you are absolutely sure that this patch is the cause of your problem. This script must be run by root in multiuser mode after completing the rolling upgrade that installed the patch and before starting another rolling upgrade. The final removal of the patch can only be accomplished by rebooting the system or cluster after this script completes its processing. This script will offer to shut down your system or cluster at the end of its processing. If you choose to wait, it is your responsiblity to execute the shutdown of the system or cluster.

Do not forget or wait for an extended period of time before shutting down the cluster. Cluster members which attempt to reboot before the entire cluster is shutdown can experience panics or hangs.

See the Patch Kit Installation Instructions for further information.

1.6.2    AdvFS and Direct I/O

In laboratory testing, Compaq has observed that under certain circumstances, a possibility exists that inconsistent data may be written to disk on some Tru64 UNIX V5.0A and V5.1 systems running AdvFS and direct I/O.

Compaq became aware of this possibility only during laboratory testing. To our knowledge, no customer has experienced this problem. Compaq is alerting customers to this potential problem as a precautionary measure.

The conditions under which this potential problem may occur are as follows:

Invalid data could occur when a single direct I/O write spans multiple AdvFS pages, and some, but not all, of the pages are still in the UBC. If the file has been opened only for direct I/O and remains open for direct I/O, the problem does not exist.

Applications that use direct I/O, such as Oracle, could be affected.

Configurations Affected

The potential problem may affect the following systems:

Only V5.0A and V5.1 systems running an application that uses direct I/O could experience this potential problem. Any application using direct I/O must request this feature explicitly.

The following Oracle versions use direct I/O and may therefore be affected:

In addition, the AdvFS file system that is used for any of the following Oracle files:

An Oracle environment meeting the above criteria could experience this potential problem.

Oracle running on raw partitions exclusively or running LSM on raw partitions exclusively are not affected.

Some customers write their own applications that use direct I/O. These customers should be aware of the detailed circumstances under which this problem could occur. The problem could occur as follows:

Under these circumstances, the data written at the start of the total write is the original data, offset by the amount of data written to the last page.

Tru64 UNIX versions V4.* and V5.0 are NOT affected.

The potential problem is fixed in future Tru64 UNIX versions and in V5.0 Patch Kit 3 and V5.1 Patch Kit 3.

Problem

If Oracle customers are running one of the affected Oracle configurations, Oracle may have already detected an inconsistency in the database and reported errors similar to the following in the alert log and trace file:

ORA-01578: ORACLE data block corrupted (file # 1, block # 100)
ORA-01119: data file 1: '/scratch/820/qa/dbs/t_db1.f'
 
 

ORA-00368: checksum error in redo block
ORA-00354: Log corruption near block #231
 
 

Oracle customers that have run the dbverify (dbv) utility may have encountered an error message similar to the following:

***
  Corrupt block relative dba: 0x0040900b (file 0, block 36875)
  Bad header found during dbv:
  Data in bad block -
   type: 27 format: 2 rdba: 0x0040900d
   last change scn: 0x0000.0001349a seq: 0x2 flg: 0x04
   consistency value in tail: 0x349a1b02
   check value in block header: 0xa377, computed block checksum: 0x0
   spare1: 0x0, spare2: 0x0, spare3: 0x0
  ***

1.6.3    Technical Update for KZPCC products

This patch provides support for KZPCC products.

For more information see Tru64 UNIX technical updates provided at the following URL:

http://www.tru64unix.compaq.com/faqs/publications/patch/

Select the option for Operating System Technical Updates and choose the following document:

Tru64 UNIX Version 5.1 Technical Update

This technical update will also contain information for valid upgrade paths to Tru64 UNIX Version 5.1 from the Version 4.0x releases that currently support I2O.

1.6.4    Release Note for KZPCC Products

In a TruCluster environment, the deletion and re-creation of any logical drive on a KZPCC controller using the SWCC utility can result in the drive becoming inaccessable. Even though the hwmgr sees the drive being deleted and added back, it can not be disklabeled nor can any read/write operation be performed to the drive. Rebooting the system will restore the drive to a usable state.

This will be fixed in the next patch kit.

1.6.5    Problem with Multi-user Mode Application

Warning

When applying this patch in multi-user mode, an inconsistency problem results between the updated /shlib/libpthread.so and the existing kernel. The problem manifests itself when you install the patch in multi-user mode and you elect to reboot at a later time. The scheduled reboot will not occur. This problem can be avoided by installing Patch 647.00 in single user mode, or selecting the option to reboot now (rather than scheduling later).

To correct this situation, if you have installed the patch and have not rebooted the system, execute the following commands:

  1. Set DUPATCH_SESLOG to location of session log, by default:

    /var/adm/patch/log/session.log

  2. Get the name of newly-built kernel:

    # NEW_KERNEL=`grep "The new kernel is" $DUPATCH_SESLOG | awk ' { print $5 }' `

  3. Copy the new kernel:

    # cp <NEW_KERNEL> /vmunix

  4. Reboot the system at a specified time:

    # shutdown -r <TIME_OF_REBOOT>

After rebooting with the new kernel, your system will once again be consistent.

1.6.6    New Graphics Card

This patch provides the driver support for a new graphics card. In order to obtain full support for this graphics card, you must also select Patch 509.00, which is the X server portion of the patch.

A list of supported platforms is available on the following web page:

http://www.compaq.com/alphaserver/products/options.html

If you have a system with this new graphics card, you will need to reconfigure and rebuild the kernel after installing this patch.

To do this, follow these steps:

  1. Shut down the system:

    # /usr/sbin/shutdown -h now

  2. Boot genvmunix to single-user mode:

    >>> boot -fi genvmunix -fl s

  3. After the system boots to single-user mode, mount the file systems, run the update command, and activate the swap partition:

    # /sbin/bcheckrc

    # /sbin/update

    # /sbin/swapon -a

  4. Run doconfig to create a new kernel configuration file and rebuild the kernel:

    # /usr/sbin/doconfig

    Note

    Do not specify the -c option to doconfig. If you do, doconfig will use the existing kernel configuration file which will not have the appropriate controller entry for the new graphics card.

  5. Save the old /vmunix file and move the new kernel to /vmunix.

  6. Shut down the system:

    # /usr/sbin/shutdown -h now

  7. Boot the new kernel:

    >>> boot

If you remove this patch from your system after you have rebuilt the kernel to incorporate support for the new graphics card as described previously, you will need to rebuild the kernel again to restore generic VGA graphics support. To do this, follow the steps given previously. The doconfig running on the original, unpatched genvmunix will not recognize the new graphics card and will include generic VGA graphics support in the resulting kernel.

1.6.7    DEGPA-TA Gigabit Ethernet Device

This patch provides support for DEGPA-TA (1000BaseT) Gigabit Ethernet device. If you have a system with this new Ethernet device, you will need to reconfigure and rebuild the kernel after installing this patch.

To do this, follow these steps:

  1. Shut down the system:

    # /usr/sbin/shutdown -h now

  2. Boot genvmunix to single-user mode:

    >>> boot -fi genvmunix -fl s

  3. After the system boots to single-user mode, mount the file systems, run the update command, and activate the swap partition:

    # /sbin/bcheckrc

    # /sbin/update

    # /sbin/swapon -a

  4. Run doconfig to create a new kernel configuration file and rebuild the kernel:

    # /usr/sbin/doconfig

    Note

    Do not specify the -c option to doconfig. If you do, doconfig will use the existing kernel configuration file which will not have the appropriate controller entry for the new graphics card.

  5. Save the old /vmunix file and move the new kernel to /vmunix.

  6. Shut down the system:

    # /usr/sbin/shutdown -h now

  7. Boot the new kernel:

    >>> boot

If you remove this patch from your system after you have rebuilt the kernel to incorporate support for the new Ethernet card as described previously, you will need to rebuild the kernel. To do this, follow the steps given previously. The doconfig running on the original, unpatched genvmunix will not recognize the new Ethernet driver.

1.6.8    Configuring FibreChannel Systems

This patch requires that FibreChannel systems which utilize FibreChannel devices for boot and swap be properly configured as follows:

1.7    Release Note for Tru64 UNIX Patches 324.00 and 496.00

This patch delivers version V1.0-032 of the libots3 library. Version 2.0 (or greater) of the libots3 library is delivered with the Compaq FORTRAN Compiler, Versions V5.3 ECO1 and V5.4, or the Developers Tool Kit (DTK) (OTABASE subset). If libots3 V2.0 (or greater) is already installed on your system, and you install this patch, you will receive the following informational message:

Problem installing:
 
 
- Tru64_UNIX_V5.1 / Software Development Environment Patches:
 
      Patch 00496.00 - Fix for problems in Compaq C compiler
 
 
       ./usr/shlib/libots3.so:
 
                 is installed by:
 
                                 OTABASE212
               and can not be replaced by this patch.
 
This patch will not be installed.

To determine what version of libots3 library is installed on your system, execute the following command:

# what /usr/shlib/libots3.so libots3.so:

libots3.a       V2.0-094 GEM 27 Feb 2001

1.8    Release Note for Tru64 UNIX Patch 614.00

This release note contains a new reference phge for the fixfdmn utility.

NAME
  fixfdmn - Checks and repairs corrupted AdvFS domains
 
SYNOPSIS
 
  /sbin/advfs/fixfdmn [-mtype[,type]...] [-d directory] [-v number] [-a [-c]
  | -n] [-s {y | n}] [domain] [fileset]
 
  /sbin/advfs/fixfdmn -u directory domain
 
OPTIONS
 
  -a  Specifies that after repairing what it can, fixfdmn will attempt to
      activate the domain at the end of the run. This option cannot be used
      with the -n option.
 
  -c  Removes any clone filesets.  This option is only valid if used with the
      -a option.
 
  -d directory
      Specifies a directory to which the message log and undo files will be
      written. If the -d option is not used, the message and undo log files
      are put in the current working directory. The message log file is named
      fixfdmn.<domain>.log and the two undo files are named undo.<domain>.<#>
      and undoidx.<domain>.<#> where # will cause a number to be appended to
      the filenames to make them unique. The numbers will be rotated sequen-
      tially from 0 (zero) through 9 if multiple undo files are created for
      the same domain. The undo file will have the same ending number as its
      corresponding undo index file.
 
  -m type[,type...]
      Specifies a list of types of metadata, one or more of which can be
      checked and repaired. The valid types are log, sbm, sync, bmt, frag,
      quota and files. If you specify the fileset parameter, sync, log, sbm,
      and bmt are made invalid types for the -m option. If you do not specify
      -m, the default is to check all types.
 
      sync
          Corrects the magic number and synchronizes data across volumes (for
          example, volume numbers, mount ids, mount states, domain ids, and
          so on.)
 
      log Resets the transaction log so it is not processed.
 
      sbm Synchronizes the sbm to the information in the bmt.
 
      bmt Corrects the bmt.
 
      frag
          Corrects frag file groups and free lists and ensures that all file
          frags reside in the frag file.
 
      quota
          Checks and corrects sizes of quota files.
 
      files
          Verifies that directory metadata is correct.
 
  -n  Specifies that fixfdmn will check the domain and not do any repairs. It
      will report what problems were found and how it would have fixed them.
 
  -s {y | n}
      Specifies that "yes" or "no" should be answered to prompts when run
      from a script.
 
  -u directory
      Restores the domain to its previous state by undoing the effects of the
      last run of fixfdmn, using the most recent undo files in the specified
      directory.
 
  -v number
      Specifies the verbose mode level which controls the messages printed to
      stdout.
 
      0 = Only error messages
 
      1 = ( Default) Progress, errors and summary messages
 
      2 = Progress messages, detailed error messages, fix information and
      summary messages
 
OPERANDS
 
  domain
      The name of a corrupted domain to repair.
 
  fileset
      The name of the fileset to repair if only one fileset in this domain
      exhibits errors.  You may tell fixfdmn to check only that fileset and
      not specifically look for errors in other filesets.
 
DESCRIPTION
 
  The fixfdmn utility checks and repairs corrupt AdvFS domains and filesets.
 
  The fixfdmn utility is primarily concerned with fixing problems that have a
  limited scope. When a large portion of the domain is corrupted, there is
  very little fixfdmn can do, so it will recommend restoring data from backup
  or running the salvage(8) command.
 
  The fixfdmn utility uses the on-disk metadata to determine what corruptions
  exist in the domain. Only metadata will be repaired, as there is currently
  no way to check or repair the contents of users files.  Only those problems
  which prevent mounting the domain, or would result in a domain or system
  panic, will be repaired.
 
  After major areas of metadata are checked, and if a corruption was fixed,
  fixfdmn will prompt the user to determine if they want to continue looking
  for additional corruption.
 
  If fixfdmn detects an error in a clone fileset, the clone is marked out of
  sync and should not be used.
 
  If fixfdmn cannot recover the metadata for a specific file, the file may be
  truncated, moved, or deleted depending on the situation.  The fixfdmn util-
  ity will attempt to save as much of a file as possible.
 
  Every page fixfdmn changes will be saved to an undo file. If the user does
  not like the results of running fixfdmn, the user can undo the changes by
  running fixfdmn again with the -u option. If the file system containing the
  undo files runs out of space during the fixfdmn run, the user will be
  prompted on how to proceed. The user will  have the option to continue
  without the undo files, to continue adding more space to the domain
  containing the undo files, or to exit.
 
  Use the -m type option when you have information from a system/domain panic
  or output from verify or other tools which indicate where the corruption
  may be. This option limits the scope of what is checked and repaired.
 
NOTES
 
  The fixfdmn command will always clear the transaction log, even on a non-
  corrupt domain unless the -n option is specified
 
  There must be a domain entry for this domain in /etc/fdmns. The fixfdmn
  command opens the block devices specified for the volumes in /etc/fdmns.
 
  If you need to repair the root domain, you must boot from CD-ROM and create
  the entry for the root domain under /etc/fdmns.
 
RESTRICTIONS
 
  You must be root to run fixfdmn.
 
  The fixfdmn command requires that the domain specified will have no
  filesets mounted.
 
  Although fixfdmn may report success, it does not guarantee that all corrup-
  tions have been eliminated.
 
  If a domain is mounted and written to after being repaired by fixfdmn,
  using the fixfdmnutility with the -u option will likely cause corruptions.
 
EXIT STATUS
 
  0 (Zero)
      Success.
 
  1 Corrupt
      Unable to repair all found corruptions
 
  2 Failure
      Program or system error
 
FILES
 
  /etc/fdmns
      Contains AdvFS domain directories and locks.
 
SEE ALSO
 
  Commands: salvage(8), umount(8), verify(8), vrestore(8)

1.9    Release Note for Tru64 UNIX Patch 509.00

This patch provides the X server support for a new graphics card. In order to obtain full support for this graphic card, you must also select Patch 647.00, which is the driver portion of the patch.

A list of supported platforms is available on the following web page:

http://www.compaq.com/alphaserver/products/options.html

1.10    Release Note for Tru64 UNIX Patch 391.00

This patch contains a solution for the following issue:

Compaq has advised owners of DS10, DS10L, ES40 AlphaServers, and XP900 AlphaStations that Compaq has determined in laboratory testing that there is a theoretical possibility that during read and write operations to the floppy disk on these systems, a single byte of data may be inaccurately read or written without notice to the user or system. The potential for this anomaly exists only if floppy disk read or write operations are attempted while there is extremely heavy traffic on these Alpha systems' internal input/output busses.

Although Compaq has observed the anomaly only in laboratory tests designed to create atypical system stresses, including almost constant use of the floppy disk drive, Compaq has informed owners of the remote possibility that the anomaly could occur so that they may take precautions to prevent it.

Compaq recommends that the solution be installed by all DS10, DS10L, ES40 AlphaServers, and XP900 AlphaStation customers.

The solution to this issue is also available as an individual, manually installed patch kit named floppy_CSP_v51.tar.gz, available from:

http://ftp1.support.compaq.com/public/unix/v5.1

1.11    Release Note for TruCluster Patch 82.00

This patch fixes a problem that can occur when an application does a direct I/O write (an AdvFS file was opened with the O_DIRECTIO flag) or when an application performs asynchronous Direct I/Os to files using the aio_raw library, and the target file resides on a fileset that has been cloned.

This patch uses the rolling upgrade version switch to ensure that all members of the cluster have installed the patch before it is enabled.

Prior to throwing the version switch, you can remove this patch by returning to the rolling upgrade install stage, rerunning dupatch, and selecting the Patch Deletion item in the Main Menu.

You can remove this patch after the version switch is thrown, but this requires a shutdown of the entire cluster.

To remove this patch after the version switch is thrown, use the following procedure:

Note:

Use this procedure only under the following conditions:

  1. Run the /usr/sbin/clone_versw_undo command.

    When this command completes, it asks whether it should shut down the entire cluster now. The patch removal process is not complete until after the cluster has been shut down and restarted.

    If you do not shut down the cluster at this time, you will not be able to shut down and reboot an individual member until the entire cluster has been shut down.

  2. After cluster shutdown, boot the cluster to multi-user mode.

  3. Rerun the rolling upgrade procedure from the beginning (starting with the setup stage). When you rerun dupatch, select the Patch Deletion item in the Main Menu.

For more information about rolling upgrades and removing patches, see the Patch Kit Installation Instructions.

1.12    Release Note for TruCluster Server Software

During the switch stage of a rolling upgrade from TruCluster Server Version 5.1 to TruCluster 5.1 Patch Kit-0003, you may see the following message:

Initiating version switch on cluster members
.Switch already switched

You can safely ignore this message. The switch stage will complete successfully.

1.13    Release Note for Misleading Error Messages

The release note explains misleading error messages you may see while deleting patches in a cluster.

There is a bug in the current version of the patch tools where messages similar to the following may be observed:

- Tru64_UNIX_V5.1A / X11 Patches:
        Patch 00057.00 - Fix for X server
hang                                  
 
can only be deleted by using the Tru64 UNIX Patch Utility 
(/usr/sbin/dupatch).
-------------------------------------------------------------------------
setld: OSFPAT00005700520 scp failed on member63.

These messages are misleading and can be ignored since they originate while running the Tru64 UNIX dupatch Utility tool.

1.14    Release Note for Broken Link Problem

When performing a baseline analysis with the dupatch utility on Tru64 UNIX 5.1 systems, the baseline error log files may report that a number of files have broken hard links to the /usr/share/man/man3 directory.

The presence of these broken links will not affect your system operation, the installation of dupatch or dupatch tools, the successful installation of patches, or the rebuilding of kernels on the system. The problem will be addressed in a future version of the operating system.

You can determine if these broken links exist on your system by performing the following steps:

  1. Change directories as follows:

    # cd /usr/share/man/man3
    

  2. Check to see that the inodes are the same for all the files:

    # ls -il slk*.3.gz curs_slk.3.gz
    

An example of a correct hard link would look as follows. Note the same inodes.

14648 -rw-r--r--  17 root     system      2086 Mar  9  2000 curs_slk.3.gz
14648 -rw-r--r--  17 root     system      2086 Mar  9  2000 slk_attr_off.3.gz
14648 -rw-r--r--  17 root     system      2086 Mar  9  2000 slk_attr_on.3.gz
14648 -rw-r--r--  17 root     system      2086 Mar  9  2000 slk_attr_set.3.gz
14648 -rw-r--r--  17 root     system      2086 Mar  9  2000 slk_attroff.3.gz
14648 -rw-r--r--  17 root     system      2086 Mar  9  2000 slk_attron.3.gz
14648 -rw-r--r--  17 root     system      2086 Mar  9  2000 slk_attrset.3.gz
14648 -rw-r--r--  17 root     system      2086 Mar  9  2000 slk_clear.3.gz
14648 -rw-r--r--  17 root     system      2086 Mar  9  2000 slk_color.3.gz
14648 -rw-r--r--  17 root     system      2086 Mar  9  2000 slk_init.3.gz
14648 -rw-r--r--  17 root     system      2086 Mar  9  2000 slk_label.3.gz
14648 -rw-r--r--  17 root     system      2086 Mar  9  2000 slk_noutrefresh.3.gz
14648 -rw-r--r--  17 root     system      2086 Mar  9  2000 slk_refresh.3.gz
14648 -rw-r--r--  17 root     system      2086 Mar  9  2000 slk_restore.3.gz
14648 -rw-r--r--  17 root     system      2086 Mar  9  2000 slk_set.3.gz
14648 -rw-r--r--  17 root     system      2086 Mar  9  2000 slk_touch.3.gz
14648 -rw-r--r--  17 root     system      2086 Mar  9  2000 slk_wset.3.gz
 
 

An example of an incorrect hardlink would look as follows. Note the different inodes.

54891 -rw-r--r--   2 root     system      2086 Aug 11 17:32 curs_slk.3.gz
54891 -rw-r--r--   2 root     system      2086 Aug 11 17:32 slk_attr_off.3.gz
55583 -rw-r--r--  15 root     system      2086 Aug 11 17:32 slk_attr_on.3.gz
55583 -rw-r--r--  15 root     system      2086 Aug 11 17:32 slk_attr_set.3.gz
55583 -rw-r--r--  15 root     system      2086 Aug 11 17:32 slk_attroff.3.gz
55583 -rw-r--r--  15 root     system      2086 Aug 11 17:32 slk_attron.3.gz
55583 -rw-r--r--  15 root     system      2086 Aug 11 17:32 slk_attrset.3.gz
55583 -rw-r--r--  15 root     system      2086 Aug 11 17:32 slk_clear.3.gz
55583 -rw-r--r--  15 root     system      2086 Aug 11 17:32 slk_color.3.gz
55583 -rw-r--r--  15 root     system      2086 Aug 11 17:32 slk_init.3.gz
55583 -rw-r--r--  15 root     system      2086 Aug 11 17:32 slk_label.3.gz
55583 -rw-r--r--  15 root     system      2086 Aug 11 17:32 slk_noutrefresh.3.gz
55583 -rw-r--r--  15 root     system      2086 Aug 11 17:32 slk_refresh.3.gz
55583 -rw-r--r--  15 root     system      2086 Aug 11 17:32 slk_restore.3.gz
55583 -rw-r--r--  15 root     system      2086 Aug 11 17:32  slk_set.3.gz
55583 -rw-r--r--  15 root     system      2086 Aug 11 17:32 slk_touch.3.gz
55583 -rw-r--r--  15 root     system      2086 Aug 11 17:32 slk_wset.3.gz
 
 

1.15    Release Note for Potential Rolling Upgrade Problem

When patching a clustered Tru64 UNIX 5.1 system using the rolling upgrade procedure, the operation may fail if your system has been upgraded from a patched Tru64 UNIX 5.0A version.

In such cases, the lead member is successfully patched, but the patching operation fails for subsequent members. The problem occurs because the file var/adm/patch/roll/installed_patches contains the old OSFPAT*505 entries, which no longer exist in ./usr/.smdb. As a result, the rolling upgrade generates error messages such as the following when subsequent members are rolled:

Backing up member-specific data for member: 2
 .......
 grep: can't open ./usr/.smdb./OSFPAT00018600505.inv
 grep: can't open ./usr/.smdb./OSFPAT00019200505.inv
 grep: can't open ./usr/.smdb./OSFPAT00020500505.inv
 grep: can't open ./usr/.smdb./OSFPAT00021100505.inv
 grep: can't open ./usr/.smdb./OSFPAT00016500505.inv
 grep: can't open ./usr/.smdb./OSFPAT00020000505.inv
 
 

The following procedures describe how to solve the problem if you discover it during a rolling upgrade or if you have not yet begun the rolling upgrade.

Rolling Upgrade Started

Perform the following steps if you issued the clu_upgrade command and discovered the error during the roll of the second member (designated here as member 2):

  1. Halt the failing member:

    # halt
    

  2. On the lead member, undo the roll:

    # clu_upgrade undo roll 2
    

  3. Remove the old OSFPAT*505 entries from /var/adm/patch/roll/installed_patches. Because this is a cluster-common file, you need only do this once. The remaining members can be rolled as documented in the Patch Kit Installation Instructions.

    1. Change to the /var/adm/patch/roll directory:

      # cd /var/adm/patch/roll
      

    2. Invoke an editor such as vi and remove any lines that contain the string OSFPAT*505 from the file installed_patches:

      # vi ./installed_patches
      

  4. Boot member 2 to multiuser mode and then shut down to single-user mode:

    >>> boot
     
    # shutdown now
    

  5. Roll member 2:

    # bckeckrc
     
    # clu_upgrade roll
    

  6. Complete the procedure as documented in the Patch Kit Installation Instructions.

Rolling Upgrade Not Started

Perform the following steps if you have not started a rolling upgrade:

  1. Rename the installed_patches file and re-create it.

    # cd /var/adm/patch/roll/ 
    # mv ./installed_patches ./installed_patches.V50A
    # touch ./installed_patches
    

  2. Complete the procedure as documented in the Patch Kit Installation Instructions.

For information on patching your clustered system using the rolling upgrade procedure, see the Patch Kit Installation Instructions and the clu_upgrade(8) reference page.

1.16    Release Note for Tru64 UNIX Patch 169.00

In cases where the bttape or btcreate command is used to back up and restore UFS file systems, btextract leaves behind a symboltable file in the restored file system. This file, if present, will cause btextract to hang the next time a bootable tape is created using btcreate or bttape. The btextract command hangs while trying to restore the UFS file system.

To work around this problem, ensure that the file restoresymtab? (where ? refers to the cluster member ID, 0 by default) is removed. Every UFS file system that was restored using btextract will have this file, and this file needs to be removed on each file system before running the bttape or btcreate command the next time. For example, if / and /usr are backed up, then the file will be found at /restoresymtable0 and /usr/restoresymtable0, and both instances of the file need to be removed before proceeding with btcreate or bttape.

1.17    Release Note for Tru64 UNIX Patch 270.00

This patch fixes a security vulnerability (called the Brown Orifice) in Netscape Communicator Version 4.72 by updating Netscape Communicator to Version 4.75.

To determine which version of Netscape Communicator you are running, click on the Help button in the toolbar at the top of the Navigator component window, then choose the About Communicator option from the drop down menu.

You can download the latest version of Netscape Communicator for Tru64 UNIX from the Netscape Download World Wide Web site:

http://home.netscape.com/download/index.html

Or, from the Compaq Tru64 UNIX World Wide Web site:

http://www.tru64unix.compaq.com/internet/download.htm

If you are unable to upgrade to Netscape Communicator 4.75 or later, you can avoid this security vulnerability by disabling the browser's ability to run Java by following these steps:

  1. Start Netscape Communicator:

    $/usr/bin/X11/netscape

  2. Click on the Edit button in the toolbar at the top of the Navigator component window.

  3. Click on the Preferences... option on the drop down menu that appears when the Edit button is selected. This displays the Netscape: Preferences dialog box.

  4. In the window pane on the left of the Netscape: Preferences dialog box, click on the Advanced tab. This displays the advanced Communicator preferences in the dialog box.

  5. If the box next to the Enable Java preference has a check mark in it, click on the box to remove the check mark. This will disable the Java programming language. Then, click on the Okay button in the Advanced preferences dialog box. (If there is no check mark in the box, you do not need to take any action.)

  6. Exit Netscape Communicator by clicking on the Exit option in the drop down menu that appears when you click on the File button on the toolbar at the top of the Navigator window.

Disabling Java ensures Netscape Communicator is not vulnerable to the Brown Orifice vulnerability. You do not have to disable JavaScript.

Note

If you use the Japanese or Chinese interfaces provided in the Worldwide Language Support software, you must update the Communicator version numbers in the /usr/lib/X11/*/app-defaults/Netscape file if you choose to upgrade to Netscape Communicator Version 4.75 or later.

If the version numbers in these files do not match the version of Netscape Communicator installed, it will not run in the Japanese or Chinese locales.

You can download the updated files from the Compaq Tru64 UNIX World Wide Web site:

http://www.tru64unix.compaq.com/internet/download.htm