All;
My original question:
We're attempting to upgrade an 8400 5/440 (6 cpu's, 10G RAM) from DU 4.0b
Patch level 7 to 4.0d and we're getting the following error message:
./sys should be symbolic link to usr/sys
Shortly after firing up installupdate. Specifically, the log looks as follows:
snip.
The definitive answer came from Tom Reu (tcr_at_unx.dec.com) of the Compaq
Tru64 UNIX Installation Team. Tom said:
>Looking at the message "./sys should be symbolic link to
>usr/sys", it means that some inventory file for 4.0B is claiming that
>./sys should be a sym link. We have checked the 4.0B and 4.0D official
>inventory files and they both ship ./sys as a directory. Our guess is
>that the patch kit ships it as a sym link or that someone has modified
>the base OS inventory file (OSFBASE410.inv).
>
>Here is what you should do:
>
>
>1). Check the inventory files to see what inventory record is shipping
>./sys as a sym link:
>
> cd /usr/.smdb.
> cat *.inv | grep "[[:space:]]./sys[[:space:]]"
>
>2). There should only be one record (OSFBASE4??) that appears and the
>record should have a "d" in the 9th field, "./sys" in the 10th field
>and "none" in the 11th field.
>
>3). If there is more than one record, the user should verify that
>./sys is indeed a directory and then remove all records but the one in
>the OSFBASE4??.inv file.
We did the cat | grep of all the "inv" files in /usr/.smdb. and found an
OSFBINCOM350.inv file that referenced ./sys as a symbolic link to /usr/sys
(in addition to the correct definition in OSFBASE410.inv) Where the
OSFBINCOM350 file came from is still under investigation.
We moved our "clone" of our production system to a test 2100 we have, made
the appropriate changes in /etc, /dev etc on the 2100 and booted the clone
up under genvmunix. We then fired up installupdate, re-produced the
problem, exited installupdate, deleted the OSFBINCOM350* files, restarted
installupdate and have successfully made it past the error and are now
loading subsets.
Other respondents were:
Joe Fletcher <joe_at_meng.ucl.ac.uk>
Dr. Tom Blinn <tpb_at_doctor.zk3.dec.com>
Alan Davis <Davis_at_Tessco.Com>
Whose responses were along the same lines as Tom's in that there was likely
something wrong with one of the inventory files.
Alan Davis <Davis_at_Tessco.Com> added:
>You may use the /usr/lbin/fverify command to validate the paths
>to all standard OS files and directories. If you have installed
>patches on the system, fverify will return verification errors
>on any file updated by a patch. Compaq Services Unix Expert
>Team can provide a program which will validate files on a patched
>system taking into account the patch updates without spurious
>error reports. The program is called "allverify.tcl".
Many thanks to all who responded.
David
mailto:sxdjd_at_ts.sois.alaska.edu
Received on Tue Feb 09 1999 - 19:48:39 NZDT