SUMMARY: GRUB: booting from cloned root disk (how to)

From: Beat Jucker <>
Date: Thu Aug 28 2008 - 12:36:21 EDT
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::

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.

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
Received 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