IBM Support

Updating to a new Technology Level or Service Pack

Question & Answer


Question

What is the recommended process for updating to a new Technology Level or Service Pack in AIX?

Answer

-- Updating to a New Technology Level or Service Pack --


Update_All in AIX

This document describes the recommended preparation and process used when updating your system to a new technology level or adding a service pack to an existing technology level. First, we review some keywords and terminology, run through recommended pre-checks, discuss the update_all process when using both SMIT and command line, and finally, post-checks & FAQ.

Key Words and Terminology:
V.R.M.F. (Version, Release, Maintenance Level, Fix Level)
This format represents your operating system level and is mentioned because of the change made in the 5300-07 technology level update. Previous to 5300-07 updates are recognized by their last numerical level entry only.
Ex.
bos.rte.install 5.3.0.60

Beginning with 5300-07 the 3rd number, or “Maintenance Level” number is also included and represents the Technology level of the fileset, followed by the “Fix Level”.
Ex.
bos.rte.install 5.3.7.0
*The “Fix Level” entry does not necessarily represent the “Service Pack” level. Any similarity is simply coincidental.

Oslevel
There is also a change to how the operating system level is presented. With the introduction of 5300-06, more information is provided by the ‘oslevel’ command.
 
# oslevel -s
6100-06-06-1140

The addition of the last four digits simply represents the year (11) and week (40) of the release of your technology level and service pack (-06-06).

Update_all
This installation method is recommended for updating your technology level or service pack level. It is not to be used when updating the version or release level of your operating system.
Ex.
6100-0x to 7100-0x - do NOT use update_all
7100-0x to 7200-0x - do NOT use update_all

For information on updating your (V)ersion or (R)elease of AIX see this document:
http://www.ibm.com/support/docview.wss?uid=isg3T1011431

Recommended Pre-Checks:
1. The back-out
It is recommended to have at least one back-out method available to you in case a system recovery is required. Recommended back out methods include: mksysb restore, Sysback restore, altinst_rootvg clone, and multibos. More information on any of these back-out methods can be found at the Publib documentation site by using this link to click through to the appropriate Infocenter and search features found here:
https://www.ibm.com/docs/en/aix

2. Boot Image Verification
The hd5 logical volume holds your boot image. There are a few checks to make against your boot image before you start your update_all process.
First, find out which disk contains your hd5 logical volume.
 
# lslv -m hd5
hd5:N/A
LP    PP1  PV1
0001  0001 hdisk1

The listing under the “PV1” column indicates on which disk hd5 is located. Any other entries under “PV2” and so on, simply represent mirrored copies.

Next, verify that your boot image can be successfully re-created by using the hdisk# from the previous command and by using /dev/ipldevice.
 
# bosboot -ad /dev/hdisk0
bosboot: Boot image is 35795 512 byte blocks.

# bosboot -ad /dev/ipldevice
bosboot: Boot image is 35795 512 byte blocks.

If either of these two commands fail for any reason, call the support center for resolution before proceeding.

Finally, with the continual introduction of new devices and hardware the boot images are growing larger. You want to make sure your hd5 logical volume has enough free and contiguous space to hold the boot image. Currently, the recommended allocated space to have for hd5 is a minimum of 64 megabytes. This issue is of concern in environments with smaller disk sizes, and needs to be checked before performing an update.
 
# lsvg -l rootvg | grep hd5
hd5                 boot       1       1       1    closed/syncd  N/A

# lsvg rootvg | grep SIZE
VG STATE:           active                   PP SIZE:        32 megabyte(s)

The single partition is 32 megabytes in size. This space is usually enough to contain the boot image. Smaller partition sizes require more partitions to be allocated.

Your hd5 partitions also need to be contiguous partitions. Check by running the following command:
# lspv -M hdisk0 | grep hd5
hdisk0:1        hd5:1
hdisk0:2        hd5:2
hdisk0:3        hd5:3

You can see in this example that the hd5 logical volume covers the first 3 partitions on the disk and they are all contiguous. If your partitions are not contiguous, or are not on the first partitions of the disk, call the software support line for assistance with correcting it.

Again, it's possible to have only one partition that is large enough to contain the boot image, or you might have multiple smaller partitions.

3. Firmware
It is recommended to check and update the firmware level when a technology level update is being considered. In general, it's best to apply firmware updates before software updates, but that is not always the case. Always refer to the firmware download site installation information and follow those instructions.
You can access the firmware download site here:
http://www.ibm.com/support/fixcentral/

If there are any questions about the firmware update, installation instructions, or if there are software considerations you can contact the hardware support center first.

4. Fileset Consistency
Run the following command to check fileset consistency:
# lppchk -v

Ideally, it returns to the command line with no output. If you receive output and are unfamiliar with how to resolve it, call the support center for assistance before running your update.

