Delayed Firmware Installation

IT Infrastructure - Other
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Previous MC Press Online articles have provided a background on system firmware, an overview of concurrent maintenance, and an explanation of the firmware installation process ("So You've Moved to an i5 Platform?" and "Installing and Updating System Firmware"). But one topic about system firmware installation consistently gets raised: Can the activation of firmware fixes be deferred? Can the process of flashing the firmware fixes to the Flexible Service Processor (FSP) be delayed until the next IPL? The good news is that the answer is yes. Flashing the firmware fixes onto the FSP is called "activating the fixes," and this article will explain the process of deferring the activation of firmware fixes.

Starting with system firmware release 2.3.0 and Hardware Management Console (HMC) firmware release V4.5, concurrent firmware (LIC) updates are now supported when updating the current release. However, the process of updating the system firmware to a new release or version will always be disruptive. This means that the firmware installation will require a deep IPL of the managed system (i.e., powering off all active partitions).

Let's run through an example. Let's assume we have a managed system running 2.3.0 with Service Pack 2. Service Pack 3, which is a concurrent update, is available for download from your selected repository. You may use the firmware installation wizard you have used in the past for updating your FSP firmware. As you can see in Figure 1, the system firmware updates are all concurrent. Since the system firmware update is concurrent, the wizard has chosen the concurrent option for you.

http://www.mcpressonline.com/articles/images/2002/Delayed%20Firmware%20InstallationV4--07050600.png

Figure 1: The system firmware wizard shows that all updates are concurrent.

Pressing Advanced Options on this panel will take you to a screen that shows you information about the Managed System and Bulk Power Controller (i595 only) firmware concurrency options. As you can see from Figure 2, the wizard shows a concurrent update, so you may proceed to update the service processor without powering off any of your partitions. In this example, all updates are concurrent; therefore, all choices except "Concurrent install and activate" are grayed out.

http://www.mcpressonline.com/articles/images/2002/Delayed%20Firmware%20InstallationV4--07050601.jpg

Figure 2: Managed System and Power LIC Concurrency

So, what if the update (i.e., firmware fixpack installation) is disruptive? How can the IPL for a disruptive installation be deferred? Under the heading "Select the type of installation to perform" in Figure 2, note the second choice: "Concurrent install only, with deferred disruptive activate." This option is provided when only a portion of the update is tagged as concurrent and the remaining pieces are disruptive. It can be used when you want to install (i.e., load) an update and allow it be activated at the next system IPL. This allows the system IPL to occur during a scheduled maintenance window.

This concept is similar to a delayed apply PTF on i5/OS. By using this option when it is available, you can help keep your maintenance window shorter. When the upgrade is complete, you will receive a message saying the firmware installation was partially successful (Figure 3). You will also notice that on the system information menu, a new column will show the level of the deferred fixes (Figure 4). Both activated and deferred fix levels are the same. Once the system has been shut down and restarted, the deferred column will disappear (Figure 5). It is still possible to perform a concurrent update even if some deferred fixes are waiting.

http://www.mcpressonline.com/articles/images/2002/Delayed%20Firmware%20InstallationV4--07050602.png

Figure 3: This message indicates a partially successful firmware installation.

http://www.mcpressonline.com/articles/images/2002/Delayed%20Firmware%20InstallationV4--07050603.png

Figure 4: On the system information menu, a new column will show the level of the deferred fixes.

http://www.mcpressonline.com/articles/images/2002/Delayed%20Firmware%20InstallationV4--07050604.png

Figure 5: Here's the system information after shutdown and restart.

While this deferred activation option is useful, if a fix is deemed high priority (i.e., could cause an unplanned outage unless it is applied), you will not have the option of a concurrent update.

For more information on the fix levels included in your update package, select your target system as seen in Figure 2, and click on View Information to bring up a window like the one in Figure 6. This will give you a summary of what level of code you are running and what level will be activated after you update, as well as the current release level of your managed system (note the EC Number column).

http://www.mcpressonline.com/articles/images/2002/Delayed%20Firmware%20InstallationV4--07050605.jpg

Figure 6: The View Information screen provides details about your levels.

From this panel, if you select your system and press View Details, you will see a more detailed description of what you are installing. Figure 7 shows an example of what you might see.

http://www.mcpressonline.com/articles/images/2002/Delayed%20Firmware%20InstallationV4--07050606.jpg

Figure 7: With View Details, you can find out more information about your installation.

The benefit of a concurrent firmware update is that once you move to a new release, which would require a disruptive IPL, you can then apply fixes within that release level without having to perform a managed system IPL. This isn't to say there won't be updates to your service processor within a release level that will require a disruptive update. IBM continues to scrutinize the fixes to be sure it is absolutely necessary for a fix to be marked disruptive before requiring customers to apply a disruptive fix requiring a system IPL.

You can find more information on updating firmware on the service processor at the IBM Information Center.

Daniel DeGroff is a Test Engineer at IBM Rochester. He can be contacted at This email address is being protected from spambots. You need JavaScript enabled to view it.

Becky Schmieding is an IBM Certified Executive Project Manager at IBM Rochester on the Product Definition Team (PDT) responsible for the E2E upgrade process. She is a noted speaker and author on PC5250, iSeries Navigator, and the iSeries Access family of products. She can be contacted at This email address is being protected from spambots. You need JavaScript enabled to view it..



BLOG COMMENTS POWERED BY DISQUS