Updating to a New TL or Service Pack? Call This Doc

Edit: I love that this document is still available.

Originally posted March 18, 2008 on AIXchange

I think you’ll find this IBM support document quite useful. It explains how to upgrade to a new technology level or service pack in AIX.
 
The document describes the recommended processes of updating your system to a new technology level or adding a service pack to an existing technology level. I’ll review some key words and terminology, run through recommended pre-checks, discuss the update_all process using both SMIT and command line and, finally, cover post-checks and FAQ.

Let’s start with the pre-checks. As noted in the document:

“It is recommended to have at least one back-out method available to you in case a restore is required. Recommended back out methods include: mksysb restore, sysback restore, altinst_rootvg clone, and multibos.”
 
This paragraph makes it pretty clear: Do not reject applied filesets with a TL update–use another back-out method if things don’t work out. Be sure to update test machines before production, and actually run tests to ensure that things work as expected on the test machines.
 
The document also tells you how to perform operations like boot image verification and conduct firmware, fileset consistency and free space checks. Then, under the Post Checks heading, is this statement:
 
“Presuming your update_all was successful you will want to check the following commands. If you receive unexpected output please contact the support center for assistance.

# oslevel -r
This should return with the expected TL output

# oslevel -s
This should return with the expected TL and SP output.

# lppchk -v
This should come back ideally with no output.”
 
And be sure to check out the FAQ section. There are some good questions (and answers) here. For instance:
 
Q: Is it okay to install my Technology Level in the “APPLIED” state ? Doesn’t that let me reject them if there is a problem?

A: With the introduction of Technology Levels and the “all or nothing” packaging format, these updates are bringing in on the upwards of 400+ fileset updates for each TL. Attempting to perform a “reject” process on so much code simply doesn’t work well. Recommended back-out methods are discussed earlier in this document.

Q: Does the same hold true for Service Packs?

A: The Service Pack updates are certainly much smaller groups of updates….typically numbering around 40-50 per update. While you certainly will have a better chance of successfully rejecting a 40 filesets instead of 400, it would still be best to have one of the back-out methods mentioned earlier.
 
Q: I need to run my update today but I won’t be able to reboot until next week. Is that a problem?

A: Plans should be made to reboot as soon as the update is complete and checks have been made to ensure there were no failures. System files will have been replaced, but the corresponding kernel and library updates will not be loaded until boot time. You will likely encounter problems if you delay rebooting.
 
Q: Is it recommended to reboot before issuing a TL upgrade?

A: If this is possible, absolutely. There are systems out there that haven’t been rebooted in over a year or more. Who is to say that something hasn’t happened in that time that simply wouldn’t show up until a reboot. Rebooting the system first assures a good boot image, a stable system, and would isolate any problem that normally wouldn’t be caught until the post-update reboot as either a preexisting issue, or an issue directly related to the TL update itself.

Q: Some say to use base AIX install media when updating the TL, others say the TL fix downloads or CDs should be used. Which is right?

A: The recommendation is to use the TL fix downloads from FixCentral, or the TL CDs that can be ordered either online or from AIX SupportLine. You can also use the base AIX installation media, however without getting into a long answer, the recommendation is using the TL fix packages.
 
Q: Is it okay to run the update_all while people are online?

A: Updating could affect running processes. As such, applications should be down and users offline as a general rule.

Even though I’ve quoted a lot here, I suggest you read the whole thing. And, as is noted throughout the document, feel free to contact IBM support with any questions.
 
I’m always on the lookout for good documentation, recommendations, cookbooks and the like. Whenever I find something, I’ll be sure to mention it here.