live upgrade rocks

Trying to build the latest tree, I ran into the problem that my build machine is downrev (its b74.) So I had to update to 77 to get the latest tree to build.

For any other OS, or in past days for Solaris, this would be a major crisis, incurring numerous hours of downtime. (Or I could use bfu.) But I decided to finally try out live upgrade.

I had an ISO image of b77 stored on a local zfs filesystem (along with all my critical data). When I had installed this system, I had set it up with a spare empty slice matching the / slice in size, in anticipation of one day trying out live upgrade. Boy am I glad I did.

All I had to do was a few commands:

# lucreate -n b77 -m /:/dev/dsk/c1t0d0s3:ufs

(Wait about 20 minutes.)

# lofiadm -a /data/isos/sol-nv-b77-sx86.iso
# mount -F hsfs -o ro /dev/lofi/1 /mnt
# luupgrade -u -n b77 -s /mnt

(Wait another 20-30 minutes.)

# luactivate b77

# init 6

(That last step confused me. I tried "reboot" a few times, before I actually read the output from luactivate to realize that you CANNOT USE REBOOT.)

All in all, the total downtime was the cost of a single reboot. (Well, several in my case, but that's because I didn't follow the instructions and used the wrong reboot command. Doh!)

Total time to upgrade took less time than it took to download the iso in the first place. Using lofi and zfs made this even more painless. Yay. And now I'll never be afraid to upgrade Solaris again. Had this been Windows or Linux I was trying to upgrade, I'd probably have had to kiss off the entire weekend dealing with fallout, etc.

A big kudos to the LU team. (And shame on me for not discovering this cool technology in Solaris earlier... its been around since Solaris 10u1, at least.)

Comments

what said…
> Had this been Windows or Linux I was trying to upgrade, I'd probably have had to kiss off the entire weekend dealing with fallout, etc.

Now that isn't very nice or accurate. Both Windows and GNU/Linux distros can update major OS systems even easier. Click the upgrade button and they connect to the internet to download what needs to be installed.
Unknown said…
Not true. Sure, you can do minor updates. But when is the last time you tried to upgrade to a new major kernel version (e.g. 2.2.x to 2.4.x, or 2.4.x to 2.6.x? Or going from XP to Vista? Those are non-trivial upgrades. And you can't just easily click to upgrade.)

While updating to a new build was seamless and easy, and some might argue it is akin to updating a patch (though that isn't technically how it is done), the same LU process can be used to upgrade from S10 to Nevada, or from S9 to S10. Thos are most definitely *not* patch updates.
Unknown said…
Hello... Just to say that it may be straight forward... but in my case it isn't ! Thinking of upgrading from build 52 (!!!) with some zfs filesystems and 3-4 whole zones is not as easy as it should be ! :-) At least nothing was broken... but I'm still trying... Most of time my PC hangs during the luupgrade. So I'm now trying to shut down everything I can (i.e. zones and unused services...).let's see... I'll post the results in a few days :-)
pbaldanta said…
Hi,

I guess that during luactivate, there are several script files changes regarding boot device into eeprom and something like that.
JimKlimov said…
Is there anything like Live Upgrade for a bootable ZFS root in OpenSolaris Nevada?

I have a test system set up with snv_b77. Then I followed the numerous blogs to make a ZFS root pool from the original UFS root - just to try it out.

And to eventually try out ZFS-root live upgrading, which is supposed to be more simple than previous technologies...

And now I want to update to a newer snv_b84. The DVD/Net installers don't see that there is an installed Solaris on the server and only offer a fresh install.

So now i'm trying to "lucreate" and "preserve" with a writable clone, but lucreate also doesn't seem to work with pools yet.

Any ideas? Are ZFS-root systems upgradable other than by BFU?

Currently digging in /usr/sbin/lu* to find how it runs the installer with an alternate root...
Unknown said…
In response to Cedric:

* I don't think Zones support is well integrated with LU yet. That situation is still evolving, and should get better as time progresses.

In response to Jim:

* I'm not sure LU supports ZFS root yet. ZFS root is still an evolving technology, and isn't officially supported yet. HOWEVER, I expect that in the next build or two, things will become much much better.

Overall, note that there is a Caiman project, which intends to overhaul the installer technology, and also a ZFS root project, which are both proceeding apace. As these projects near 1.0 milestone, I think you'll find the situation will improve very very greatly. In particular, having a BE on ZFS offers some opportunities in the installer to make use of copy-on-write to greatly decrease the size of LU between builds, and make the whole process a lot more smooth. Stay tuned!
Tuli Poika said…
Well, upgrading a kernel in Linux isn't hard, really. In Debian just run apt-get and reboot. If the kernel isn't broken, everything's fine. And I've yet to find a broken kernel in Debian.

Upgrading XP to Vista is also very straightforward.

I'm just doing my first ever Solaris upgrade (Sun sent a device with S10 11/06 yesterday, why not 05/08...) and it's taking a looooooong time, not to mention the hassle of downloading an ISO image with another machine and other annoying stuff.

And not to mention the hassle of creating a copy of the OS and waiting a couple of years for it to complete.

Funny, Fire T1000 and luupgrade has been running for over half an hour and it's only done 5%. In that time I'd installed and configured a couple of Linuxes and at least one Vista. Not to mention what I could do in the remaining 95% of the upgrade :P
blake said…
I think the great advantage of lupgrade is that it doesn't mess with your known working install at all. on a machine with a lot of old/poorly documented configs, this is a lifesaver. not every admin has the time to fix all the problems that come with an update - sometimes it's easier to just revert to the old, known-good boot environment before your maintenance window expires. we *are* all using maintenance windows, right? :)

Popular posts from this blog

SP (nanomsg) in Pure Go

An important milestone

GNU grep - A Cautionary Tale About GPLv3