Tim Foster's Weblog

As promised, I've now got an updated version of the old mountrootadm script that works with the new ZFS Bootable Datasets. It allows you to create multiple LiveUpgrade-like boot environments. Of course, it isn't a complete LiveUpgrade solution, but is enough for me. Tim also wrote about this sort of thing recently.

You can download zfs-bootadm.sh now.

Like mountrootadm, zfs-bootadm.sh allows a user to easily maintain several bootable datasets, creating, destroying, activating and listing them. It also updates the GRUB menu.lst file, so on boot, you get a menu of all bootable datasets.

In order to set it up, create a ZFS root system (this script may help) and do two things:

1. set the user-property "bootable:" on the root dataset, eg.
   zfs set bootable:=true pool/root_filesystem
2. Append the name of the current ZFS root filesystem to it's title in your your menu.lst file, which would be in /pool/boot/grub/menu.lst)

The user-defined property, bootable: is just used by the script to work out which datasets are being managed by it - it has nothing to do with the underlying ZFS boot functionality.

Once you've done that, you can start using the script:

 # ./zfs-bootadm.sh
Usage: zfs-bootadm.sh [command] <arguments>

where command is one of:
         create <name>
                Creates a new bootable dataset as a clone
                of the existing one.
         activate <name>
                Sets a bootable dataset as the next
                dataset to be booted from.
         destroy <name>
                Destroys a bootable dataset. This must not
                be the active dataset.
         list
                Lists the known bootable datasets.

# ./zfs-bootadm.sh list
onnv-gate:2007-03-30
test (current)
timmy
# ./zfs-bootadm.sh create my-test    
bootable dataset space/my-test has been created, and mounted on /tmp/bootable_dataset.101339
# ./zfs-bootadm.sh activate my-test
Currently booted from bootable dataset space/test
Creating ram disk for /tmp/bootable_dataset.101339
updating /tmp/bootable_dataset.101339/platform/i86pc/boot_archive...
 this may take a minute
updating /tmp/bootable_dataset.101339/platform/i86pc/amd64/boot_archive...
 this may take a minute
On next reboot, bootable dataset space/my-test will be activated.
# ./zfs-bootadm.sh list
my-test (active on next reboot)
onnv-gate:2007-03-30
test (current)
timmy

There's a few things I'm not entirely sure about - I don't like requiring the menu.lst titles to end with the name of the bootable dataset, but it makes the menu.lst file easier to manage. I'm not happy with the name of the script either - too much potential confusion with the real bootadm. Also, I've only tested this on one machine here, but it appears to work fine (yeah yeah, I'm guilty of it too sometimes)

I was half-thinking of using a "bootable:master" setting to specify a single dataset to use as a base for cloning new datasets - that way there wouldn't be the same cascading dependency between multiple bootable datasets (eg. pool/c cloned from pool/b@c, pool/b cloned from pool/a@b, meaning that destroying pool/a is awkward without promoting lots of clones). If you think this would be useful, let me know.

Thoughts/comments welcome.