5. Space
To see whether you have enough space for your update, you can run the update_all operation in preview mode. The preview output includes an estimated system resources list of the necessary space. You first need to install the bos.rte.install fileset from the update package. Here are two examples of how to update this fileset, so a preview update_all can be executed. The next example shows the command for “committing” the bos.rte.install update. If you would feel more comfortable using the “apply” feature, you can.

From an unmounted cdrom device (cd0).
# installp -acd /dev/cd0 bos.rte.install

From a download directory (/fixes/6100-06)
# installp -acd /fixes/6100-06 bos.rte.install

Using SMITTY
# smitty install_latest
* INPUT device / directory for software              [/dev/cd0]
* SOFTWARE to install                                [bos.rte.install]
  PREVIEW only? (install operation will NOT occur)    no

Once the installation is complete, you can then run the preview operation for the remaining filesets to get an estimate of the required space for your update.
 
# smitty update_all
* INPUT device / directory for software              [/dev/cd0]
* SOFTWARE to update                                  _update_all
  PREVIEW only? (update operation will NOT occur)     yes

The preview shows something similar to the following regarding the space requirements:
RESOURCES
---------
  Estimated system resource requirements for filesets being installed:
                (All sizes are in 512-byte blocks)
      Filesystem                     Needed Space             Free Space
      /                                     402                 239312
      /usr                                94352                 165440
      /var                                    1                 237384
      /tmp                                52304                 259240
      /opt                                 6648                 158576
      -----                            --------                 ------
      TOTAL:                             153707                1059952
Running the update by using SMIT or command line:
This section covers the update_all process. In all cases, the “input device” (location of the software) is referred to as being a local cdrom drive (/dev/cd0). You can always use a download directory or NFS mount point, simply substitute the input device as necessary. This process is also executed presuming that you are logged in as root (as opposed to using ‘sudo’).

1. SMITTY:
By menu selection options you would take the following path:
# smitty
  Software Installation and Maintenance
  Install and Update Software
  Update Installed Software to Latest Level (Update All)

-or use the fastpath-
 
# smitty update_all

* INPUT device / directory for software              [/dev/cd0]
* SOFTWARE to update                                  _update_all
  PREVIEW only? (update operation will NOT occur)     no
  COMMIT software updates?                            yes
  SAVE replaced files?                                no
  AUTOMATICALLY install requisite software?           yes
  EXTEND file systems if space needed?                yes
  VERIFY install and check file sizes?                no
  DETAILED output?                                    no
  Process multiple volumes?                           yes
  ACCEPT new license agreements?                      yes
  Preview new LICENSE agreements?                     no

The only required change would be the option for “ACCEPT new license agreements”. All other defaults remain as they are. Pressing <Enter> here brings up a confirmation dialog box to which you press <Enter> again. The only other interaction that you might have is to switch out a volume of the media package, if necessary. When complete, the upper left corner “Command:” field results in one of two outcomes:

OK: Your installation completed without error. You can either scroll down or exit out and view the smit.log file in the root user's home directory for the log of the installation.

FAILED: One or more filesets failed for some reason. Review the output from the update by either scrolling down in the smit screen, or exit out of smit and view the smit.log file in the root user's home directory for the log of the installation. Take corrective action before rebooting the system.

2. Command line:
Use the ‘install_all_updates’ command when opting to perform the update from command line.
This command has a man page, so feel free to review the flags, however it is intended to be easy to use, so running a basic update is simple.
 
# install_all_updates -Y -cd /dev/cd0

Once complete, the log of the installation is found in the /var/adm/ras/install_all_updates.log file. By default, the fileset updates are installed in the “APPLIED” state. The "-c" flag of the install_all_updates command specifies that all filesets install in the “COMMITTED” state. For more information about the "APPLIED" vs "COMMITTED" states, see the FAQ at the end of this document.


Post checks:
Presuming your update_all was successful, you want to check the following commands. If you receive unexpected output, contact the support center for assistance.
* See FAQ statement 11 and 11a regarding post-update_all issues.
 
# oslevel -r
This command should return the expected TL output
# oslevel -s
This command should return the expected TL and SP output.
# lppchk -v
This command should produce no output.

 
FAQ and Opinions
This section contains the most commonly asked questions and a few recommendations concerning the update_all procedure. Most answers are kept short and to the point (as much as possible).

1. Is it okay to install my Technology Level in the “APPLIED” state? What if I want to reject the TL update if there is a problem?
With the introduction of Technology Levels and the “all or nothing” packaging format, these updates are bringing in upwards of 400 fileset updates for each TL. Attempting to perform a “reject” process on so much code simply does not work well, and is not supported. Recommended back-out methods are discussed earlier in this document. Also, refer to the "AIX Service Strategy and Best Practices" at https://www.ibm.com/support/pages/node/3464613.

