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

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 921.01

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    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 921.01 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.5    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 777.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.6    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 Ethernet device..

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

This release note contains a new reference page 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 777.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 921.01, 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 Tru64 UNIX Patch 921.01

1.11.1    TMPDIR Environment Variable

If the TMPDIR environment variable is not defined, then sys_check -escalate will always put the escalate.tar files in /var/tmp even if you specify an alternate directory. To work around this problem, you must first set and export the TMPDIR environment variable to the directory where you want sys_check to put the escalate.tar files. For example, if you want sys_check to put the escalate.tar files in /var/adm, then you must execute the following commands before running sys_check -escalate: 

# ksh  
# export TMPDIR=/var/adm  
# sys_check -escalate

1.11.2    sys_check Version

The following information is for users who have installed the sys_check version 125 web kit or higher and are currently using the version of sys_check in the web kit as the system default version.

This patch kit contains sys_check version 124. If you have already installed the sys_check version 125 web kit or higher, then installing this patch kit will downgrade the version of sys_check that is being used by the system. However, you can set the system default back to the version of sys_check that you downloaded from the web by using the /usr/sbin/use_sys_check script. For example, type use_sys_check 125 at the command line prompt to set sys_check version 125 as the system default.

If you wish to delete the sys_check patch (that is, sys_check version 124), then you should make sure that version 124 is the system default version before deleting the patch. You can verify this by examining the output of the sys_check -v command. If 124.0 is not the default version, then you should run the /usr/sbin/use_sys_check 124 command to set the system default version of sys_check to version 124. Setting the system default to 124 ensures that the version 124 sys_check files get removed when the patch is deleted. After you delete the patch, 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 is installed and will restore these symbolic links when the patch is deleted.

If you delete the patch and the system default version is not set to 124, then version 124 will remain on the system because sys_check version 124 has been backed up by the web kit (for example, /usr/sbin/sys_check.124.0).

You will encounter problems if you delete the sys_check web kit and then delete this patch kit. This is 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 non-existent files. You can fix this problem by re-installing the sys_check web kit.

1.12    Reference Page Information for Tru64 UNIX Patch 921.01

This release note contains reference page information for sys_check(8).

sys_check(8)                                                     sys_check(8)
NAME
 
  sys_check, runsyscheck - Generates system configuration information and
  analysis
 
SYNOPSIS
 
  /usr/sbin/sys_check [options...]
 
OPTIONS
 
  -all
      Lists all subsystems, including security information and setld inven-
      tory verification.  This option may take a long time to complete.
 
  -debug
      Outputs debugging information to stderr (standard error output).
 
  -escalate [ xx ]
      Creates escalation files for reporting problems to your technical sup-
      port representative. This option produces one file,
      TMPDIR/escalate.tar unless there are crash dump files; if so,
      it also creates two other files: TMPDIR/escalate_vmunix.xx.gz
      and TMPDIR/escalate_vmcore.xx.gz. If you use the -escalate
      option, sys_check runs with the -noquick option and collects the output
      in the escalate.tar file. Optionally, you can specify a number (xx)
      with the -escalate option to define a crash number.
 
      See also the ENVIRONMENT VARIABLES section for information on how you
      can set the value of TMPDIR.
 
  -evm
      Generates Event Manager (EVM) warnings. When EVM is configured, warn-
      ings are posted as EVM events identified by the string
      sys.unix.sys_check.warning. Six levels of priority ranging from 0-500
      are used, as follows:
 
        +  0 - Information only.
 
        +  100 - Note
 
        +  200 - Tuning Note
 
        +  300 - Tuning Suggestion
 
        +  400 - Operational        
 
    +  500 - Warning
 
  -frame
      Produces frame HTML output, which consists of three files:
      sys_checkfr.html, sys_checktoc.html, and sys_check.html (unless you
      specify a different file name with the -name option).  This option
      cannot be used with the -nohtml option. The following options are
      available for use with the -frame option:
 
      -name name
          Specifies the name to use for the frame files output.  The default
          name is sys_check.
 
      -dir name
          Sets the directory for the frames output.  Used only with the
          -frame option.  The default is the current directory (.).
 
  -help or (-h)
      Outputs help information.
 
  -nohtml
      Produces text output, consisting of one text file, instead of the
      default HTML output. This option cannot be used with the -frame option.
 
  -noquick
      Outputs configuration data and the setld scan.  Excludes security
      information.
 
  -perf
      Outputs only performance data and excludes configuration data. This
      option takes less time to run than others.
 
  -v  Displays the sys_check version number.
 
  -warn
      Executes only the warning pass. This option takes less time to run than
      other options.
 
  -nowarn
      Executes only the data gathering pass.
 
