Known, but underused Solaris Features: Live Upgrade

How to change the world ?
Once in a while root saw some imperfections in his world. He had change some things. But root couldn´t stop the turning of the world for hours as people lived in this world. Because of root´s special powers, root was able to create a second world without people. Thus root created a second world as an exact copy of the old world. And now root was able to work on the imperfections of his world as long as root wanted. Then he behold and all was good. A magic chant late at night when all people slept and the people woke up in the new world. What´s Live Upgrade
Okay, Live Upgrade isn´t really a “less known feature”, but in the time working at the keyboard at several customer sites, i´ve got aware of a fact: One of the most simple, but brilliant feature of Solaris is a somewhat unused feature. The feature is called Live Upgrade. We´ve got painfully aware of two facts in the past: At first … yes, we know of our somewhat suboptimal patch process. And: You can´t expect updates of the operating environment when you have to bring down the machine for some time. Thus Sun introduced a feature called Live Upgrade. Okay, Live Upgrade is so easy that nobody has an excuse not to use it. And with 6 GB size of the SOE and 73 GB boot disks minimum “no space” isn´t an excuse too ;) The concept behind Live Upgrade
The basic concept behind Live Upgrade is pretty simple. All mechanisms are grouped around the concept of alternate boot environments. At first you have your running boot enviroment and a emtpy slice or disk (the symbol with the thick lines is the active boot environment).


Now you create an alternate boot environment. It´s a copy of the actual boot environment. The system still runs on this environment.


The trick is: The update/patch processes doesn´t work on the actual boot environment, they use this alternate but inactive boot environment. The running boot environment isn´t touched at all.


After the completion of the updating you have an still running boot environment and a fully patched and updated alternate boot environment. Now the boot environments swap their roles with a single command and a single reboot.

After the role swap the old system stays untouched. So, whatever happens with your new installation, you can fall back to you old system. In case you see problems with your new configuration, you switch back the but environments and you run with your old operating environment. A hint for testing this
Use some spare equipment. I´ve used my MacBook Pro for the first try, and it took forever. Do yourself a favour and don´t use a virtual environment. At least use a real DVD and not an ISO to prevent the harddisk from jumping around. Using Live Upgrade without Updating
Okay, i will present two usecases to you: The first one doesn´t exactly match to the “upgrade” moniker. It´s a solution for a small problem: You´ve installed your system and after a few weeks you realize, that you filesystem model wasn´t the best choice. /export/home to large, / to small. and a seperated /var would be nice. Okay, how you seperate those filesystems without a longer service interuption. Bringing the system down, moving files around, booting it up is not an option for productive system. Moving while running isn´t a good idea. Live Update is a nice, but simple solution for this problem: Live Upgrade replicates the boot environments by doing a file system copy. The filesystem layout of the old boot environment and the new environment doesn´t have to be the same. Thus you can create a filesystem layout with a bigger /, a smaller /export/home and a seperate /var. And the best is: The system runs while doing this steps. In my example i will start with an operating system on a single partition. The partition is located on /dev/dsk/c0d0s0 and has the size of 15 GB.

<br />
/ on /dev/dsk/c0d0s0 read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=1980000 on Mon Feb 11 21:06:02 2008<br />

At the installation time i´ve created some additional slices. c0d0s3 to c0d0s6. Each of the slices has the size of 10 GB. Seperating the the single slice install to multiple slices is nothing more than using Live Upgrade without upgrading. At first i create the alternate boot enviroment:

# lucreate -c "sx78" -m /:/dev/dsk/c0d0s3:ufs -m /usr:/dev/dsk/c0d0s4:ufs -m /var:/dev/dsk/c0d0s5:ufs -n "sx78_restructured"<br />
Discovering physical storage devices<br />
[..]<br />
Populating contents of mount point </>.<br />
Populating contents of mount point </usr>.<br />
Populating contents of mount point </var>.<br />
[..]<br />
Creation of boot environment <sx78_restructured> successful.

We´ve successfully created a copy of the actual boot environment. But we told the mechanism to put / on c0d0s3, /usr on c0d0s4 and /var on c0d0s5. As this was the first run of Live Upgrade on this system the naming of the environment is more important than on later runs. Before this first run, the boot environment has no name. But you need it to tell the process, which environment should be activated, patched or updated. Okay, my actual enviroment runs with Solaris Express CE build 78, thus i´ve called it “sx78”. The lucreate command set this name to the actual enviroment. My new boot environment has the name “sx78_restructured” for obvious reasons. Okay, now you have to activate the alternate boot environment.

