Live Upgrade on a Laptop ?
By user12611829 on Mar 05, 2007
I can think of several reasons.
Live Upgrade can be completely driven from ISO disk images of installation media. This means that I don't have to burn DVDs or CDs, or even better - no more late night runs to CompUSA or Fry's before the big presentation in the morning. And I won't miss the sound of the DVD reader grinding itself to death every time I install Solaris.
It simplies running multiple versions of Solaris, significantly. One of the most frequent questions we encounter in Installfests is which OS to run ? Solaris 10, OpenSolaris Community Edition, Solaris Developer Express, the nightly OpenSolaris BFU. And the answer is all of them. OK, maybe not for everyone - but even if you are going to choose one OS, upgrading to the newest update or applying a set of patches safely, while keeping the older environment as a fallback is a good thing, especially if you are on the road.
And best of all, Live Upgrade is quite simple as long as you follow the rules - and fortunately there are only a few.
The planAs with most things, the critical first step is the plan - and the earlier the better. For Live Upgrade this means the disk layout prior to installation. You will have to reserve some space for your alternate boot environment(s) when you initially install Solaris. While not strictly true, the mobile laptop user with a single disk drive will find the task of relocating data and repartitioning your disk after the fact rather complicated. In other words, you are better off planning in advance.
Here is an example of a multi-boot partition table that has been designed for Live Upgrade.
So how many boot environments do you really need ?
I use three - one for my customer facing Solaris 10 environment, one for my Open Solaris Community Edition daily driver, and one for whatever super-cool-gotta-have OpenSolaris project that is only available via BFU (today that is Xen, but it has been other things in the past and will likely be so in the future). And we all know that BFU means Better Forget Upgrades - but I have found that Live Upgrade is a simple way of preparing for a BFU. This third boot environment is also used as a backup during major Solaris updates (yeah, I would really like a 4th and 5th, but at some point you have to stop). Three is good.
How big do these need to be ?
That depends on how much stuff you carry around - specifically how much /opt will grow. There are some techniques you can use to reduce the storage requirements (sharing /opt directories across boot environments), but these tricks make other things more complicated (like zone creation). 6GB makes a good root file system, perhaps a bit larger if you start installing packages from Blastwave. Solaris Developer Express with the Studio development tools and Netbeans environment slightly larger - 8GB to 10GB.
Familiarization and Reading the Furnished MaterialsThe next step is to familiarize yourself with the process. There is a wealth of information to be found in the Solaris Documentation on the web, specifically Solaris Live Upgrade and Upgrade Planning in the Release and Installation Collection. Even more important is Infodoc 72099 which lists all of the patches required for Live Upgrade. An excellent community reference is Derek Crudgington's Live Upgrade for Idiots.
At first glance you may find the documentation a bit intimidating. Perhaps this is why more people aren't adopting Live Upgrade in their environment. Live Upgrade can do all sorts of spectacular things such as installing from a flasharchive, splitting and joining file systems, breaking Solaris Volume Manager mirrors - none of which apply to our current situation. In fact when you strip Live Upgrade down to the few parts that we will be using, it is amazingly simple. Here is an outline of the steps you will perform (after thoroughly reading the documentation - I have to say that).
- Check Infodoc 72099 to make sure all of the prerequisite patches are installed (and remember to do this each time as Live Upgrade is an evolving product).
- Create the new boot environment if it doesn't already exist. You can name your current boot environment the very first time you do this.
- Download the DVD ISO image for the new Solaris release or update
- Mount the ISO disk image
- Install the packages SUNWluu, SUNWlur (and if present, SUNWlucfg) from the installation media (in Solaris_nn/Product) in your current boot environment. This is a critical step - incorrect Live Upgrade software is the most common cause of failure.
- Run luupgrade -u to upgrade your new boot environment
- Check the upgrade logs in /var/sadm/system/logs in the new boot environment. The boot environment is mounted as /a during the upgrade, or you can use lumount after the upgrade is complete.
- Activate the new boot environment using luactivate
- init 0 (also critical as K0 RC scripts are installed to perform important steps like updating your bootloader configuration, syncing system files, and building a good boot archive.
Preparing for Live UpgradeI'm starting with a Solaris 10 6/06 system, freshly installed with my root file system (aka the primary boot environment) in c0d0s3. From my disk partition table you will see that I have two other boot environments available: c0d0s0 and c0d0s4. I plan on putting Solaris 10 11/06 in c0d0s0 and the latest OpenSolaris Community Edition (aka Nevada) in c0d0s4.
Since I've already read the documentation a few hundred times, I can proceed to patch analysis.
After comparing the patch list in Infodoc 72099 with what I have in Solaris 10 6/06 (showrev -p), I see that I am behind on four patches: 119255, 118855, 112653, and 121003. I fire up our new best friend updatemanager and see that I also need 121119 and 119255. These two will point updatemanager at the new repository.
So I apply 121110-08 and 119255-27, and restart updatemanager. This lets me find the rest of the patches that I will need.
I then apply 119255-32, 118855-19, 112653-04 and 121003-03. None of these required a reboot, so we can proceed immediately to the next step.
Creating the new boot environmentSince I will be upgrading from media and not a flash archive, I have to create a complete new boot environment, based on my current installation. This step will essentially clone the current system. As a side note, there are lots of fascinating uses for this that we will explore later.
Since this is the first time I am using lucreate, I also get to name my current boot environment. Future invocations of lucreate will be done without the -c argument.
# lucreate -c sol10u2 -n sol10u3 -m /:c0d0s0:ufsThis magic sequence told Live Upgrade to name the current boot environment sol10u2 and to create a new one called sol10u3 with the new UFS root file system on /dev/dsk/c0d0s0.
One more time, with output.
# lucreate -c sol10u2 -n sol10u3 -m /:/dev/dsk/c0d0s0:ufs Discovering physical storage devices Discovering logical storage devices Cross referencing storage devices with boot environment configurations Determining types of file systems supported Validating file system requests Preparing logical storage devices Preparing physical storage devices Configuring physical storage devices Configuring logical storage devices Analyzing system configuration. Comparing source boot environmentAt this point all of the system files from the current root file system are being copied to the new boot environment. On this laptop and with a rather complete Solaris install, it takes about 45 minutes.
file systems with the file system(s) you specified for the new boot environment. Determining which file systems should be in the new boot environment. Updating boot environment description database on all BEs. Searching /dev for possible boot environment filesystem devices Updating system configuration files. The device is not a root device for any boot environment. Creating configuration for boot environment . Source boot environment is . Creating boot environment . Checking for GRUB menu on boot environment . Creating file systems on boot environment . Creating file system for > on . Mounting file systems for boot environment . Calculating required sizes of file systems for boot environment . Populating file systems on boot environment . Checking selection integrity. Integrity check OK. Populating contents of mount point >. Copying.
Upgrading Live UpgradeIf you have not already done so, download and unpack the DVD ISO image for Solaris 10 11/06 (or whatever media you wish to use).
# lofiadm -a /export/iso/sol10u3/solarisdvd.iso /dev/lofi/i # mount -o ro -F hsfs /dev/lofi/1 /mnt # pkgadd -d /mnt/Solaris_10/Product SUNWluu SUNWlur (Remember to install SUNWlucfg if present)And answer Y when asked if you wish to overwrite existing files.
Perform a Live UpgradeWe will now run luupgrade(1m) to upgrade the new boot environment. Since Live Upgrade doesn't support non-global zones you should delete all installed zones in the target boot environment. This restriction is relaxed in the latest OpenSolaris snapshots. Since I'm starting with a clean Solaris 10 6/06, there are no non-global zones, so I can proceed.
# luupgrade -u -n sol10u3 -s /mntThis magic sequence says to run upgrade from the media source /mnt (mounted in an earlier step) against the boot environment sol10u3. The process will go something like
- Extract the miniroot from the source media
- Mount the new boot environment as /a
- Remove all of the packages from the new boot environment
- Install new packages from the source media
- Install a new boot archive
- Unmount the new boot environment
# tail -f /a/var/sadm/system/logs/upgrade_logWhen the upgrade is complete, check the logs for any failed package installations. Some are harmless, but all should at least be investigated. Also look at /var/sadm/system/data/upgrade_cleanup for a list of files that had conflicts, and what Live Upgrade did to resolve them. Most of these are harmless, but you should check to see if anything looks out of place.
# more `lumount sol10u3`/var/sadm/system/logs/upgrade_log # luumount sol10u3 # more `lumount sol10u3`/var/sadm/system/data/upgrade_cleanup # luumount sol10u3
Activating the new boot environmentThe last step is to activate the new boot environment. This is all done by a K0 script, so after activation it is imporant that you use shutdown or init 0. Do not use reboot as this bypasses the normal shutdown process and the K0 scripts will not run. This is also an FAQ!
# luactivate sol10u3 # init 0At this point some serious magic will be invoked. The K0 script will update your bootloader configuration (in this case /boot/grub/menu.lst on the boot partition), a new boot archive will be built (just in case), and commonly modified system files will be synced. This last step is driven by /etc/lu/synclist.
Extremely important GNOME warning: GNOME configurations are not generally compatible across releases. If you are switching between Solaris 10 and Nevada, OpenSolaris, or Solaris Developer Express you are advised to maintain separate home directories so that your GNOME configurations (.gnome, .gnome2, .gconf) don't collide. If you choose different Solaris users then you are done. If you are just changing your home directory in /etc/passwd then Live Upgrade will gladly send your old directory setting to your new boot environment - and that's not at all good. Either remove /etc/passwd from the file synclist or remember to log in via command line or failsafe session once you've activated and booted the new boot environment and manually change /etc/passwd.
And that's really about it. Recovery is rather simple. After activation you will have all of your boot environments available for selection. Skipping the activation step isn't recommended as it bypasses various sanity checks and the file sync process, but when recovering a broken boot environment I think I can deal with things like old passwords.
Practice makes perfectOne more time, this time putting a nevada build 57 in c0d0s4. The only change here is that nevada adds a new LU package: SUNWlucfg. The magic sequence looks something like
# lucreate -n nevada57 -m /:c0d0s4:ufs # mount -o ro -F hsfs `lofiadm -a /export/iso/nevada57/solarisdvd.iso` /mnt # pkgadd -d /mnt/Solaris_11/Product SUNWluu SUNWlur SUNWlucfg # luupgrade -u -n nevada57 -s /mnt # luactivate nevada57
Upgrading existing Boot EnvironmentsOnce you have used all of your boot evironments your next upgrade will require you to either delete one of them and start again or upgrade an existing boot environment. The differences are minor (ludelete and lucreate versus lurename and lumake), but there are a couple of things have to consider - if you don't then this will come back to haunt you wnen you least expect it.
Since there is no livedowngrade, you can only upgrade from an older version to a newer version. The implication is that you can't use Live Upgrade to install Solaris 10 from a Solaris 11 based system (Nevada, Solaris Express Community Edition, Solaris Express Developer Edition). That's not exactly correct, you can install a Solaris 10 from a flasharchive, but that's an installation, not an upgrade.
Now you know why I have three boot environments. I leave an old Solaris 10 around as a Live Upgrade source and then alternate the other two between whatever is the most interesting - today that is Solaris 10 11/06 as the legacy and Solaris 10 8/07 and Nevada in the ping pong set. Now that Solaris 10 8/07 has been released, it will become the legacy Solaris environment and I will go back to alternating between Nevada builds with and without xVM.
Another consideration, and common source of problems, is that Live Upgrade expects that the target enviroment match the source environment. As an example, lets assume that I am driving a Live Upgrade from Solaris 10 to one of my Nevada ping pong environments. It seems attractive to just upgrade one of the boot environments as it is - but it doesn't match the source. Some of the time, even most of the time, this will seem to work - but there will be times when drivers will not get replaced and you will have a hard to debug mess. The simple solution is to remember to lumake before you luupgrade.
One last thing - remember to check back to Infodoc 72099 as it does change occasionally - generally as a result of a Solaris release. But do check back to make sure your patch levels are correct.
One last example - my current boot environment is s10u3 and it is running Solaris 10 11/06. I have an nv69 and nv71 running Solaris Express Community Editions 69 and 71. I want to put Solaris 10 8/07 in the nv69 boot enviromnent and call it s10u4. After installing patches 119255-42, 121429-08, 126539-01, and 125419-01, the magic sequence goes something like
# lurename -e nv60 -n s10u4 # lumake -n s10u4 # mount -o ro -F hsfs `lofiadm -a /export/iso/s10u4/solarisdvd.iso` /mnt # pkgadd -d /mnt/Solaris_10/Product SUNWluu SUNWlur SUNWlucfg # luupgrade -u -n s10u4 -s /mnt # luactivate s10u4 # init 0And when a new Solaris Express Developer Edition or the next update of Solaris 10 is available, just repeat all of the steps above. I hope that this helps you understand an amazing Solaris capability and that you start using this on all of your systems, including your laptop.
Technocrati Tags: Sun Solaris Upgrade Laptop Live Upgrade