DESCRIPTION
 
  The sys_check utility is a system census and configuration verification
  tool that is also used to aid in diagnosing system errors and problems. Use
  sys_check to create an HTML report of your system's configuration (software
  and hardware). The size of the HTML output that is produced by the
  sys_check utility is usually between .5 MB and 3 MB.
 
  The sys_check utility also performs an analysis of operating system parame-
  ters and attributes such as those that tune the performance of the system.
  The report generated by sys_check provides warnings if it detects problems
  with any current settings. Note that while sys_check can generate hundreds
  of useful warnings, it is not a complete and definitive check of the health
  of your system. The sys_check utility should be used in conjunction with
  event management and system monitoring tools to provide a complete overview
  and control of system status. Refer to the EVM(5) reference page for infor-
  mation on event management. Refer to the System Administration guide for
  information on monitoring your system.
 
  When used as a component of fault diagnosis, sys_check can reduce system
  down time by as much as 50% by providing fast access to critical system
  data. It is recommended that you run a full check at least once a week to
  maintain the currency of system data. However, note that some options will
  take a long time to run and can have an impact on system performance.  You
  should therefore choose your options carefully and run them during off-peak
  hours. As a minimum, perform at least one full run (all data and warnings)
  as a post-configuration task in order to identify configuration problems
  and establish a configuration baseline. The following table provides guide-
  lines for balancing data needs with performance impact.
 
  ___________________________________________________________________________
  Option              Run time                        Performance         Recommended At
                            impact
  ___________________________________________________________________________
  -warn, -perf        Short.                           Minimal.                 Regular
                                                                                                     updates, at
                                                                                                     least weekly
  null - no 
 options              Medium, perhaps     Some likely at           Run at least
 selected.           15 to 45 minutes        peak system use.    once post-
                            depending on pro-                                      installation
                            cessor.                                                          and update
                                                                                                   after major
                                                                                                   configuration
                                                                                                   changes. Update
                                                                                                   your initial
                                                                                                   baseline and
                                                                                                   check warnings
                                                                                                   regularly.
  -noquick
