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:
- set the user-property “bootable:” on the root dataset, eg.
zfs set bootable:=true pool/root_filesystem
- 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)
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.