If you ever shift around any bootable drives within a Sun Solaris box, you may find that either the device names (cxtxd0sx) do not follow the disk position within the server, or, the system just fails to boot because it can’t mount the other disk slices.
Let’s assume you are booting off of target 8 (c1t8d0s0), but wish to move that disk to the appropriate slot to make it target 0 (c1t0d0s0). You have changed all references in the /etc/vfstab file to reflect the new disk position, physically moved the drive from the target 8 slot to the target 0 slot, and changed the boot-device variable within the OBP to the appropriate disk. You should now be all set to boot from the disk in target 0, right?
Not quite yet.
Solaris creates a device tree with links to all the disks it knows about, and these don’t get rebuilt upon reboot. If you simply tried to boot the disk now in target 0, it would find the kernel, but fail to mount any of the other filesystems, because these device links are still pointing to the disk slices on target 8.
In order to boot off the drive in the new position, you will have to remove these device links and rebuild them. Here is how we do that:
1. Insert a Solaris 8, 9 or 10 cd into the hosts cdrom
2. From the ok prompt, enter boot cdrom -s
ok> boot cdrom -s
3. fsck the boot disk
# fsck -y /dev/rdsk/c1t0d0s0
Remember that your boot disk may differ than the example above. Since in our example above, we have put the disk into the slot for target 0 (c1t0d0), that is what we are using here.
4. Mount the root slice on /mnt
# mount /dev/dsk/c1t0d0s0 /mnt
Note that your root slice may differ than the above example.
5. Move path_to_inst
# mv /mnt/etc/path_to_inst /mnt/etc/PATH_TO_INST_ORIG
6. Remove all old device links
# rm /mnt/dev/rdsk/c* ; rm /mnt/dev/dsk/c* ; rm /mnt/dev/rmt/* ; rm
/mnt/dev/cfg/c*
7. Rebuild path_to_inst and devices
# devfsadm -r /a -p /mnt/etc/path_to_inst
8. Unmount the root slice and reboot
# umount /mnt ; init 6
You should now be able to boot off your old drive in its new slot.
[...] Notice that the target number will remain 2, not move to 0 when we swap the disks and boot from the new one. To resolve this, it is strongly suggested that you rebuild the solaris device tree and change the vfstab file to reflect the new disk position. [...]
Shouldn’t
# devfsadm -r /a -p /mnt/etc/path_to_inst
be
# devfsadm -r /mnt -p /mnt/etc/path_to_inst
/etc/inst_to_path doesn’t seem to be used (or created by this procedure) on i86pc. Moved a drive from an older V40 to a newer one and can’t get it to work, so any clues would be appreciated. I’ve done basically what’s above moving from SPARC to SPARC, but doesn’t seem to work on the AMDs.
Your directions look pretty good but I’m not quite sure about the arguments. Why, when you have the root mounted under /mnt are you using -r /a? I know the /a convention is usually what you’ll use if you’re mounting a filesystem under a failed boot which exits to the degraded single user mode… but wouldn’t the -r (root_dir) also be the mounted filesystem under /mnt?
Thanks, other than that looks great. I’m using some of your notes to migrate a fibre based V480 disk to a scsi based V440.
Jay
Doh, sorry, should have looked further down the page. Pardon my redundancy.
Jay
Very useful article - thanks. Like another poster, I was able to use this to help clone an already installed system from a V440 to a V240 with a different device layout.
Robert.
[...] we swap the disks and boot from the new one. To resolve this, it is strongly suggested that you rebuild the solaris device tree and change the vfstab file to reflect the new disk [...]
A. Braunsdorf:
I was having the same problem you are having. (because I installed it on one machine and then moved the disk to a completely different machine). I got the system running by starting up in safe mode and copying the file “path_to_inst” from the failsafe instance to the normal “etc” directory. I then modified the boot archive in the normal instance so that the file /boot/solaris/bootenv.rc had the parameter “boot device” pointing to the correct device. To find out what the new device was, I just made a ls -l to the /dev/dsk directory. Lastly I had to make some modifications to the vfstab file in the “normal” /etc/ directory. Hope this helps.
[...] we swap the disks and boot from the new one. To resolve this, it is strongly suggested that you rebuild the solaris device tree and change the vfstab file to reflect the new disk [...]