Rebuilding the Solaris Device Tree

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

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.

Recovering From a Stuck Symantec Ghost Virtual Boot Partition

It seems that when you manage a bunch of machines with Symantec Ghost, you always end up with one or two that, for whatever reason, get stuck in the Ghost Virtual Boot Partition, and can’t boot back into windows. This can be really frustrating because you usually know what went wrong, and need to get back into Windows to fix the problem.

The good news is that setting the machine is really easy once you know how. I went through years of booting into DOS, and running fdisk from a floppy whenever this happened to me before I realized that fixing it is just a simple command that exists on the Ghost Virtual Partition.

Here is how it is done:

  • Stop Ghost and go to a DOS prompt:
  • If running the Ghost DOS client, NGctdos.exe, type Ctrl+X
  • If running the Ghost executable, Ghost.exe, type Ctrl+C
  • Change to the Ghost directory.
  • Type cd Ghost
  • Type ngctdos -hide

This last command hides the Ghost Boot Partition, makes the Windows partition active, and restarts the computer. You can then move on to fix the problem with minimal fuss, and get on with distributing the virus known as “Windows”.