, -all,                   Long, perhaps 45    Very likely at           Use only when
  -escalate.        minutes on fast,        peak use.                  troubleshooting
                           large systems to                                         a system prob-
                           hours on low-end                                       lem or escalat-
                          systems.                                                         ing a problem
                                                                                                  to your techni-
                                                                                                  cal support
                                                                                                  representative.
  ___________________________________________________________________________
 
  You can run some sys_check options from the SysMan Menu or the
  /usr/sbin/sysman -cli command-line interface. Choose one of the following
  options from the Menu:
 
       >- Support and Services
           | Create escalation report [escalation]
           | Create configuration report [config_report]
 
  Alternatively, use the config_report and escalation accelerators from the
  command line. Note that the escalation option should only be used in con-
  junction with a technical support request.
 
  The runsyscheck script will run sys_check as a cron task automatically if
  you do not disable the crontab entry in /var/spool/cron/crontabs/root.
  Check for the presence of an automatically generated log file before you
  create a new log, as it may save time.
 
  When you run the sys_check utility without command options, it gathers con-
  figuration data excluding the setld scan and the security information and
  displays the configuration and performance data by default. It is recom-
  mended that you do this at least once soon after initial system configura-
  tion to create a baseline of system configuration, and to consider perform-
  ing any tuning recommendations.
 
  On the first run, the sys_check utility creates a directory named
  /var/recovery/sys_check. On subsequent runs, sys_check creates additional
  directories with a sequential numbering scheme:
 
    +  The previous sys_check directory is renamed to
       /var/recovery/sys_check.0 while the most recent data (that is, from
       the current run) is always maintained         in
       /var/recovery/sys_check.
 
    +  Previous sys_check directories are renamed with an incrementing exten-
       sion; /var/recovery/sys_check.0 becomes /var/recovery/sys_check.1, and
       so on, up to /var/recovery/sys_check.5.
  There is a maximum of seven directories. This feature ensures that you 
  always have up to seven sets of data automatically. Note that if you only
  perform a full run once, you may want to save the contents of that direc-
  tory to a different location.
 
  Depending on what options you choose, the /var/recovery/sys_check.* 
  directories will contain the following data:
 
    +  Catastrophic recovery data, such as an etcfiles directory, containing
       copies of important system files. In this directory, you will find
       copies of files such as /etc/group, /etc/passwd, and /etc/fstab.
 
    +  Formatted stanza files and shell scripts and that you can optionally
       use to implement any configuration and tuning recommendations gen-
       erated by asys_check run. You use the sysconfigdb command or run the
       shell scripts to implement the stanza files. See the sysconfigdb(8)
       reference page for more information.
 
NOTES
 
  You must be root to invoke the sys_check utility from the command line;
  you must be root or have the appropriate privileges through Division of
  Privileges (DoP) to run Create Configuration Report and Create Escalation
  Report from the SysMan Menu. The sys_check utility does not change any sys-
  tem files.
 
  The sys_check utility is updated regularly. You can obtain the latest ver-
  sion of the sys_check utility from either of two sources:
 
    +  The most up-to-date version of the sys_check kit is located on the
       sys_check tool web site,
       http://www.tru64unix.compaq.com/sys_check/sys_check.html
 
    +  You can also obtain sys_check from the patch kit, see
       http://www.support.compaq.com/patches/.
 
  You should run only one instance of sys_check at a time. The sys_check
  utility prevents the running of multiple instances of itself, provided that
  the value of the TMPDIR environment variable is /var/tmp, /usr/tmp, /tmp,
  or a common user-defined directory.  This avoids possible collisions when
  an administrator attempts to run sys_check while another administrator is
  already running it. However, no guarantees can be made for the case when
  two administrators set their TMPDIR environment variables to two different
  user-defined directories (this presumes that one administrator does not
  choose /var/tmp, /usr/tmp, or /tmp).
 
  The sys_check utility does not perform a total system analysis, but it does
  check for the most common system configuration and operational problems on
  production systems.
 
  Although the sys_check utility gathers firmware and hardware device revi-
  sion information, it does not validate this data.  This must be done by
  qualified support personnel.
 
  The sys_check utility uses other system tools to gather an analyze data. At
  present, sys_check prefers to use DECevent and you should install and con-
  figure DECevent for best results.
 
  If DECevent is not present, the sys_check utility issues a warning message
  as a priority 500 EVM event and attempts to use uerf instead. In future
  releases, Compaq Analyze will also be supported on certain processors.
 
  Note that there are restrictions on using uerf, DECevent and Compaq Analyze
  that apply to:
 
    +  The version of UNIX that you are currently using.
 
    +  The installed version of sys_check.
 
    +  The type of processor.
 
EXIT STATUS
 
  The following exit values are returned:
 
  0   Successful completion.
 
  >0  An error occurred.
 
