Thanks to all of you that responded to our problem.
A big thanks goes to Jan Mark Holzer who's advice we followed and managed to
get the system to restore OK.
Our Question :
We have tried to do a restore of the operating system (file systems /, /usr
y /var) in a different model computer than that where these file systems
were saved (from a ES40 to an Alphaserver 4100). We have followed the method
in the Installation Guide-Advanced Topics and in the System Administration
Guide. After the restore, when we try to reboot the system with generic
kernel to single user it can't boot and produces a panic with the message
"panic (cpu 0): mcbusconfl1: cannot configure PCI subsystem -get-bus
failure". The problem is not in the new computer, because it runs perfectly
when you boot the system with the Installation CD and even if you install
operating system with the Installation CD in the same disks that we restored
the file systems. This is the first time that we try to do this with version
5.1. In versions 4.0X we have done this procedure several times without
problems.
The Answer :
Hello,
yep V5 is a 'little' bit different. We now 'remember' the PCI
bus
locations and configuration. The side effect is that you can't
just boot a system disk (or restore it) on another
system/configuration.
In order to restore a system disk to another system (ie.
different
hardware) you have to delete the existing hardware database
information and re-create it after the restore operation.
The V5.1 System Admin guide has all the information in
chapter 5.7.6
Below you'll find a simple procedure you could use to clean out
the existing hardware databases and have them recreated at the
first boot off your next from the newly restored disk .
If you have an existing V5 system disk on the same system
make sure the bootdef_dev variable is reset to "" as otherwise
the boot process will read the device database off you
old system disk (this can be very confusing if you re-install
a system as you'll keep seeing the old device numbering/names) .
Here's the procedure, I'd suggest to run it on a test system
as this is mostly from memory :) :
1) Invoke this script on the system
#!/bin/sh
# Replace 'new_disk' with the mount point
# where you mount the newly restored root filesystem
# on your old system
#
rm /new_disk/etc/dec*
rm /new_disk/etc/dccd.*
rm /new_disk/etc/dcdd.*
rm /new_disk/etc/dfsc.*
rm /new_disk/etc/dfsl.*
rm /new_disk/cluster/members/member0/etc/cfginfo
rm /new_disk/etc/cfginfo
rm /new_disk/cluster/members/member0/etc/dfsl.dat
rm /new_disk/dev/tty0*
rm /new_disk/dev/lp*
rm /new_disk/dev/kevm*
rm /new_disk/dev/scp*
rm /new_disk/devices/disk/*
rm /new_disk/devices/rdisk/*
rm /new_disk/devices/tape/*
rm /new_disk/devices/ntape/*
rmdir /new_disk/devices/disk
rmdir /new_disk/devices/rdisk
rmdir /new_disk/devices/tape
rmdir /new_disk/devices/ntape
rm /new_disk/dev/disk /new_disk/dev/rdisk /new_disk/dev/tape
/new_disk/dev/ntape
rm /new_disk/cluster/members/member0/.Booted
2) Shutdown the system
3) Boot to single user
4) /sbin/mountroot
5) fix all files that know about device special files
- AdvFS
- LSM
- sysconfigtab (device special file name of swap device)
- fstab (ufs mounted devices)
- use hwmgr -v d to get new device special file names
6) Exit to continue booting
Hth,
Jan
www.guardianit.com
The information contained in this email is confidential and intended
only for the use of the individual or entity named above. If the reader
of this message is not the intended recipient, you are hereby notified
that any dissemination, distribution, or copying of this communication
is strictly prohibited. Guardian iT Group will accept no responsibility
or liability in respect to this email other than to the addressee. If you
have received this communication in error, please notify us
immediately via email: postmaster_at_guardianit.com
_____________________________________________________________________
This message has been checked for all known viruses by MessageLabs Virus Control Centre.
Received on Fri Feb 22 2002 - 15:40:08 NZDT