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.
December 2, 2007 at 11:24 AM
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.
December 2, 2007 at 12:06 PM
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 :-)
December 5, 2007 at 4:24 AM
pbaldanta said…
Hi,

I guess that during luactivate, there are several script files changes regarding boot device into eeprom and something like that.
January 18, 2008 at 7:28 AM
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...
March 28, 2008 at 4:40 AM
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!
March 28, 2008 at 8:59 AM
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
July 2, 2008 at 4:33 AM
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? :)
January 8, 2009 at 2:11 PM
Post a Comment

Popular posts from this blog

An important milestone

Yesterday, with very little fanfare, illumos passed an important milestone. This milestone was the integration of  195 Need replacement for nfs/lockd+klm This is work that I originally tasked Gordon Ross and Dan Kruchinin to work while we were colleagues at  Nexenta .  Gordon started the work, picking up bits from FreeBSD as a starting point and gluing it to the illumos entry points.  Dan continued with it, and fleshed out a lot of the skeleton that Gordon had started.  It was subsequently picked up by the engineers at Delphix , and -- after some important bug fixing work was completed -- was integrated into their product quite some time ago -- reportedly its been stable since December in their product. The reason this is such an important milestone, is two fold: First, this represents a substantial collaborative effort, involving contributions from parties across several organizational boundaries.  The level of collaboration achieved here is a win for the greater good of th
Read more

GNU grep - A Cautionary Tale About GPLv3

My company, DEY Storage Systems , is in the process of creating a new product around the illumos operating system.  As you might imagine, this product includes a variety of open and proprietary source code.  The product itself is not delivered as a separate executable, but as a complete product.  We don't permit our customers to crack it open, both from the sense of protecting our IP, but also to protect our support and release engineering organizations -- our software releases consist only of a single file and we don't supply tools or source for other parties to modify that file. One of the pieces that we wanted to integrate into the tree is an excellent little piece of software called Zookeeper , produced by the Apache organization.  Like illumos, Zookeeper has a nice non-viral copyleft license, which makes it nice for integration into our product. However, I discovered that as part of our integration, one of my engineers had decided to integrate GNU grep.  Why? Becaus
Read more

The Hand May Be Forced

Well, as you may have read , Oracle has decided that at some point very soon, we're going to lose normal regular access to the source code for OS/Net. (I.e. the Solaris kernel and supporting programs.) While I would have vastly preferred for Illumos to have a cooperative and collaborative relationship with Oracle , it appears that Oracle doesn't value this. In fact, the exact words were from the management at Oracle were as follows: Solaris is not something we outsource to others, it is not the assembly of someone else’s technology, and it is not a sustaining-only product. While I understand the need to own the technology, there are few things that could be stated that show a stronger NIH attitude than this. Its unlikely that there will ever be a way for Oracle and the greater community to have a collaborative relationship. This is a dark day for OpenSolaris -- its effectively dead now. (Its parent, Solaris, lives on however.) How unfortunate. For Oracle that is. Because
Read more