LIMITATIONS
 
  DECevent or Compaq Analyze may not be able to read the binary error log
  file if old versions of DECevent are being used  or if the binary.errlog
  file is corrupted.  If this problem occurs, install a recent version of
  DECevent and, if corrupted, recreate the binary.errlog file.
 
  HSZ controller-specific limitations include the following:
 
  HSZ40 and HSZ50 controllers:
      The sys_check utility uses a free LUN on each target in order to com-
      municate with HSZ40 and HSZ50 controllers. To avoid data gathering
      irregularities, always leave LUN 7 free on each HSZ SCSI target for
      HSZ40 and HSZ50 controllers.
 
  HSZ70, HSZ80 and G80 controllers:
      The sys_check utility uses a CCL port in order to communicate with
      HSZ70 controllers. If a CCL port is not available, sys_check will use
      an active LUN.  To avoid data gathering irregularities, enable the CCL
      port for each HSZ70 controller.
 
  HSV controller-specific limitations include the following:
 
      The sys_check utility uses the SANscript utility (sssu) to collect data
      from an Enterprise controller. This utility is included with the
      Enterprise Platform Kit; verify that this utility is installed in
      /usr/lbin and ensure that it has execute permissions.
 
      The sys_check utility cannot dynamically determine the SAN appliance or
      appliances used to manage your Enterprise storage. To do so, create the
      file /etc/enterprise.txt with the element name, the user name, and the
      password (separated by colons) of the SAN appliance as shown below;
      these values may contain embedded spaces. Set the permissions of this
      file to 600.
           element:user:password
           element 1:user 1:password
 
  The sys_check utility attempts to check the NetWorker backup schedule
  against the /etc/fstab file.  For some older versions of Networker, the
  nsradmin command contains a bug that prevents sys_check from correctly
  checking the schedule.  In addition, the sys_check utility will not
  correctly validate the NetWorker backup schedule for TruCluster services.
 
EXAMPLES
 
   1.  The following command creates escalation files that are used to report
       problems to your technical support organization:
            # sys_check -escalate
 
   2.  The following command outputs configuration and performance informa-
       tion, excluding security information and the setld inventory, and pro-
       vides an analysis of common system configuration and operational prob-
       lems:
            # sys_check > file.html
 
   3.  The following command outputs all information, including configura-
       tion, performance, and security information and a setld inventory of
       the system:
            # sys_check -all > file.html
 
   4.  The following command outputs only performance information:
            # sys_check -perf > file.html
 
   5.  The following command provides HTML output with frames, including con-
       figuration and performance information and the setld inventory of the
       system:
            # sys_check -frame -noquick
 
   6.  The following command starts the SysMan Menu config_report task from
       the command line:
            # /usr/sbin/sysman config_report
 
       Entering this command invokes the SysMan Menu, which prompts you to
       supply the following optional information:
 
         +  Save to (HTML) - A location to which the HTML report should be
            saved, which is /var/adm/hostname_date.html by default.
 
         +  Export to Web (Default) - Export the HTML report to Insight
            Manager. Refer to the System Administration for information on
            Insight Manager.
 
         +  Advanced options - This option displays another screen in which
            you can choose a limited number of run time options. The options
            are equivalent to certain command line options listed in the
            OPTIONS section.
 
            In this screen, you can also specify an alternate temporary
            directory other than the default of /var/tmp.
 
         +  Log file - The location of the log file, which is
            /var/adm/hostname_date.log by default.
 
   7.  The following is an example of a stanza file advfs.stanza in
       /var/recovery/sys_check.*:
            advfs:
            AdvfsCacheMaxPercent=8
 
   8.  The following is an example of a shell script apply.kshin
       /var/recovery/sys_check.*:
            cd /var/cluster/members/member/recovery/sys_check/
            llist="advfs.stanza
            vfs.stanza "
            for stf in $llist; do
            print " $stf "
                    stanza=`print $stf | awk -F . '{print $1 }'`
            print "/sbin/sysconfigdb -m -f $stf $stanza"
                    /sbin/sysconfigdb -m -f $stf $stanza
            done
            print "The system may need to be rebooted for these
            changes to take effect"
 
