LIve Upgrade from Solaris 10 11/06 to 8/07 without nonglobal zones

Live Upgrade is one of the most useful Solaris features, yet in my travels around the US I still don't see it used as much as I would like. I can think of several reasons for this - not all of them totally valid
  • I tried it once a long time ago and a patch or package that wasn't LU aware messed up my current boot environment. Not valid for Solaris components although we do see the occasional partner product with this problem. The last one I saw was the NVidia driver, and the good folks from NVidia fixed it very quickly once reported.
  • The documentation can be a bit intimidating. Valid with a capital V. But Live Upgrade is an amazingly flexible feature, so at some point you do have to describe these capabilities. As a guide through this documentation, several folks have blogged managable howto guides. You can find mine back in March 2007, although I've recently updated it. And there are other good blogs with plentry of examples. There is a very good Blueprint on Live Upgrade.
  • It doesn't work with the Veritas Volume Manager.
  • I didn't know about Live Upgrade. Well, you do now. But I have noticed that a lot of the Solaris conversation is focused on new features, like ZFS, Zones, SMF, DTrace and some of the older features like Flash archives and Live Upgrade don't receive the attention they deserve. The simple fact is that Live Upgrade takes all of the pain out of the patching process, at least once you know what to patch.
And I'm sure there are other reasons, but these are the ones I hear most often.

Let's turn our attention to the topic at hand, upgrading a Solaris 10 11/06 system to 8/07, without zones. This example will be on an x64 system, but the SPARC approach is simular.

If you have read my earlier blog on Live Upgrade, you will recall the process is
  1. Read Infodoc Infodoc 72099 and install any required patches
  2. Install the LU packages SUNWluu SUNWlur and SUNWlucfg (if present) from the installation media
  3. lurename(1m) if you want to change the name of your new boot environment
  4. lumake(1m) or ludelete(1m) + lucreate(1m) to repopulate the target boot environment with the proper software and configuration files
  5. luupgrade(1m) to upgrade the target boot environment
  6. luactivate(1m) to activate the new boot environment
  7. init 0 to perform the file synchronization and conversions, create the new boot archive and update your GRUB menu


So I fire up my web browser and run over to SunSolve to pick up Infodoc 72099 and see a rather large set of patches. And there are two lists, one for systems with non-global zones and one without. Since we're looking at a system without non-global zones we will start with the shorter of the two lists (the next article will cover systems with nonglobal zones).

Apparently we need patches
	 
Solaris 10 	x86 	118816-03 or higher 	nawk patch 	 
Solaris 10 	x86 	120901-03 or higher 	libzonecfg patch 	 
Solaris 10 	x86 	121334-04 or higher 	SUNWzoneu required patch 	 
Solaris 10 	x86 	119255-42 or higher 	patchadd/patchrm patches 	 
Solaris 10 	x86 	119318-01 or higher 	SVr4 Packaging Commands (usr) Patch 	 
Solaris 10 	x86 	117435-02 or higher 	biosdev patch for GRUB Boot 	 

Reboot after installation 	 

Solaris 10 	x86 	120236-01 or higher 	SUNWluzone required patches 	 
Solaris 10 	x86 	121429-08 or higher 	SUNWluzone required patches 	 
Solaris 10 	x86 	121003-03 or higher 	pax patch 	 
Solaris 10 	x86 	123122-02 or higher 	prodreg patch 	 
Solaris 10 	x86 	121005-03		sh patch 	 
Solaris 10 	x86 	119043-10		/usr/sbin/svccfg patch 	 
Solaris 10 	x86 	121902-02		i.manifest r.manifest class action script patch 	 
Solaris 10 	x86 	120901-03		libzonecfg patch 	 
Solaris 10 	x86 	120069-03		telnet security patch 	 
Solaris 10 	x86 	120070-02		cpio patch 	 
Solaris 10 	x86 	123333-01		tftp patch


Hmmm, seems like a lot of patches and a required reboot! So I fire up our new friend updatemanager to patch my system. I see that there is a new updatemanager patch available (121119-13), so I installed that one all by itself and restarted updatemanager.

I soon realize that my choice of patching tools is making this a bit challenging. Users of patch tools such as Patch Check Advanced(PCA) may have an easier time, but I was determined to do this with updatemanager, with occasional help from the patch READMEs in SunSolve.

The list of patches required for this upgrade applies to any release of Solaris 10. A fresh install of a Solaris 10 11/06 system only needed the following four patches - which is a lot better than I first thought.
	 
119255-42	 
121429-08
126539-01 as it replaces the required 121902-02
125419-01 as it replaces the required 120069-03
The difficulty with updatemanager was with the set of obsoleted patches. Something like the required 121902-02 that was obsoleted by 126539-01 which was installed took a bit of manual trolling through patch READMEs. So I'll save you the research - it came down to only the four above patches.

One important note: the required reboot after patch 117435-02 wasn't needed after all - so I'll try to save all of you Solaris 10 11/06 users one reboot. While I have your attention, it is a good idea, if not a best practice, to install patch and packaging patches separately.

