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:
To obtain the lastest patch kit for your operating system and cluster:
To view or print the lastest version of the Patch Kit Installation Instructions or the Patch Summary and Release Notes for a specific patch kit:
To visit Compaq's main support page:
To visit the Tru64 UNIX homepage:
The following storage space is required to successfully install this
patch kit:
Base Operating System
Temporary Storage Space
A total of ~250 MB of storage space is required to untar this patch
kit.
Compaq recommends that this kit not be placed in the
/
,
/usr
, or
/var
file systems because doing so may
unduly constrain the available storage space for the patching activity.
Permanent Storage Space
Up to ~80 MB of storage space in
/var/adm/patch/backup
may be required for archived original files if you choose to install and
revert all patches.
See the
Patch Kit Installation Instructions
for more information.
Up to ~82 MB of storage space in
/var/adm/patch
may
be required for original files if you choose to install and revert all patches.
See the
Patch Kit Installation Instructions
for more
information.
Up to ~958 KB of storage space is required in
/var/adm/patch/doc
for patch abstract and README documentation.
A total of ~160 KB of storage space is needed in
/usr/sbin/dupatch
for the patch management utility.
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 theclu_upgrade setup
command.Rolling upgrade disk space requirements are described in Section 7.4.1 of the TruCluster Server Software Installation manual.
Temporary Storage Space
A total of ~250 MB of storage space is required to untar this patch
kit.
Compaq recommends that this kit not be placed in the
/
,
/usr
, or
/var
file systems because doing so may
unduly constrain the available storage space for the patching activity.
Permanent Storage Space
Up to ~56 MB of storage space in
/var/adm/patch/backup
may be required for archived original files if you choose to install and
revert all patches.
See the
Patch Kit Installation Instructions
for more information.
Up to ~57 MB of storage space in
/var/adm/patch
may
be required for original files if you choose to install and revert all patches.
See the
Patch Kit Installation Instructions
for more
information.
Up to ~883 KB of storage space is required in
/var/adm/patch/doc
for patch abstract and README documentation.
A total of ~168 KB of storage space is needed in
/usr/sbin/dupatch
for the patch management utility.
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:
Install the Tru64 UNIX base kit.
Install the TruCluster Server kit.
Install the patch kit before running the
clu_create
command.
In this situation, you must then perform three additional steps:
Run
versw
, the version switch command,
to set the new version identifier:
# /usr/sbin/versw -setnew
Run
versw
to switch to the new version:
# /usr/sbin/versw -switch
Run the
clu_create
command to create your
cluster:
# /usr/sbin/clu_create
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:
An application writes to a file using AdvFS direct I/O and the file had previously been opened for normal I/O (which by default is cached).
Some but not all of the pages are still resident in Unified Buffer Cache (UBC) memory.
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:
Tru64 UNIX V5.0A clustered and nonclustered systems
Tru64 UNIX V5.1 nonclustered systems only
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:
Oracle 8.1.7
Oracle 8.1.6.3
Oracle 8.1.6.2 with patch 1527141
Oracle 8.0.6.2 with patch 1523186
Oracle 7.3.4.5 with patch 1523179
In addition, the AdvFS file system that is used for any of the following Oracle files:
Control file
Data file
Log file
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:
The write spans multiple AdvFS 8K pages.
The last page to be written is in the UBC.
One or more of the preceding pages are not in the UBC.
The write to the last page is less than a full page size (8K).
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:
Set
DUPATCH_SESLOG
to location of session
log, by default:
/var/adm/patch/log/session.log
Get the name of newly-built kernel:
#
NEW_KERNEL=`grep "The new kernel is"
$DUPATCH_SESLOG | awk ' { print $5 }' `
Copy the new kernel:
#
cp <NEW_KERNEL>
/vmunix
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:
Shut down the system:
#
/usr/sbin/shutdown -h now
Boot
genvmunix
to single-user mode:
>>>
boot -fi genvmunix -fl s
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
Run
doconfig
to create a new kernel configuration
file and rebuild the kernel:
#
/usr/sbin/doconfig
Note
Do not specify the
-c
option todoconfig
. If you do,doconfig
will use the existing kernel configuration file which will not have the appropriate controller entry for the new graphics card.
Save the old
/vmunix
file and move the
new kernel to
/vmunix
.
Shut down the system:
#
/usr/sbin/shutdown -h now
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:
Shut down the system:
#
/usr/sbin/shutdown -h now
Boot
genvmunix
to single-user mode:
>>>
boot -fi genvmunix -fl s
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
Run
doconfig
to create a new kernel configuration
file and rebuild the kernel:
#
/usr/sbin/doconfig
Note
Do not specify the
-c
option todoconfig
. If you do,doconfig
will use the existing kernel configuration file which will not have the appropriate controller entry for the new graphics card.
Save the old
/vmunix
file and move the
new kernel to
/vmunix
.
Shut down the system:
#
/usr/sbin/shutdown -h now
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:
There is a minimum of 1.25 -2 times physical memory for swap space available.
All boot and swap devices are properly configured to use one of the four console ports.
The console WWID number for each boot or swap device is identical to the WWID number found via the hwmgr utility using the steps outlined as follows:
Identify the console port(N) and WWID number configuration information using consvar as follows:
consvar -g N1 ; consvar -g N2 consvar -g N3 ; consvar -g N4 consvar -g wwid0 ; consvar -g wwid1 consvar -g wwid2 ; consvar -g wwid3
Find the device name by checking
etc/fstab
,
using
showfdmn
for AdvFS root domains, and
swapon -s
for swap devices for each FibreChannel boot and swap
device.
Find the HWID using the device name obtained in step 2
hwmgr -view dev | grep "device name from step 2 above"
for each FibreChannel boot and swap device.
Find the WWID using the device name obtained in step 3
hwmgr -view dev | grep "device name from step 3 above"
for each FibreChannel boot and swap device.
Verify that the hwmgr WWIDs from step 4 above match the WWIDs from step 1 above for each FibreChannel boot and swap device.
If the WWIDs do not match in step 5 then the system needs to be shut down and reconfigured using the wwidmgr utility as described in the Wwidmgr Users Manual located in the doc directory on the Firmware CDROM until you have verified that the WWID console configuration matches the system hwmgr WWID configuration using the steps described previously.
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:
The rolling upgrade that installed this patch, ncluding the clean stage, has completed.
The version switch has been thrown (clu_upgrade -switch).
A new rolling upgrade is not in progress.
All cluster members are up and in multi-user mode.
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.
After cluster shutdown, boot the cluster to multi-user mode.
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:
Change directories as follows:
# cd /usr/share/man/man3
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):
Halt the failing member:
# halt
On the lead member, undo the roll:
# clu_upgrade undo roll 2
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.
Change to the
/var/adm/patch/roll
directory:
# cd /var/adm/patch/roll
Invoke an editor such as
vi
and remove
any lines that contain the string
OSFPAT*505
from the file
installed_patches
:
# vi ./installed_patches
Boot member 2 to multiuser mode and then shut down to single-user mode:
>>> boot # shutdown now
Roll member 2:
# bckeckrc # clu_upgrade roll
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:
Rename the
installed_patches
file and re-create
it.
# cd /var/adm/patch/roll/ # mv ./installed_patches ./installed_patches.V50A # touch ./installed_patches
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)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:
Start Netscape Communicator:
$/usr/bin/X11/netscape
Click on the Edit button in the toolbar at the top of the Navigator component window.
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.
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.
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.)
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