Thanks for all that. Your replies are confirming that it is the "state-of-the-art" and not so much what I am missing in my steps, that is causing the "hickups". And I put "hickups" in quotes because I'm *not* speaking disparagingly here: It is what it is at this point, and that in fact is the answer - at this point in time avoid moving a USB hosted O/S disk between USB ports. :-)
BTW... I did notice that boots into failsafe mode results in inconsistent device trees (it changes between boots) -- so I was hip to checking out the /dev/(r)dsk directories to confirm my boot device. I will try booting using "-m milestone=none/remount" method, but didn't before because not sure I will get that far. If I do, I will devfsadm it, and report back the results. Regards. -----Original Message----- From: Edward Pilatowicz [mailto:[email protected]] Sent: Wednesday, November 22, 2006 4:01 PM To: Noelle Milton Vega Cc: install-discuss at opensolaris.org Subject: Re: [install-discuss] So, is REINSTALLING SOLARIS MY ONLY OPTION AFTER MOVING A DISK? :-( well, we're pretty far off into unsupported land, but i know i've done similar things in the past so here are some ideas... On Wed, Nov 22, 2006 at 11:23:30AM -0800, Noelle Milton Vega wrote: > THIRD POSTING (LOOKING FOR HELP). SEE PROBLEM DESCRIPTION BELOW > > (Because there were no answers to my previous two posts below on this > same topic). Please email me with any answers, since I cross posted in > hopes of finding an answer. I will post-back good results. The email address is: > > nmvega at ComputingArchitects.Com > > Hi: > > After moving my USB drive (on which the O/S is installed) from one USB > port to another on my laptop, I need to reconfigure/re-order the > Solaris 10 x86 (nv48) device trees so that it can boot again. Right > now, it does not boot as attached to the new USB port. > > So as shown below, I performed the standard reconfiguration steps I > have many times over the years, yet they do not seem to be enough on > Solaris 10 x86. Here they are. What did I miss (TIA!): > > ==================================================== > Step 1) boot to failsafe ramdisk based O/S Step 2) mount -F ufs -o rw > /dev/dsk/c1t0d0s0 /a Step 3) (see rest that follows)... > > rm -f /a/dev/dsk/* > rm -f /a/dev/rdsk/* > rm -f /a/etc/path_to_inst > (I never "rm" the /devices tree; I only append to it) > > cp /tmp/root/etc/path_to_inst /a/etc/path_to_inst cd /dev/dsk; find . > | cpio -pudm /a/dev/dsk cd /dev/rdsk; find . | cpio -pudm /a/dev/rdsk > cd /devices; find . | cpio -pudm /a/devices > instead of all this copying, try running devfsadm -C -r /a > vi /a/boot/solaris/bootenv.rc (adjust the bootpath directive). > you'll also need to look in /a/dev/dsk, figure out the root disk name (which may be different from the name in the current failsafe environment), and make sure that value is stored in /etc/vfstab > /sbin/bootadm update_archive -v -R /a > > # And for good measure, I also did this: > cd /a/boot/grub > installgrub ./stage1 ./stage2 /dev/rdsk/c1t0d0s0 > ===================================================== > > So after doing all that and rebooting, I get the GRUB menu and select > Solaris to boot normally. What happens? The initial Solaris banner > shows up (and nothing else). It just hangs forever. I specified "-v" > to the kernel line within GRUB, and I see its gets to the "PCI Express > device line (early)", and thats it (it goes no further). > fyi, i've never used the failsafe archive in this manner. in the past i've always done something like this: - boot into milestone none by supplying the following options to the kernel: -m milestone=none - when you get a shell, remount root as read-write: mount -o remount,rw / - run: devfsadm -C - update /etc/vfstab to have the correct root disk pointer - (i don't remember if i updated bootenv.rc here.) - reboot. > Did I miss something? > not really, this is just unsupported, not documented anywhere, changes from release to release, and tricky to get right. in the past we have discussed changing the system so it can dynamically boot from whatever device we loaded bits from, but no official project for this has ever prototyped, funded, and staffed. ed