Feeling a lot better about this process, I proceed and install the four required patches using updatemanager in two steps (119255-42 and then the other three patches) and all succeeded, as expected. All that was left to do was finish the standard procedure
# mount -o ro -F hsfs `lofiadm -a /export/iso/s10u4/solarisdvd.iso` /mnt 
# pkgadd -d /mnt/Solaris_10/Product SUNWlur SUNWluu SUNWlucfg 
# lurename -e nv71 -n s10u4 
# lumake -n s10u4 
# luupgrade -u -s /mnt -n s10u4 
# luactivate s10u4 
# init 0 


And all went as expected. Next time I will tackle the longer list of patches and examine the same upgrade path, but with nonglobal zones.

Technocrati Tags:
Comments:

here is one that IS valid... VxVM takes up some slices on its own.. you're now OUT OF SLICES for live-upgrade....

Also, last I checked the VxVM integration is ANYTHING but clean, as in you basically have to unencapsulate/unmirror your environment so you can attempt LU, followed by a re-encapsulate/mirroring effort after the fact.

Could you confirm if the 2nd point is still valid?

Posted by guest on October 05, 2007 at 10:07 AM CDT #

When's the article about upgrading with non-global zones due? I'm really looking forward to that!
Thanks

Posted by Mark on October 22, 2007 at 02:09 AM CDT #

"It doesn't work with the Veritas Volume Manager"

Not exactly true! I found a way to let LU work with Veritas encapsulated booting env. The boot and alt-boot envs are all Veritas encapsulated, LU can recognize them both without no issue, lumake/lucopy to sync up these two booting envs,
luupgrade -t -n to on-the-fly OS patch the alt-boot env with NO issue.

we have hundreds of veritas encap boxes, group engineers feel alright to handle this.

down everything for 3 hours just for OS patching? with LU, the answer is NO.

Posted by Ming Fan on February 05, 2008 at 05:09 AM CST #

Bob

Have you been successful in using Live Upgrade with servers configured with Veritas Volume Manager?

Have you tried creating a FLAR on the fly on a server configured with VVM, that is without un-encapsulating the root drive?

Thanks,
Bret

Posted by Bret Justus on April 17, 2008 at 11:02 AM CDT #

It might help to describe what you are doing in the commands you entered, correct me please if I am wrong but my understanding is this:
# lurename -e nv71 -n s10u4 You rename the BE nv71 to s10u4. Question: when and how was the BE nv71 created?
# lumake -n s10u4 The man page of lumake suggests that the target BE must already exist and to create it using lucreate, when and how was lucreate used?
so you are copying files from the current BE to the new BE s10u4, am I correct?
# luupgrade -u -s /mnt -n s10u4 -u to upgrade an os image, -s to specify source -n name of BE to be upgraded
# luactivate s10u4 activates the new BE

My questions: What are the prerequisites of a liveupgrade to upgrade to the next solaris release, do I need an additional disk identical to the current system disk? Do I need a slice with enough free disk space?
Please advise. dariusz.dolecki@gmail.com

Posted by Dariusz Dolecki on October 17, 2010 at 10:30 AM CDT #

do I have to rum lumake after running lucreate - does not lucreate copy the files?

Posted by darius dolecki on October 17, 2010 at 01:12 PM CDT #

Hi Dariusz,

Thanks for the question. Reading this one blog by itself, I understand where the confusion comes in. It was really meant as part 2 of an earlier blog.

In this example, I had already rebuilt all of my boot environments, so it was easier to just rename it than to go through the create process. This would be true if you had a configuration with a huge number of LUNs, or was being lazy, like I was being.

You are right, the nv71 boot environment already existed. In a real case, you should delete the old boot environment with ludelete and create a new one with lucreate (which will populate it with the right files, or in the ZFS root case, make a clone of the source).

So, no - don't run lumake after the lucreate. All lumake does is repopulate the boot environment, which would be useful after a rename. In the ZFS root case, lumake is totally unnecessary.

Perhaps the presentation the Gerry Haskins (blogs.sun.com/patch) and I did for Oracle Open World might be more helpful. You can find it at http://blogs.sun.com/patch/resource/Oracle_Solaris_Patching_Best_Practices_final.ppt

There's also a pretty good document be Enda O'Connor at http://blogs.sun.com/patch/resource/luzones.pdf

For your last question, what do you mean by next Solaris release ? If you mean an s10 update (like Solaris 10 9/10) then you just need a slice big enough to hold the new boot environment. If you are using ZFS as your root file system, the new boot environment can be in the same root pool and you only need free space to hold the differences between the boot environments.

If you are asking about Solaris 11, there is no easy upgrade path at the moment. My blog was written when SXCE was still SVR4 package based. Since it has moved on to IPS, the upgrade path is a bit more complicated.

Posted by Robert Netherton on October 18, 2010 at 02:15 AM CDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Bob Netherton is a Principal Sales Consultant for the North American Commercial Hardware group, specializing in Solaris, Virtualization and Engineered Systems. Bob is also a contributing author of Solaris 10 Virtualization Essentials.

This blog will contain information about all three, but primarily focused on topics for Solaris system administrators.

Please follow me on Twitter Facebook or send me email

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today