Installing technology levels and service packs for AIX
In 2006, all the rules changed with respect to operating system upgrades in AIX. Even the nomenclature has changed from maintenance level (ML) to technology level (TL). Is this just a rebranding or are there substantive changes here? What about best practices? When should you deploy technology- (maintenance) level upgrades? Furthermore, what is the best way of retrieving upgrades, service packs, and fixes? Finally, how do you actually perform a TL upgrade?
This article explains all of these concepts and discusses recent changes to the upgrade methodology. In doing so, you'll review important new concepts such as the Concluding Service Pack (CSP), which is the final service pack of a TL. You'll even walk through an actual upgrade of a system where you'll be working with systems such as the IBM® Service Update Management Assistant (SUMA) and Fix Central. SUMA helps the systems administrator automate the retrieval of AIX updates. Fix Central is the Web-based central repository for all TLs, services packs, and fixes, including hardware firmware. Finally, you'll learn the rationale in determining when you should deploy a TL upgrade.
Technology level overview
Although some systems administrators still use the term "maintenance level" when discussing their AIX version, the term is now reserved for legacy AIX systems. The new IBM methodology dictates two TL releases per year. The first TL includes hardware features, enablement, and software services. The second includes software features in the release, which means the second release is larger and more comprehensive. Finally, there is also now support for new hardware on older TLs.
Historically, new hardware was only supported in new technology releases, which obviously required an upgrade to the new level. The way AIX now supports new hardware is broken down into two categories. The first category is support. First, AIX has actually undergone changes allowing it to recognize new hardware at boot time. Changes to support the new hardware include, at a minimum, updates of tables that are referenced at boot. These determine the processor type and how to create new boot media. The second category is referred to as exploitation, which requires AIX to undergo more pervasive changes to the operating system, such as changes to the Virtual Memory Manager (VMM) to exploit new pages sizes. This new release strategy was first implemented in 2007, starting with AIX V5.3 TL6, which was the first level to have two-year support.
Service pack overview
What about service packs? A service pack (SP) contains groups of Program Temporary Fixes (PTF)s for highly pervasive issues. Service packs are cumulative and are generally released every four to six weeks after the release of a new TL. Service packs can include any of the following:
- Customer-reported problems that can't wait until the next TL.
- Critical problems reported by development teams.
- Limited changes to support new hardware, such as device drivers' kernels changes to reflect a new processor. These are changes that do not add new functionality. New functionality will only be added for TLs or new releases. SP release schedules are approximately every four to six weeks.
So, what happens between service packs? Interim fixes, sometimes referred to as fix packs
or temporary fixes, or stand-alone PTFs, are made available for relief until the time
that the fix becomes available in a service pack. It's what IBM calls "temporary relief."
They are tracked on the system with either the
lslpp -L command or
emgr -l command.
Security updates, published through advisories, are made available by IBM through subscription services.
Concluding service packs
Another important concept to understand is the Concluding Service Pack (CSP). The CSP is the final service pack for a TL. It usually contains fixes for critical problems or security issues. The new strategy also includes a longer period of support for each OS TL. Each TL will now be supported for up to a two-year period. This means that you can continue to call IBM support for up to a two-year period (from the introduction to the update) without having to move up to the latest TL. The new server update strategy also promises improved serviceability throughout the life of TL. This is done by allowing you to maintain your operating system by installing service packs and PTFs throughout the entire lifecycle of the TL.
Automating TLs and service pack deployments with SUMA
The IBM Service Update Management Assistance (SUMA) is an extremely important system because it allows you to automate the retrieval of TL and service pack deployments. In this section, you're going to use SUMA to retrieve TLs. SUMA was first released with AIX V5.3. More than anything, SUMA helps the system administrator automate the retrieval of AIX updates, allowing the administrator to get away from the mundane tasks of manually retrieving updates from the Web. Furthermore, it allows you to configure policies to automatically download either entire TL upgrades, service packs, or even interim fixes. The primary objective of the utility is to allow systems administrators to spend more time on proactive systems administration and less time on redundant or tedious work such as downloading updates.
So, how do SUMAs work? Essentially, they use a scheduling module that allows policies to be run at predefined intervals, which conform to your maintenance window. The policies can be configured easily without any extensive configuration. You even have the option to manually run SUMA (either from smit or the command line) to bring in whatever updates you require. To configure SUMA, you need to know the fix type. There are eight different kinds of fix types. They include APAR, PTF, Critical, Security, I/O Server, Latest (all fixes), Filesets (specific types), and Maintenance Levels. In addition, there are three types of actions you can perform on a policy. These include preview, download, and download and clean. Preview mode does not really do anything; it just generates a preview of what would be downloaded. The "download only" action downloads the actual data, while the "download and clean" action removes filesets no longer necessary after a new fix level has been brought down. This limits the size of the data that you'll need to keep.
You can run the suma command from either smit or the command line. In the first example,
use smit to download an entire TL:
# smit suma.
When the smit screen comes up, choose Download Updates Now (easy) and click Enter.
Figure 1. Downloading updates from the smit screen
From this screen, scroll down to Download Maintenance Level or Technology Level and click Enter (see Figure 2).
Figure 2. Selecting Download Maintenance Level or Technology Level
At the window in Figure 3, click F4 and choose the appropriate TL level.
Figure 3. Choosing the appropriate TL level
In this case, it is 6100-01, as shown in Figure 4.
Figure 4. TL level of 6100-01
Click Enter and let it run. When it completes, you'll see a summary, as shown in Figure 5.
Figure 5. Summary page
This provides you with the following summary:
- 59 downloaded
- 0 failed
- 36 skipped
Now try it from the command line. In this case, you're going to download TL Two for AIX
V6.1. Do this by running the
suma -x command (see Figure 6).
Figure 6. Running the
suma -x command
After about 30 minutes, it completes successfully (see Figure 7).
Figure 7. Command completed
The files get installed in /usr/sys/inst.images, which is where you would also manually put them if you were to retrieve them using different processes.
Why is SUMA important? Perhaps most importantly, it helps to ensure that your systems have the latest patches that it needs. Current fixes are important. Secondly, it downloads the patches without intervention, which allows the systems administrator to focus on more important tasks.
This section reviews Fix Central and discusses how to use it to download TL and service pack deployments. Fix Central is the central repository for all TLs and service packs for AIX. Among other things, you'll see how to log into Fix Central and retrieve service packs. Completely revamped in October of 2007, it provides fixes and updates for all your software, hardware, and operating systems. This includes the Hardware Management Console (HMC). Using Fix Central, you can download using the following options: by APAR, Fix ID, or Test. In addition, there are three download options, IBM Download Director, HTTP, and FTP.
Download a service pack from the exact TL that you downloaded previously during the work with suma from the command line -- 6100-02. First go to Fix Central for System p®, as shown in Figure 8 (see Related topics for a link to Fix Central).
Figure 8. Fix Central for System P
From here, in the drop-down menu, choose your version. Another drop-down menu pops up, which is where you can select from one of the following: fix packs, fix recommendations, fix search, managing updates, and security advisories. Choose fix pack. Click Continue (see Figure 9).
Figure 9. Choosing Fix packs type
From here, select the TL: 6100-02. At this time, you can either download the latest service pack or the entire TL. Choose the entire TL (see Figure 10).
Figure 10. Choosing the entire TL
The options for download include Download Director, bulk FTP, or CD. In this case, use Download Director. I recommend this method because it has a friendly interface and there is also flexibility to pause downloads.
Figure 11. Download Director
The length of time is dependent on your Internet connection. For me, on broadband, this took roughly an hour.
As a systems administrator, the Fix Central URL should definitely be one of your browser favorites. Fix Central helps you keep your systems up to date and is the best method of manually retrieving data for your upgrades. You really can't be an effective AIX systems administrator without knowing how to use this tool.
Upgrading a TL
Now review the procedures to upgrade your system to the next TL.
First log in as root:
# su - root. Make sure you back up your system. If you
prefer, you can also use alt_disk_install or multibios; the bottom line is that you need
to have a plan B if you must go back to your prior level. You should also commit them,
because they can't be rejected and they also make it easier to track and reject PTFs.
Do a backup using the following command:
# mksysb. When the backup is
completed, you're set!
Create a .toc file. This is done by running the inutoc command (see Figure 12). You run this in the directory where your filesets reside. If you don't have the .toc file, your update will not work.
Figure 12. Running the inutoc command
When this is completed, you are ready to start the upgrade. Move to the directory where
your .toc file resides. If you do this, you will not have to specify a path name during
# smit update_all.
On the screen in Figure 13, you will be making several changes.
Figure 13. Update software screen
For Input device/directory for software, put in the dot (.). If you remembered to cd to the directory that has the .toc file, you don't need to specify the full path name. In this case, you did not commit the software, though as a practical matter because you can't back out of a TL upgrade, you really should say yes to limit the amount of filesets stored on your system -- a real disk hog. In this case, you first previewed the data to ensure that there would not be any problems. This is the third option on this smit menu (shown in Figure 13). The preview option does nothing except validate whether something might be missing as a prerequisite of the upgrade. This is good to do to avoid surprises. You don't want to find out something is missing during your two-hour maintenance window of the month. You can run a preview at any time without any impact to the system.
In our case, as you can see in Figure 14, the preview is successful and there are no failures. So you are ready to move on.
Figure 14. Output of the preview
When you are ready to run the upgrade, change the preview to no. You will also have to change the default field that relates to << Accept new license agreement >>. For some reason, AIX defaults to no. Change it to yes.
After you click Enter, it will prompt you to make sure you want to do this. Click Enter to continue to start the process (see Figure 15).
Figure 15. Start the upgrade process
This can run for up to an hour, depending on the speed of your system and the type of upgrade you are performing. When the process is complete, you can scroll down to the summary section to see if you've been successful, which in this case is yes. (see Figure 16).
Figure 16. Success
Your final step is to reboot the box. Make sure you perform this step before bringing your applications back and going live. After I rebooted the box, I ran the oslevel command to confirm the new system level (see Listing 1).
Listing 1. Confirming the new system level
lpar46ml16fd_pub > # oslevel -s 6100-02-01-0847
What does this information signify? It tells that you are running AIX V6 TL2, service pack 1, released in 2008 in the 47th week. The forth field, 0847, indicates the year and week. Finally, it is highly recommended that you apply the latest service pack when moving to the new TL. In our case we did not have to, because the latest pack was already a part of the TL upgrade.
TL upgrade deployment schedule
When should you actually perform a TL upgrade? There are generally three scenarios where you will make this choice:
- When your TL is going out of the available support period.
- You want to test a new distribution level that will be going into production and need to get the longest period of fix support.
- You want to use the new features and functionality of the TL.
The short answer is that there really is no right or wrong time to perform an upgrade. Some clients need an environment that requires maximum uptime and stability. These clients typically wait until new TLs are out for at least six months to a year before applying them. Other folks will wait for several TL's to be put into place prior to upgrading to ensure maximum reliability. For clients that like to take advantage of new features and ensure that they have the latest security patches, they typically install new service packs shortly after they come out. From a vendor-support perspective, IBM would prefer if you upgraded your TLs (and service packs, for that matter) as soon as they come out. The reason is that it's just easier to support systems that are always at current levels. I like to upgrade at least once a year to a new TL. In doing so, I will also usually wait until at least service pack number two has been released. If you really want to err on the side of caution, wait until service pack number three. That way, you will know that your release is really rock solid.
This article,discussed how to work with technology upgrades and service packs on AIX. It reviewed recent enhancements and changes in both nomenclature and substance. At the same time, it discussed best practices on how and when to upgrade environments. It looked at various methods at bringing the data to our systems: automatically using SUMA and manually with the IBM Fix Central. The article also performed an actually upgrade (with smit) using a download performed using SUMA.
- Visit IBM Fix Central, central repository for all technology levels and service packs for AIX on System p.
- Optimizing AIX 5L performance: Tuning network performance, Part 1 (Ken Milberg, developerWorks, November 2007): Read Part 1 of a three-part series on AIX networking, which focuses on the challenges of optimizing network performance.
- For a three-part series on memory tuning on AIX, see Optimizing AIX 5L performance: Tuning your memory settings, Part 1 (Ken Milberg, developerWorks, June 2007).
- Download and read the IBM whitepaper Improving Database Performance with AIX concurrent I/O.