Following is a long overdue summary of problems I ran into when upgrading a
system from V3.2G to V4.0d patchkit 3
Thanks to:
Tom Blinn
Alan Davis
Larry Magnello
for their support
The brief problem description was that I had to upgrade a V3.2g system to
V4.0d and tried to do it by skipping the rolling upgrade process.
I did this by saving what I thought were the critical system configuration
files, like /etc/rc.config, /etc/fdmns..., vat/adm/lmf... etc. before the
upgrade and then restoring them after new OS install.
Unknown to me -- due to stupidity on may part -- the orignal system was
running LSM, and the LSM configuration information was not saved.
When the new version OS was installed, the problem to be solved was to
restore the LSM configuration.
The disks holding the LSM managed data were on a separate SCSI controller
than the disk with /, swap, /usr, and /var, so the data still existed.
Chronology:
Day One:
After I had installed V4.0d and Jumbo Patch 3, I tried to start LSM and it
wouldn't start.
I realized that the right lines weren't in /etc/inittab and that the
/etc/vol and /dev/vol files were missing.
I was able to put those onto disk running the new version of the OS, by
restoring from a tar of the original / partition
I then started dxlsm and it stated that the volume daemon wasn't running,
which was no surprise.
I then rebooted so the system would start clean and execute the
/etc/inittab file
Several LSM related messages flew by on the blue screen as the system came up.
>From level 3, I ran a voldctl enable, then a vold.
I was then able to start dxlsm and found that the configuration was back,
viewable in the gui, however, it was in
a disabled state. I then realized after a while that the /etc/vol/type/gen
and /etc/vol/type/fsgen links were from V3.2 G and
were pointing to the wrong executables.
At that point I collected some information and decided to study the problem
on known machines I control.
Day Two:
Experimenting on my machines to find the locations on V4.0d of the targets
of the links from /etc/vol/type/fsgen.
And mapping the links from /dev/rvol so I could reconstruct them on the
target machine.
Day Three:
I was back at the machine and took a close look at the /dev/rvol listings.
The ones which I needed were
there with a date stamp of the time I started vold 2 days ago! On
reflection and readng the man pages, vold will look at the volboot file and
then using the information there, will scan the disk configuration and
import the disk groups.
Evidently, what happens is that vold recreates the /dev/rvol files.
So, after seeing the /dev/rvol entires, I just replaced all the links in
the existing /etc/vol tree with the correct links
for a V4.0d system, and LSM then started the rootdg disk group and the
volumes on which the Sybase db was just fine.
To summarize:
1. I trusted the manager of the system, rather than my own inspection and
that's how the LSM related links were left out of my upgrade steps.
2. vold will read the information from /etc/volboot and recreate (if
necessary) the /dev/rvol links it needs to run LSM. This is an empirical
finding.
3. From the V3.2 family of Unix to the V4.0 family, the targets of the
links from /etc/vol/type/* have changed. This is an empirical finding.
4. On any system runing LSM, I will always now do a rolling upgrade rather
than try shorcuts, or I would save all the LSM information, so I could
recreate the disk group information after a clean install of a new OS.
5. On a system without LSM, it appears to be possible to restore the
original configuration informaiton by carefully making copies of all the
relevant configuration information, the restoring it after the new OS install
6. The value of verified vdumps and/or tar files of the system is
immeasurable.
Again, Thanks and Regards
+--------------------------------------+
Bruce B. Platt, Ph.D.
Comport Consulting Corporation
78 Orchard Street, Ramsey, NJ 07446
Phone: 201-236-0505 Fax: 201-236-1335
bbp_at_comport.com, bruce_at_ bruce.platt_at_
OR, bruce_at_bbplatt.com
Received on Mon Jun 28 1999 - 13:32:41 NZST