The horrorI was watching Law & Order: Special Victims Unit the other day when a giant ad popped up for The Bourne Ultimatum. This thing takes up a third of the screen and they actually did it twice in the same episode! Is this the networks’ new advertising strategy? I’m sorely tempted to pirate it out of sheer spite (in HD of course).
At the local OpenSolaris User’s Group meeting a few months back, one of the presenters asked a a fairly innocuous question to the gathered group of users: “How many of you use live upgrade?”. Of the gathered people present (mostly professional sysadmins), I was the only one who raised their hand. Suffice to say, this was quite a surprise, as binary Solaris Express: Community Edition releases are pushed out every 2 weeks and manually upgrading would take forever.
Background
LiveUpgrade was originally introduced in Solaris 8 10/01 (update 6), LiveUpgrade 2.0 is available for all versions of Solaris from 2.6 onward. The idea behind LiveUpgrade or lu is to be able to upgrade the os and rollout patches without affecting the running system. It also provides an incredibly effective failsafe if an upgrade or patch screws up something unexpectedly.
Preparation
One of the key parts of using lu is to plan for it when you first layout your filesystems during system install (you are following good fs layout practices right?). The simplest layout would be 4 slices, /, /export/home, swap, and an alternate root. In this layout, /export/home and swap are shared between both boot environments. The machine I’m using for this demo has a single 80gb ide disk with the following layout.
device mountpoint size type /dev/dsk/c0d0s1 1GB swap /dev/dsk/c0d0s0 / (root) 14GB ufs /dev/dsk/c0d0s3 (alternate) 14GB ufs /dev/dsk/c0d0s7 /export/home 44GB ufs
Obviously, in practice you will have a more fine-grained filesystem to slice ratio. Additionally, lu is smart enough to make the distinction between filesystems that hold os data like /usr and /var and filesystems that don’t like /export. It is also smart enough to deal with Solaris Volume Manager/Solstice Disksuite volumes and will usually cope with Veritas Volume Manager/Storage Foundation volumes too.
Use
When you first install Solaris, there aren’t any boot environments configured by default, although the snazzy new Caimain installer in OpenSolaris will automatically set aside an extra slice with the same size as /. If you have never used lu before, lustatus will look something like this:
[root@internal]~# lustatus
ERROR: No boot environments are configured on this system
ERROR: cannot determine list of all boot environment names
Initial state The system I’m using already has a boot environment named snv75 containing (surprise) OpenSolaris build 75.
Output of lucreateThe first step is to create the new boot environment. The first time you use LiveUpgrade, you will want to specify -c name to assign current environment. The most basic form of the lucreate command takes the form lucreate -n new environment name -m mountpoint:device:fs type . By default, the source for the new boot environment is the current enviroment, but this can be changed with the -s option. In this example, the new environment will be called snv77, and we want / (which is ufs) to be on /dev/dsk/c0d0s3.
[root@internal]~# lucreate -n snv77 -m /:/dev/dsk/c0d0s3:ufs
snip
Creation of boot environment
UpgradingThe next step is upgrading the new boot environment, this can be done from a physical cd/dvd, a cd/dvd image (using lofiadm), tape or a Flash archive. On this machine I’m using the OpenSolaris build 77 dvd image, mounted with lofiadm (this is the Solaris equivalent of loopback mounting using losetup or mount -o loop for linux users).
[root@internal]~# lofiadm -a /shared/sol-nv-b77-x86-dvd.iso
/dev/lofi/1
[root@internal]~# mount -F hsfs /dev/lofi/1 /cdrom
After mounting the image, luupgrade is invoked with the -u option (upgrade) -n new environment name -s path to install:
[root@internal]~# luupgrade -u -n snv77 -s /cdrom
As you can see in the screenshot, 2 packages failed to upgrade, in this instance they were packages from the blastwave repository, so not a critical issue. The failure of those packages is actually a good case for using LiveUpgrade. Had this been a traditional upgrade, we would not have known till we rebooted the system and something didn’t work, then we would have to figure out what was broken and get it fixed, all while users are probably unhappy; and of course the system would be down during the entire upgrade process.
luactivateOnce the upgrade/patching/package manipulation is complete, we want to activate the new boot environment. Easy as pie:
[root@internal]~# luactivate snv77
After luactivate luactivate adds the entries to grub and changes the default boot slice. Should something go wrong after reboot, all you have to do is reboot and choose the old boot environment in grub.
lu gui The Easy Way(tm)
Now that you’ve seen how to do LiveUpgrade manually, you should know that there is a much simpler (but less flexible) gui for it. The command to invoke it is simply lu.
Limitations
LiveUpgrade doesn’t support systems with non-global zones on installations older than OpenSolaris build 53, and doesnt support ZFS bootable data sets, at least not yet. On a related note, Al Hopper (all around Solaris guru and former member of the OpenSolaris Governing Board) of the DFW OpenSolaris User’s Group has written a quick howto on setting up ZFS boot. Xen/XVM was recently integrated into the main OpenSolaris builds, and as far as I can tell, there are no plans to support lu in guest domains on systems that aren’t fully virtualized (ie systems with cpus that don’t support Vanderpool/VT-x or Pacifica)