Hello all;
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:
begin log snippet
Do you want to continue the update installation? (y/n) []: y
****** Checking current state of system
Depending on the system configuration, this may take
up to 10 minutes...
Working....Sun Feb 7 14:54:35 AKST 1999
Working....Sun Feb 7 14:55:05 AKST 1999
----------------------------------------------------------------------
The following directories on this system conflict with assigned file
types originally shipped in the Digital UNIX operating system. This
can be caused, for example, if a symbolic link is replaced with a real
directory.
These conflicts must be resolved before an update installation can be
performed on this system. Additional file status information can be
found in subset inventory files located in the /usr/.smdb. directory.
For later review, this message is also logged in
/var/adm/smlogs/update.log
The update procedure will exit and return the system to its original
state.
./sys should be Symbolic Link to usr/sys
end log snippet
On our 8400, 4100, 2100 (2) and 3000 (2) machines /sys is *not* a link to
usr/sys. sys is a directory within which there are links to /usr/sys. The
compaq analyst also noted that sys was not a link on all the systems he
checked. Those machines are at 4.0d except the 8400 and one of the 3000's
which are both 4.0b. I searched the archives and there is a summary of this
exact problem (during a 3.2->4.0) upgrade located at:
http://www.bucks.edu/~moorem/alpha/Mar1997-47.html
however, there is no real resolution in the summary. It discusses
interrupting upgrades and residual files being left in /usr/.smdb. We did
have to "stop" the first attempt as a DCE subset was installed and it was
necessary to deinstall it and retry the upgrade. It was stopped
"gracefully", by typing "stop" as intructed by installupdate.
The Compaq analyst that we were working with yesterday had us delete 4
files from /usr/.smdb. . Said files were:
OSFPAT00042500410.ctrl
OSFPAT00042500410.inv
OSFPAT00042500410.lk
OSFPAT00042500410.scp
The date/timestamp of a lot of the files in the .smb. directory are from
the exact day/time we upgraded the 8400 from 4.0b patch level 2 to patch
level 7.
We then tried the installupdate again with the exact same results. We have
previously successfully upgraded one 3000, two 2100's and one 4100 from
4.0b PL7 -> 4.0d patch level 2 w/o running in to this problem.
I should note, that this upgrade attempt was a "dry run". By that I mean
that it was done on a copy of our "real" system. Here's how we do it:
shut the system down and bring it up in single user mode
mount the disks that we will "clone" to
vdump/vrestore /, /usr, /var, /tmp to the "clone" disks
modify /etc/fstab on the clone disk to only mount /,/usr,/var,/tmp
shutdown to the >>> prompt
set bootdef_dev <clone device>
boot
upgrade the clone
shutdown to the >>> prompt
set bootdef_dev <back to original device>
boot
we've used this process for several years to do a dry run of the upgrade a
week or two before the actual upgrade is scheduled. The intent is to
encounter any problems and have some time to figure them out.
We have called this in to our Gold support team and I thought I would ask
here as well.
Any help, suggestions, advise etc would be appreciated and I will summarize.
David J. DeWolfe
Systems Programmer
Statewide Office of Information and Network Services
University of Alaska
907.474.7399
mailto:sxdjd_at_ts.sois.alaska.edu
In a vicious struggle for survival intelligence emerges as the weapon of
choice. - Nova, In Search of Human Origins
Received on Mon Feb 08 1999 - 22:53:45 NZDT