ENVIRONMENT VARIABLES
 
  The following environment variables affect the execution of the sys_check
  utility. Normally, you only change these variables under the direction of
  your technical support representative, as part of a fault diagnosis pro-
  cedure.
 
  TMPDIR
      Specifies a default parent directory for the sys_check working sub-
      directory, whose name is randomly created; this working subdirectory is
      removed when sys_check exits. The default value for TMPDIR is /var/tmp.
 
  LOGLINES
      Specifies the number of lines of log file text that sys_check includes
      in the HTML output.  The default is 500 lines.
 
  BIGNUMFILE
      Specifies the number of files in a directory, above which a directory
      is considered excessively large.  The default is 15 files.
 
  BIGFILE
      Specifies the file size, above which a file is considered excessively
      large. The default is 3072 KB.
 
  VARSIZE
      Specifies the minimum amount of free space that sys_check requires in
      the TMPDIR directory.  The default is 15 MB and should not be reduced.
      The sys_check utility will not run if there is insufficient disk space.
 
  RECOVERY_DIR
      Specifies the location for the sys_check recovery data.  The default is
      /var/recovery.  The sys_check utility automatically cleans up data from
      previous command runs.  The typical size of the output generated by
      each sys_check utility run is 400 KB.  This data may be useful in
      recovering from a catastrophic system failure.
 
  ADHOC_DIR
      Specifies the location at which sys_check expects to find the text
      files to include in the HTML output.  The default is the /var/adhoc
      directory.
 
  TOOLS_DIR
      Specifies the location at which sys_check expects to find the binaries
      for the tools that it calls.  The default is /usr/lbin.
 
