Thanks to Doug Yatcilla. He gave me the missing puzzle: mount /dev/dsk/c1t1d0s0 /mnt bootadm update-archive -R /mnt -- Beat ---------------------------------------------------------------------- > Well, this is how I see things; > > c1t0d0s0 is the disk with your original Solaris 10 system. That disk > is hd(0,0,a) from GRUB's point of view. The c1t0d0s0 should have > "/pci.../sd@0,0,a" specified in the bootenv.rc file. > > If your disk controller will only boot from c1t0d0s0, then the GRUB > bootblocks are read from that disk as are all the files in /boot/grub > (like menu.lst). So, that disk needs to be present when the system > boots. > > But, you may specify a different disk from which Solaris will be > booted. I would verify that using "root (hd0,0,a)" in GRUB will boot > Solaris from c1t0d0s0. > > Next, mount c1t1d0s0 on /mnt and verify that /mnt/etc/vfstab > has the root filesystem specified as c1t1d0s0. Also, verify that > /mnt/boot/solaris/bootenv.rc has bootpath set to "/pci.../sd@1,0,a" > > Next, mount c1t1d0s0 on /mnt and verify that /mnt/etc/vfstab > has the root filesystem specified as c1t1d0s0. Also, verify that > /mnt/boot/solaris/bootenv.rc has bootpath set to "/pci.../sd@1,0,a" > > Then, reboot the system and specify "root (hd1,0,a)" in GRUB to boot > Solaris from c1t1d0s0. > > If that doesn't work, then I am stumped. > > If it doesn't work, I would use Live Upgrade (lucreate & luactivate > commands) to make a copy of your current boot environment from > c1t0d0s0 to c1t1d0s0. This will automatically do exactly what you are > trying to manually. LU will automatically adjust GRUB, bootenv.rc, > /etc/vfstab, etc. It is probably the safest thing to do. > > Good luck, > Doug Hello Beat, I forgot about the bootadm command. I think you need to run "bootadm -R /mnt update-archive" in order for the changes you made to /boot/solaris/bootenv.rc to be included in the ramdisk image of Solaris that is booted by GRUB. More info here:: http://www.sun.com/bigadmin/features/articles/grub_boot_solaris.jsp http://flux.org.uk/howto/solaris/fix_boot_archive The lesson is that the booting process for x86 Solaris is more/overly complicated and prone to errors compared to SPARC. Live Upgrade simplifies things, though. -Doug Hello SUN sysadmins We have a Sun Fire x4240 (fully patched Solaris 10). Until now I have worked only with Sparc & Solaris9. I'm not so familiar with x86 & Solaris10. I want to be able booting from a cloned disk. Because ZFS isn't ready for system FS I have cloned the system disk manually (just a small modified script already working for our Solaris9 Sun Fires): - partition the clone disk, make it bootable fdisk -B /dev/rdsk/c1t1d0p0 prtvtoc /dev/rdsk/c1t0d0s2 | fmthard -s - /dev/rdsk/c1t1d0s2 installgrub -fm /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c1t1d0s0 - create filesystem and copy all files to the clone disk (using snapshot and ufsdump, adjusting cloned /etc/vfstab afterwards) - enhance GRUB boot menu to hd1 (default: root=hd0,0,a) title Solaris 10 clone disk root (hd1,0,a) kernel /platform/i86pc/multiboot module /platform/i86pc/boot_archive So far everything seems OK but when I boot the system (GRUB boot menu "Solaris 10 clone disk") it boots always from default root (c1t0d0) and not from cloned disk (c1t1d0). Even when I change/edit the boot disk manually from GRUP boot menu: root (hd0,0,a) --> root (hd1,0,a) it boots from c1t0d0 ... Did I miss something? Because I'll use zfs raid feature for user data I didnt touch the builtin Raid controller ASR-5805. But after checking disk status with the command "arcconf getstat 1 al" I can see only disk-0 has "Bootable=Yes" and all other disks have "Bootable=No". Could this be the problem? How to set disk-1 as "Bootable=Yes" (couldn't find this task in the manual)? Best regards -- Beat _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Thu Aug 28 12:38:47 2008
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:44:11 EST