Received several replies, but found the answer in the release notes manual.
the 4.0f to 5.0A upgrades have problems with ufs encapsulated LSM volumes.
to determine if this is the case "mount -t ufs |grep /dev/vol". any output
is a ufs encapsulated LSM volume. the fix is very easy before the upgrade "
voledit set fstype=4.2BSD ufsvolnames" or after the is a documented
procedure in the 5.0a relaese notes.
-----Original Message-----
From: O'Brien, Pat [mailto:pobrien_at_mitidata.com]
Sent: Friday, February 09, 2001 8:28 AM
To: tru64-unix-managers_at_ornl.gov
Subject: tru64 v4.0F to v5.1 migration
We are committed to converting all systems to v5.1 by fall, and are aware of
the 2 paths ending on v5.1. The first is 4.0F to 4.0G to 5.1 while the
other of 4.0F to 5.0A to 5.1. We suspect the later path, for lack of better
reasoning, we have this set of CD's, and we understand 4.0G was mostly just
a hardware release for GS160/320's. Each system to be upgraded is a
standalone (nonclustered) system. We heavily utilize LSM & ADVFS. All
system volumes are mirrored with LSM although no root or /usr partitions
utilize ADVFS and reside within the system cabinet(no sys volume on
hs(zg|z)'s controllers). We have performed the upgrade on test systems just
a couple of times so far, with very sad results. The big impediment seems
to be LSM and the mirrored root partitions. My question to the group is, 1)
Have others done 4.0F to 5.1 upgrades with similar LSM config, and what
happened, 2) Is the recommendation to remove LSM from root/sys volumes
before attempting these upgrades? And not to worry, we will be going back
to our test systems, and continuing to work out these bugs, but all generous
recommendations all welcome.
Received on Tue Feb 20 2001 - 18:54:35 NZDT