Solaris ZFS root boot mirror pools are usually pretty easy to clone and move to different boxes with little difficulty. There is quite a bit of data on the web about this already so I’m not going to get into the nitty gritty. I might add some better examples with complete shell output later but I’m not near a broken system at the moment. In a nutshell, if you’ve built your O/S on a pair of disks using the ZFS boot option you can later move one of the mirrored disks to another box and clone away. (You’re thinking, ‘why don’t you just use Jumpstart?’ Yeah, me too. )
After the initial install you need to make sure you can boot from both drives. If drive 0 goes away you kinda hope that drive 1 will be bootable. By default the second drive (drive 1) – which is a mirror of the first (drive 0) – is not bootable. In the x86 world you need to run installgrub to make driveN bootable.
[root@someserver:~]# installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c3t0d0s0 Updating master boot sector destroys existing boot managers (if any). continue (y/n)?y stage1 written to partition 0 sector 0 (abs 16065) stage2 written to partition 0, 272 sectors starting at 50 (abs 16115) stage1 written to master boot sector [root@someserver:~]# bootadm update-archive updating /platform/i86pc/boot_archive [root@someserver:~]#
You may also want to run bootadm update-archive. On recently installed / disk changed systems you’ll note that the boot archive will get updated just prior the actual reboot.
Once you’ve grabbed a mirrored disk and plopped it into a similar bit of kit you should be able to boot from it. Then you can add a second disk to the system, fdisk it, give it the same partition table as the disk you borrowed from the other system, replace the device in the pool, installgrub on the second disk in the second box, and so on…. I’ll have to write something else about that simple process later.
So — you’ve done all the requisite stuff, replaced the borrowed disk, gave everyone some boot blocks, everything is good to go and it’s time to turn over the cloned box to whomever will be using it. Based on $foo, you decide to reboot the thing one more time, just because.
Oh Carp! It boots to a SPLAT> prompt, errr.. I mean, GRUB> prompt.
Now, one of the common solutions involves some boot media (read: cd or dvd), importing the pool, mounting things on /a and updating the boot archive on /a. In some cases that also means a trip to the datacenter.
Since I like to break as many things as possible I’ve seen the Grand Unified Boot Loader prompt ‘a few’ times. Depending on the hardware (read: boot time), sometimes you’re better off just booting from the CD and fixing things. On the other hand if you know the basic details about where things are supposed to be you can use GRUB as designed. (Okay, you use this method because you really don’t want to drive the datacenter in the afternoon. If it breaks in the morning, you might opt for the CD method. It’s technical, don’t ask.)
I don’t have the proper screenshots for this tonight, but these are some bits of data that I recently used on a borked Sun X4200M2. Everything was going fine, I had installed the boot blocks with installgrub and it returned the correct output but the box rebooted to a grub prompt so I used the data below to boot the box and reinstall the boot loader.
From the GRUB> prompt, in order, I issued the following statements, the kernel loaded and I was in like Flynn! It’s probably a good time to mention that this was done over a serial console that allows remote access to a system console. Also, without some form of LOM (Lights Out Management), or remote power you’ll be headed to the datacenter for the reboots.
findroot (pool_rpool,0,a) kernel$ /platform/i86pc/multiboot -B $ZFS-BOOTFS module /platform/i86pc/boot_archive boot
The snippet above is direct from the GRUB config and each line is followed by some system details as grub locates $x and then boots. In the example, the system was built with the default name of rpool for the root pool.
This is not going to work in every situation, it’s a good idea to have a copy of the menu.lst which is generated by bootadm for your systems. Example:
-bash-3.00$ pwd /rpool/boot/grub -bash-3.00$ tail -10 menu.lst | head -3 findroot (pool_rpool,0,a) kernel$ /platform/i86pc/multiboot -B $ZFS-BOOTFS module /platform/i86pc/boot_archive -bash-3.00$
Even when you boot from the CD and import the root pool you may run into issues. For example, booting to a shell from the install media usually tries to find an installed OS. With ZFS root pools you might not have things automagically mounted on /a. Better yet, /a may then be a read only filesystem so importing the pool and fixing the boot archive can be fun. (think /tmp/foo, it’s writeable)
Too many words about a simple fix :) Thanks for reading.