# luactivate sx78_restructured<br />
Saving latest GRUB loader.<br />
Generating partition and slice information for ABE <sx78_restructured><br />
Boot menu exists.<br />
Generating direct boot menu entries for ABE.<br />
Generating direct boot menu entries for PBE.<br />
[..]<br />
Modifying boot archive service<br />
GRUB menu is on device: </dev/dsk/c0d0s0>.<br />
Filesystem type for menu device: <ufs>.<br />
Activation of boot environment <sx78_restructured> successful.

Now we have to reboot the system. Just use init or shutdown. If you use any other command to reboot the system, Live Upgrade will not switch to new environment:

# init 6

Okay, this takes a minute. But let´s have a look on the mount table after the boot.

# mount<br />
/ on /dev/dsk/c0d0s3 read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=1980003 on Tue Feb 12 05:52:50 2008<br />
[...]<br />
/usr on /dev/dsk/c0d0s4 read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=1980004 on Tue Feb 12 05:52:50 2008<br />
[...]<br />
/var on /dev/dsk/c0d0s5 read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=1980005 on Tue Feb 12 05:53:12 2008

Mission accomplished. Okay, but we want to use LiveUpgrading for upgrading, later. Switch back to your old environment:

# luactivate sx78

Boot the system. And your are back on your old single-slice installation on c0d0s0:

<br />
/ on /dev/dsk/c0d0s0 read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=1980000 on Mon Feb 12 06:06:02 2008<br />

Using Live Upgrade for upgrading Solaris Express
With a new Solaris Express Community Edition every week a Live Upgrade procedure is a good practice to update your system to a new release of the operating system. Okay, i´ve burned a DVD with the Solaris Express Community Edition Build 81. I want to upgrade the exisiting boot environment on the three slices. Just to keep the naming in line, i rename it so sx81.

# lurename -e sx78_restructured -n sx81<br />
Renaming boot environment <sx78_restructured> to <sx81>.
Changing the name of BE in the BE definition file.<br />
Changing the name of BE in configuration file.<br />
Updating compare databases on boot environment <sx81>.<br />
Changing the name of BE in Internal Configuration Files.<br />
Propagating the boot environment name change to all BEs.<br />
Boot environment <sx78_restructured> renamed to <sx81>.

You don´t have to rename it, you just could use the old name. But why should you confuse your fellow admins by calling your Build 81 boot environment sx78_restructured. Okay, now start the upgrade. My installation DVD was mounted under /cdrom/sol_11_x86 by Solaris and i want to upgrade the sx81 boot environment. This will take a while. Do this overnight or go shopping or play with your children. Your system is still running and the process will not touch your running installation:

# luupgrade -u -n sx81 -s /cdrom/sol_11_x86
Copying failsafe kernel from media.<br />
Uncompressing miniroot<br />
[...]<br />
The Solaris upgrade of the boot environment <sx81> is complete.<br />
Installing failsafe<br />
Failsafe install is complete.

Okay. Let´s check the /etc/release before booting into the new environment:

# cat /etc/release<br />
                   Solaris Express Community Edition snv_78 X86<br />
           Copyright 2007 Sun Microsystems, Inc.  All Rights Reserved.<br />
                        Use is subject to license terms.<br />
                           Assembled 20 November 2007

Activate the new boot environment:

# luactivate sx81
Saving latest GRUB loader.<br />
Generating partition and slice information for ABE <sx81><br />
Boot menu exists.<br />
Generating direct boot menu entries for ABE.<br />
Generating direct boot menu entries for PBE.<br />
[...]<br />
Modifying boot archive service<br />
GRUB menu is on device: </dev/dsk/c0d0s0>.<br />
Filesystem type for menu device: <ufs>.<br />
Activation of boot environment <sx81> successful.

Eject the installation DVD and reboot the system:

# eject<br />
cdrom /dev/dsk/c1t0d0s2 ejected<br />
# init 6

Wait a minute, login to the system and let´s have a look at /etc/release again:

bash-3.2$ cat /etc/release<br />
                   Solaris Express Community Edition snv_81 X86<br />
           Copyright 2008 Sun Microsystems, Inc.  All Rights Reserved.<br />
                        Use is subject to license terms.<br />
                            Assembled 15 January 2008

By the way, the system runs on the three seperated slices now:

/ on /dev/dsk/c0d0s3 read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=1980003 on Tue Feb 12 07:22:32 2008<br />
[..]<br />
/usr on /dev/dsk/c0d0s4 read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=1980004 on Tue Feb 12 07:22:32 2008<br />
[..]<br />
/var on /dev/dsk/c0d0s5 read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=1980005 on Tue Feb 12 07:22:54 2008<br />

Neat, isn´t it ? Do you want to learn more ? Documentation
Solaris 10 8/07 Installation Guide: Solaris Live Upgrade and Upgrade Planning » Upgrading With Solaris Live Upgrade</blockquote> Others
Solaris[TM] Live Upgrade Software: Minimum Patch Requirements(the infodoc formerly known as 72099)