SUMMARY: Disaster Recovery Issue: Rebuilding a system on different hardware from Tape

From: Stephen Kelly <>
Date: Tue Sep 25 2001 - 00:03:17 EDT
Thanks to:

Uddin, Mohammed M. []
Ilin, Jane []
Steve Hastings []
Brett Lymn []
Roger D. Leonard []

Mohammed's response contained the vital piece of information I was
missing, and Jane provided a succinct procedure for the steps I had
already followed. She referenced /a where I reference /mnt so I have
changed it to be consistent.=20

I had already followed the path of migrating the /dev and /device trees
from the cdrom boot to the root drive. However I failed to also migrate
the /etc/path_to_inst file. This proved to be the key to the whole

For the sake of brevity the full process is as follows.

How to restore root filesystem=20
This procedure assumes that you saved root partition using ufsdump.=20
1. Boot from CD to single-user mode. (boot cdrom -s)
2. Create new partition for root filesystem and than check it with fsck.
(format and newfs)
3. Mount the new partition on /mnt mount point.=20
4. restore root filesystem=20
        # cd /mnt
        #ufsrestore rvf /dev/rmt/0=20
5. Remove the restore symbol table and unmount new root partition.=20
        # rm restoresymtable=20
        # cd /=20
        # umount /mnt=20
6. Check root filesystem again( fsck )=20
7. Install boot block=20
        # cd /usr/platform/`uname -i`/lib/fs/ufs=20
        #installboot bootblk /dev/rdsk/<rootpartition>=20

8. mv /mnt/dev /mnt/dev-old
9. mv /mnt/devices /mnt/devices-old
10. mv /mnt/etc/path_to_inst /mnt/etc/path_to_inst-old
11. Copy the new "/dev", "/devices" and the "/etc/path_to_inst" from
the cdrom. ( I prefer the find-cpio pipe very effective for getting the
dev directories, and a tar pipe for getting the device subtree).

An example of the find-cpio pipe is: cd /dev; find . -depth -print |
cpio -pdlmv /mnt/dev
An example tar pipe is: cd /devices; tar cBf - . | ( cd /mnt/devices;
tar xvf - ) ( I use this one a lot)


I missed the path_to_inst file which turned out to be pivitol to the
whole process working. Thanks for all who helped and I now have a
successful restore of an Ultra 60 based server on an Ultra 5. It's this
sort of portability that makes an investment in Sparc/Solaris

Thanks again for all your help.


Steve Kelly

##   Stephen Kelly
##   Technical Specialist
##   Beacon Technology
##   ph + 61 8 9486 8500
"Those who cannot remember the past are condemned to repeat it."=20
- George Santayana

=3D=3D=3D=3D=3D Original Posting =3D=3D=3D=3D=3D
Greetings Managers.

The situation I am facing is as follows. One of our clients has pulled
their e-business site due to lack of demand. They intend to relaunch it
sometime in the future. We are in the process of archiving the system
off so that the clients hardware can be reused for other purposes.

The System is an Ultra60 running Solaris 7. The / , /usr , /opt and /u01
partitions are on different physical disks.

I have been tasked with restoring this system to another system on a
single disk and storing that disk offsite for quick recovery. The entire
system will currently fit on a 9Gb disk.

The process I have followed is:

Dump all partitons using ufsdump to tape.

Boot up my target restore server, which is an Ultra 5,  via cdrom into
single user mode. Configure my target disk, create a newfs and mount the
disk under /mnt.

Restore each dump across the wire onto the disk. This process works

Use installboot to install a bookblk on the target disk.

Do a touch /mnt/reconfigure. (Remembering the boot disk is on /mnt)

Edit /mnt/etc/system to ensure the rootdev points to the correct disk.

Edit /mnt/etc/vfstab appropriately.

Then I reboot the system, praying for it to come up.

Everything looks good initially, then i get a cpu panic. Here is the

Resetting ...

Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 270MHz), No Keyboard
OpenBoot 3.11, 128 MB memory installed, Serial #10409566.
Ethernet address 8:0:20:9e:d6:5e, Host ID: 809ed65e.

Rebooting with command: boot
Boot device: disk:a  File and args:
SunOS Release 5.7 Version Generic_106541-10 64-bit [UNIX(R) System V
Release 4.0
Copyright (c) 1983-1999, Sun Microsystems, Inc.
WARNING: kbconfig: keyboard open failed: error 6
BAD TRAP: cpu=3D0 type=3D0x31 rp=3D0x104073e0 addr=3D0x0 mmu_fsr=3D0x0
BAD TRAP occurred in module "genunix" due to a NULL pointer dereference.
: trap type =3D 0x31
pid=3D0, pc=3D0x100caf40, sp=3D0x10406c81, tstate=3D0x4480001600, =
g1-g7: 100a4338, a9d40, a9d40, ff00000, 2, 1041f700, 10408000
Begin traceback... sp =3D 10406c81
Called from 101c455c, fp=3D10406fd1, args=3D300001ecbb0 10407898 =
2 2 0
Called from 1004cf6c, fp=3D104070c1, args=3D1045c000 10407898 1045fce0
10446ba0 3000
01ecbb0 5400
Called from 1006cb00, fp=3D10407171, args=3D449f8254d 806fa4 3b4443ec 0
72000 1048c4
Called from 1009cdb8, fp=3D10407221, args=3D0 ffffffffffffffff 28 0 =
Called from 10006ecc, fp=3D104072f1, args=3D10408000 2000 10407ec0 =
Called from 100568cc, fp=3D132401, args=3D10006d08 1041f930 80 1045a528
10435db4 104
End traceback...
panic[cpu0]/thread=3D10408000: trap
syncing file systems... done
skipping system dump - no dump device configured

Could anyone give me some pointers to where I may be going wrong?=20



=3D=3D=3D=3D=3D=3D End Original Message =3D=3D=3D=3D=3D=3D=3D
Received on Tue Sep 25 05:03:17 2001

This archive was generated by hypermail 2.1.8 : Wed Mar 23 2016 - 16:32:31 EDT