FILES
 
  /usr/sbin/sys_check
      Specifies the command path.
 
                                       Note
 
         This file may be a symbolic link.
 
  /usr/lbin/*
      Various utilities in this directory are used by sys_check.
 
                                       Note
 
         These files may be symbolic links.
 
  The sys_check utility reads many system files.
 
SEE ALSO
 
  Commands: dop(8), sysconfigdb(8), sysman_cli(8), sysman_menu(8)
 
  Miscellaneous: EVM(5), insight_manager(5)
 
  Books: System Administration, System Tuning

1.13    Release Note for Tru64 UNIX Patch 921.01

This section describes changes to Patch 921.01.

Updated sh, csh, and ksh

The updated shells in this kit all implement the following changes when processing shell inline input files:

sh noclobber option and >| , >>| constructs Added

A -noclobber option similar to that already available with csh and ksh has been added to the Bourne shell.

When the noclobber option is used (set -C), the shell behavior for the redirection operators > and >> changes as follows:

ksh noclobber Behavior Clarified

For > with noclobber set, ksh returns an error rather than overwrite an existing file. If the file name is actually a symlink, the presence of the symlink satisfies the criteria file exists whether or not the symlink target exists, and ksh returns an error. The >| construct will suppress these checks and create the file.

For >> with noclobber set, output is appended to the tail of an existing file. If the file name is actually a symlink to a non-existent file, ksh returns an error.

csh noclobber Behavior Clarified

For > with noclobber set, csh returns an error rather than overwrite an existing file. If the file name is actually a symlink, the presence of the symlink satisfies the criteria file exists whether or not the symlink target exists, and csh returns an error. The >!construct will suppress these checks and create the file.

For >> with noclobber set, output is appended to the tail of an existing file. If the filename is actually a symlink to a non-existent file, csh returns an error. The >>! construct will suppress these checks and create the file.

Updated mkdir System Call and Command

This kit reverts the mkdir system call, and thus the mkdir command, to its Tru64 UNIX V4.n behavior with respect to symlinks. For the unusual case where a symlink is used as the very last elment of a mkdir path, the mkdir system call nows returns an erro rrather than create the target.

If you want mkdir to follow the symlink, you can do this by making the last character of the mkdir pathname a slash. The following text describes how to get mkdir to follow the symlink.

If /var/tmp/foo is a symlink to /usr/xxx, which does not exist, then mkdir("/var/tmp/foo",0644) will return an error but mkdir("var/tmp/foo/",0644) will create /usr/xxx.

The behavior of mkdir can also be controlled system wide by an addition to the sysconfig options for the vfs subsystem. The new sysconfig option -follow_mkdir_symlinks defaults to 0, specifying the secure symlink behavior. Changing this option to 1, which Compaq strongly discourages, will cause mkdir to follow symlinks.

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

1.18    Release Note for Tru64 UNIX Patch 387.00

This patch modifies the fverify application so that it can fix files which were erroneously installed onto the system with the date of 12/31/69. This was due to a problem in the Compact Disk File System (CDFS) code that caused any file copied onto a system from a CD created in CDFS format after 1/1/2001 to have the erroneous date. The files will be corrected automatically when fverify is invoked by setld(8) during the verification phase of the software installation.

1.19    Release Note Tru64 UNIX Patch 921.01

If you have installed sendmail from the Internet Express (IX) or Open Source Internet Solutions (OSIS) layered products (IAESMTP subset), the mailsetup command from this subset will cause the automated patch update mechanism to fail.

Perform the following steps to fix this problem:

  1. Save the IX version of mailsetup to a temporary file:

    # mv /usr/sbin/mailsetup /usr/sbin/mailsetup.IX

  2. Restore the base operating system mailsetup file:

    # cp -p /usr/sbin/mailsetup.preIAE5.6 /usr/sbin/mailsetup

  3. Run the patch update.

  4. After the patch update has completed, save the updated base operating system file:

    # cp -p /usr/sbin/mailsetup /usr/sbin/mailsetup.preIAE5.6

  5. Then restore the IX mailsetup file:

    # mv /usr/sbin/mailsetup.IX /usr/sbin/mailsetup

1.20    Release Note for Tru64 UNIX Patch 900.00

There was a problem in earlier releases that caused LSM to incorrectly determine the WWID of a disk in a cluster. As a result of that, fixing this problem now means that some disks that were previously identified with an incorrect WWID now may be incorrectly rejected as a clone.

The workaround is to run volrestore after the update installation. This assumes that you have a current volsave data. If you do not have current volsave data then you will need to restart LSM with the prior version of vold (/sbin/vold).

This may require a cluster reboot if all volumes under LSM cannot be closed//unmounted. The older vold should still accept the incorrectly identified disks and you can now run volsave. You can then return to the current vold, reboot if necessary, and then run volrestore to correct the incorrectly identified disks.

Assuming you ran volsave before the upgrade then the procedure is as follows:

  1. Remove all of the invalid disks from LSM control:

    # voldisk rm dskA dskB dskC ...

  2. Run volrestore:

    # volrestore

  3. Manually start all volumes in each of the recovered diskgroups:

    # volume -g DG1 start V1 V2 V3 ...

    # volume -g DG2 start V1 V2 V3 ...

This procedure is only required if the system incorrectly rejects one or more disks as clones. If you do not see this behavior then you do not need to do the volrestore operation.

1.21    Release Note for TruCluster Patch 152.01

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.22    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-0005, 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.23    Release Note for LP9002 Support

If you have installed LP9002 FibreChannel Adapters and have built your system for the first time you need to edit your kernel configuration file in /sys/conf and add the following line to the Static Driver Definitions section: 

#
# Static Driver Definitions
#
 
config_driver emx

When this is done you can install V5.1 Patch Kit-0004 or Patch Kit-0005. When kernel rebuilding has been done your adapters should be recognized by the operating system and should have access to your FibreChannel devices upon system reboot.

If you are installing LP9002 Adapters and have already installed V5.1 Patch Kit-0004 or Patch Kit-0005, halt your system, boot genvmunix and rebuild your kernel using doconfig but replace your existing configuration file. Copy the kernel into place (we recommend that you keep a backup until you have booted the new kernel and things are working as expected) and reboot your system.

1.24    Release Note for Cluster Alias Routing

When you use cluster alias routing make sure that the /proc file is mounted. To verify that the file is mounted, execute the df command, as follows: 

# df /proc

After you execute the df /proc command you will see this output: 

Filesystem   512-blocks        Used   Available Capacity  Mounted on
/proc                 0           0           0   100%    /proc
 
 

If the file is not mounted, then edit the /etc/fstab file as root and add the following entry: 

/proc                      /proc                        procfs rw 0 0
 

Then execute following command as root: 

# mount /proc