Patching with Live Upgrade

Live Upgrade is a technology in Solaris that allows you to easily upgrade a system while not risking change to your running environment. You can easily revert back to your previous environment if you need to. BigAdmin has a great guide on setting up Live Upgrade.

I’ve mentioned before about the problems of patching live systems. With the latest Solaris 10 KU for example most of the effort went into crafting the patch scripts so that the patch could be applied to a running system. When you patch a live system for example you have to take care about replacing libraries so that the commands you are delivery and the ones on the running system will continue to work, 118833-36 does some clever loopback mounting of libraries for this. With Live Upgrade this problem goes away.

Thats why patch testers and developers like LU. For users the benefits are that patching is easier – you don’t have to be in single user mode. Its safer – you can instantly return to your previous environment. And its quicker – the system can be patched while running and your downtime is just the time it takes to reboot to the new environment.

So how do you do it?

Set up an alternate boot environment.
For
this you need to have some space allocated for the boot environment
(BE), obviously it needs to be big enough to store the OS! lucreate(1M) is used to create our BE.

This names our current BE "Current_BE" and the BE we want to create as
"New_BE". The root filesystem is installed on /dev/dsk/c0t0d0s1 that
will be the root filesystem of the New_BE. The Bigadmin LU guide explains more detailed options for lucreate.

Now to patching!

We use the luupgrade(1M) command to do patching. The simplest way to add a patch to our New_BE is to do:

The -s argument indicating the patch directory is required. Adding multiple
patches is easy too. If you want to add all the patches in a directory
you can just do:

luupgrade does allow you to use an order file, but since the patches
will be ordered automatically in Solaris 10 this is redundant. For
older OS’s you could do this s recommended by Big Admin:

The -O option arguments are passed directly to patchadd. To remove patches we use the -T option:

Under the Hood

luupgrade re really just mounting the alternate BE, New_BE in our case, and then calling patchadd -R <mountpoint> to install the patches.

The -R argument causes, in the simplest cases, causes reloc directory from each package in the patch to be copied to /<mountpoint> rather than /.

In patch scripts the value of the -R argument is stored as $ROOTDIR, it is / is -R is not specified. So if you want your patch to say update an editable file you operate on ${ROOTDIR}/etc/file. Its good practice to prefix all filenames with ${ROOTDIR}.  Also if you are only interested in changing the running system, for example stopping and starting a service you need to check that $ROOTDIR is / before performing any operation.

At the package level the mount point is exported as $BASEDIR and $PKG_INSTALL_ROOT to the package level scripts. Similarly all paths in these scripts should be prefixed with $BASEDIR or $PKG_INSTALL_ROOT.

Leave a Reply

Your email address will not be published. Required fields are marked *