From: Bütow, Michael (michael.buetow@comsoft.de)
Date: Thu Mar 20 2003 - 13:12:47 EST
My deep thanks to all who contributed to solve my immediate problem:
Bluejay Adametz, B.Krieg, David Stacks, and Dr Thomas Blinn.
The "PCI configuration failure" kernel panic resulted from the presence of
persistent data in "device databases" located under /etc, even when booting
from a generic kernel.
It is not as straightforward to get a restored dump to work on a different
hardware platform under v5.x as it was under 4.0(F), where I could boot the
generic kernel into single user mode and rebuild a kernel tailored to the
new hardware. To quote Bluejay Adametz:
"Tru64 v5 keeps a lot of device information in device database files, rather
than depending on how the kernel is built. This means that, even though you
booted a generic kernel, it's still using the device information from the
previous system."
Eventually, the procedure that got the new system working was:
(I have only UFS filesystems so YMMV..)
1. boot from 5.1B install CD and restore the dump from tape
2. delete the device databases on the restored system, specifically
dec_devsw_db*, dec_hw_db*, dec_hwc_ldb*, dec_scsi_db* in /etc
3. replace the restored /etc/dfsl.dat with the dfsl.dat from /var/etc of the
booted install CD
4. now should be able to boot into single user from the restored genvmunix
kernel, which should create new device databases
5. run "dn_setup -init" and "dsfmgr -K" to get rid of old device names and
regenerate new ones
6. now should be able to mount the non-root filesystems (I preferred to use
bcheckrc) without necessarily adjusting /etc/fstab
7. reinstall the generic sysconfigtab either from CD or from
/etc/sysconfigtab.GENERIC
8. rebuild a new kernel using "doconfig" and copy it to /vmunix
9. now should be able to boot normally on the restored disk
I think these steps represent the essentials, but since I didn´t know the
sequence I also tried other options to get the device naming correct, such
as "dsfmgr -v -F" but these didn´t fix things completely. For example, the
/dev/disk/dsk0* devices hung around, with the two new disks being named as
dsk1 and dsk2 . The sequence in step (5) did the trick .
Other helpful comments suggested that patch kit 1 for 5.1B should at least
be installed since this fixes diverse problems, some of which affected
booting. In my case I didn´t have to do it, but it may help someone.
Also, the "btcreate" command may be used to create a bootable tape dump of a
system can be used to work around the dilemma. I have not tried this utility
yet, but when I do I´ll probably have some more questions and answers :-)
Michael Bütow
<michael.buetow@comsoft.de>
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:13 EDT