Repairing the Solaris /dev and /devices directories

The /devices and /dev directories on one of my Solaris 9 hosts got majorly borked a few weeks back, and the trusy old `devfsadm -Cv’ command wasn’t able to fix our problem. To clean up the device tree, I booted from CDROM into single user mode and manually cleaned up the device hierarchy. Here is what I did to fix my problems (WARNING: This fixed my problem, but there is no guarantee that this will work for you. Please test changes similar to this on non-production systems prior to adjusting production systems.):

Step 1: Boot from CDROM into single user mode

Step 2: Mount the “/” partition to your favorite place (if your boot devices are mirrored, you will need to perform the following operations on each half of the mirror):

$ mount /dev/dsk/c0t0d0s0 /a

Step 3: Move the existing path_to_inst aside:

$ mv /a/etc/path_to_inst /a/etc/08012007.path_to_inst.orig

Step 4: Clean out the /devices and /dev directories:

$ rm -rf /a/devices/*

$ rm -rf /a/dev/*

Step 5: Replicate the /devices and /dev directories that were created during boot:

$ cd /devices; find . | cpio -pmd /a/devices

$ cd /dev; find . | cpio -pmd /a/dev

Step 6: Adjust the vfstab to reflect any device changes

Step 7: Boot with the “-a”, “-s” and “-r” options to create a new path_to_inst (you can optionally use `devfsadm -C -r /a -p /a/etc/path_to_inst -v’ to create the path_to_inst from single user mode), and to add device entries that weren’t found while booted from single user mode

Step 8: Grab a soda and enjoy the fruits of your labor! :)

7 thoughts on “Repairing the Solaris /dev and /devices directories”

  1. Were your original metadevices recreated as part of this procedure? I’m guessing they’d be recreated due to -r boot option.

    If not, take a look at http://unixfreaks.net/?p=113 this should be usable with your procedure for 2 things:
    – recreate /devices & /dev’s original metadevices
    – let you work from the root mirror it self, doing stuff on both mirror sides at differing times (to my knowledge) can be technically dangerous depending on which way the main mirror syncs

  2. shouldn’t mv /a/etc/path_to_inst /a/etc/path_to_inst.orig.08012007
    be something like mv /a/etc/path_to_inst /a/etc/orig.080102777.path_to_inst? From what I’ve experienced path_to_inst is a hard coded name for the first 12 letters and you run the risk of the system picking up the wrong path to inst if it’s not named a bit differently…

  3. Matty,

    Would this procedure still work on Solaris 10? I know things are quite different now.

    I was looking for procedures to image (dd) a root disk on a v480 to the second internal disk, then move it to a near identical v480. I’m missing something the for FC-AL WWNs and the device link. I had to put the newly imaged drive in HHD1 (c1t1) and not HHD0 (c1t0) and it boots quite nicely, but I’d like it in HHD0, like the original server. I suspect because of the WWN, and maybe that I didn’t not recreate the path_to_inst. I’m still poking at it.

    Thanks, great articles. Keep posting.

    Chris

  4. Matty,

    In true Solaris fashion, your procedures for “Repairing the Solaris /dev and /devices directories” on Solaris 9, also worked flawlessly for imaging a second disk from a boot disk in a Sun Fire v480 and then repair the devices on the new v480 server.

    Just needed a Solaris 10 CDROM. I’m sure there’s another way to skin this cat, but for now, this works great.

    Take care,

    Chris

  5. Once again your insights saved the day !

    For the record there is no -p switch to devfsadm in solaris 8, path_to_inst gets re-created in /etc and needs to be copied back to /a/etc .

  6. Matty,

    I had a similar issue to this after restoring a S10u3 flar (sourcehost T2000, targethost T2000).
    The crux of the issue was not being able to find the boot device, and when you issue:

    [root@yoda:/] # format
    Searching for disks…done
    No disks found!

    This seemed a little odd, since I had just booted from the disks?!

    The source flar hard some additional external storage configured as mpxio. This is the cause of the issue.

    Basically – it is Sun bug# 6761587, being fixed with kernel 139555-08 U7.

    The workaround:

    1. boot net -s
    2. Update /a/kernel/drv/fp.conf – change mpxio-disable from “no” to “yes”
    3. Move /a/etc/mpxio/mpt.conf to /a/kernel/drv
    4. touch /a/reconfigure; umount /a ; reboot

    The system then comes up as you would expect.

    I hope this can help you or one of your readers!

    /Mark

Leave a Reply

Your email address will not be published. Required fields are marked *