Yes I have found that to be true about only one copy of the menu.lst is maintained, So what generates the /boot/solaris/bootenv.rc, if eeprom just stored the value?
But the boot disk selection in the Solaris-installer set up the target boot disk, play a role. in that I have ran a DVD or a jumpstart inital_install on a perfect good slice s0 and then again rerun the installer for another initial install of a different version of Solaris (Or OpenSolaris) and instead picked s3 and was later able to modify the menu.lst on the new s3 and boot into the s0 slice! >> I've succeeded with this, moving a boot IDE disk from an Ultra 5 to a >> SunBlade 100: >> (different IDE controllers) >> >> Boot the CD, in your new hardware. >> It generates /devices in a ram-disk. >> mount the root disk partition on, say, /mnt >> Remove /mnt/devices/* >> Copy the, generated /devices to /mnt/devices>> >> Remove /mnt/dev/rdsk/c* and /mnt/dev/dsk/c* >> Copy /dev/dsk/c* and /dev/rdsk/c* to /mnt etc. >> Edit your /mnt/etc/vfstab and fix the entries. >> //Alan So did the bootenv.rc value change in this test between the old and the new HW? The only way I was ever able to figure out how to update the bootenv.rc by booting the DVD in single user mode for the Solaris kernel or a boot net -s and run the format command and map the /dev back to /devices for the boot-device and and the cfgadm -val only shows the connected usb or sans deivces? So could this is a function of booting a kernel option be created to update the bootenv.rc like the other kernel options -r creating the /dev and /divices tree i.e unix -a recreating default /etc/path_to_inst So when could grub be closer to the OBP also handle show-devs or set them to list the interfaces between a BIOS data registers on one had and Solaris unix kernel OS side that uses the eeporm command to change the OBP or the bios and that ends up maintaining /dev/openprom and /boot/solaris/bootenv.rc This message posted from opensolaris.org