1a. Does the same hold true for Service Packs?
The Service Pack updates are much smaller groups of updates, typically numbering around 40-50 per update. While you certainly have a better chance of successfully rejecting 40 filesets instead of 400, it would still be best to have one of the back-out methods mentioned earlier.

2. Can I update multiple TL or SP levels at once, or do I need to perform multiple updates incrementally?
TL and SP updates are cumulative, so you can update to a new SP within the same TL, for example 7200-04-01 to 7200-04-05, in one step. You can also update to a higher and newer TL/SP combination in one step, provided you include the TL requisite when you download the SP from Fix Central. For example, you can update from 7200-02-05-1938 to 7200-05-02-2114 since it is both a higher TL and SP level and has a newer build date.

3. The update_all failed. What now?
Do not reboot. You can review the log to find out what failed and why. If you are comfortable and familiar with these situations, you can correct the failures and update the filesets again. If not, call AIX Support and open a case for assistance. Have the log available to submit if necessary.

4. I need to run my update today but I might not be able to reboot until next week. Is that a problem?
Plans should be made to reboot as soon as the update is complete and you have checked to ensure there were no failures. System files will have been replaced, but the corresponding kernel and updated libraries will not have been loaded until the system is booted. If you delay rebooting, these inconsistencies will likely cause problems.

5. Is it recommended to reboot a system before performing a TL update?
If a reboot is possible, absolutely. Some systems have not been rebooted in a year or more. It's possible that a change was made to the system in that time that prevents the system from booting. Rebooting the system before updating it assures a good boot image, a stable system, and helps to isolate a problem that might not be caught until the post-update reboot. Problems rebooting the system could arise from a preexisting issue, or an issue directly related to the TL update itself.

6. Some say to use base AIX installation media when updating the TL, others say the TL fix downloads should be used. Which is right?
The recommendation is to use the TL fix downloads from FixCentral. However, you can also use the base AIX installation media. Without getting into a long answer, the recommendation is using the TL fix packages.

7. How long does the update_all take?
There is no definite answer. The length of time required for the update_all depends on how many filesets are being updated as well as the available system resources such as processors and memory.
However, giving an approximate figure, going up one TL takes about 30-60 minutes plus reboot time. Some admins prefer to be more on the conservative side and block a 2-3 hour downtime. Also, consider the amount of time that it would take to restore, should it become necessary, using the backup method selected.

8. Is it okay to run the update_all while people are online?
Updating could affect running processes. As such, the best practice is to stop applications and have no users online.

9. Where can I download new service packs or technology levels?
TL and SP updates can be acquired from the FixCentral website located here:
https://www.ibm.com/support/fixcentral/

10. Will product X at level Y.Z work with my new technology level?
Some products might be certified only up to a certain operating system level while other products might require an update. The best thing to do would be to contact product X's support center. If it is an IBM product, feel free to contact our support center and open a case requesting to speak to the product X team. Any 3rd party products need to be cleared by their support before the update.

11. The 'oslevel -s' and/or 'oslevel -r' commands do not report what I expect after the update. How can I determine what is missing?
If your 'oslevel' commands do not report the expected level after your update_all, use the "-l" flag to determine which filesets need to be updated in order to complete the update.
The syntax:
# oslevel -rl <level>
# oslevel -sl <level>

Example:
# oslevel -rl 6100-01
-or-
# oslevel -sl 6100-00-01-0748

The filesets listed show an "Actual Level" heading (your current level) and a "Maintenance Level" heading (the level that you need to have installed to satisfy the TL or SP). Once all of the filesets are installed at the level required by the TL or SP that you are updating to, the oslevel command reports the new level.

11a. Some filesets occasionally require multiple update_all operations.
There are cases where a second update_all operation needs to be executed to pick up the full TL update. This behavior is not defective. This tip is not intended to resolve a "FAILED" status of your update_all. If you notice that your TL update was successful, but some filesets did not get updated and are on your media or in your download location, you might need to run the update_all a second time to pick them up. Most of the time, it is documented in the Installation Tips document, which is available by clicking the Installation Instructions link for the TL or SP that you are installing on Fix Central.

12. What are other best practices with regards to keeping the AIX operating system updated?
IBM maintains a best practices site for service and support for Power Systems.
Visit https://www.ibm.com/support/pages/service-and-support-best-practices-power-systems for more information.


If there are other questions that you would like to see in this FAQ, feel free to submit feedback with the question, and it might be added.

[{"Type":"MASTER","Line of Business":{"code":"LOB08","label":"Cognitive Systems"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG10","label":"AIX"},"ARM Category":[{"code":"a8m0z000000cvoiAAA","label":"Install"}],"ARM Case Number":"","Platform":[{"code":"PF002","label":"AIX"}],"Version":"All Versions"}]

Document Information

Modified date:
19 May 2023

UID

isg3T1010755