20140331-1.1.1.2 840 Release Notes
20140331-1.1.1.2 840 Release Notes
Contents
===================
1. Candidate Systems
2. Bug Severity Legend
3. Latest Changes
4. Upgrading Firmware
5. Errata
6. Release History
7. Contact Information
============================================================================
1. Candidate Systems
-------------------------------
========================================================================
2. Bug Severity Legend
-------------------------------
The following table describes the bug severity terminology used in the release history:
============================================================================
3. Latest Changes
-------------------------------
General
Battery error messages were improved.
Background Lost Links were improved.
Patch management was improved.
Note: In order to perform concurrent maintenance on canisters and batteries, the following procedure
should be used:
Canister CM Demonstration
1) To demonstrate Canister CM, simulate an error by using the GUI system page to power down
either canister:
Click on “Power Off” to complete the process. Note: You must wait for the power status light to blink on
the canister, indicating it has powered down.
Battery CM Demonstration
1) Remove a single battery
2) Under Status Alerts or Monitoring > Events, view the latest events and click on Run Fix to
walk through the Directed Maintenance Procedure for battery replacement.
Bug Fixes:
• 29814 Intermittent 114 Enclosure Battery fault type 1 (S2)
• 29881 MGMT to XBAR link integrity improvement (S2)
• 29894 Management FPGA is not always patched on boot (S4)
• 29893 Displayed Battery charge percentage calculation not correct. (S5)
4. Upgrading Firmware
-------------------------------
Overview
If you are upgrading from version 1.1.1.1 to this release, and your system is healthy, then you can perform
a concurrent code load (CCL) upgrade to 1.1.1.2. A CCL upgrade is a non-disruptive upgrade and is the
preferred upgrade method. For general instructions on performing upgrades, refer to the FlashSystem 840
Information Center:
http://pic.dhe.ibm.com/infocenter/flshsstm/cust/index.jsp
Preparing to upgrade
CCL is a non-disruptive upgrade which means that the system remains online throughout the process and
you can continue to access data normally. As a precaution, it is recommended that the upgrade occur dur-
ing a time of reduced traffic. During the upgrade, the Fibre Channel adapters in each node are taken offline
temporarily to be upgraded. This might impact performance or throughput. The impact is more noticeable
under heavy load conditions. With a properly configured multi-path configuration, access to your data is
maintained at all times.
In order to ensure a successful, non-disruptive upgrade, you should verify that your interface ports are all
online and all the system hardware is functioning normally. Ideally, you should have:
All host interfaces online. An active multi-path configuration is required to ensure no loss of access
during the upgrade.
Both batteries should be online and charged at least 85%. Use the CLI command "lsenclosure-
battery" to verify the charge level.
All hardware should be online and functioning normally. There should be no unfixed alerts in the
event log. (See the exceptions below.)
Before you begin the upgrade, we recommend that you perform a backup of your data and a backup of the
FlashSystem 840 configuration. To backup the 840 configuration, log into the cluster management IP ad-
dress and run the command:
svcconfig backup
Optionally, you can copy the configuration backup file from the 840 to your workstation using scp (Linux)
or pscp.exe (Windows, using the PuTTY utility's secure copy tool), for example:
Linux:
scp <username>@<cluster_ip>:/tmp/svc.config.backup.xml .
Windows:
pscp <username>@<cluster_ip>:/tmp/svc.config.backup.xml .
It is strongly recommended that the upgrade be performed using the web-based cluster management
interface, under the "General" tab. Using the web GUI, you will be prompted to install and run the soft-
ware upgrade utility which is designed to detect and warn of various conditions that might prevent a suc-
cessful upgrade.
However the upgrade can also be performed using the "applysoftware" command using the CLI. This
requires that you manually upload the 1.1.1.2 release to the /upgrade directory on the cluster management
node.
Troubleshooting
If the upgrade is taking more than 2 hours to finish, your upgrade may have stalled. This can be checked
using the "lssoftwareupgradestatus" CLI command. In most cases, this can be resolved by
aborting the upgrade and reattempting the upgrade after the system downgrades to its original level.
To abort the upgrade, you can use the "applysoftware -abort" CLI command or the “Stop Up-
grade” button in the GUI, as seen below:
After the system downgrades, you can reattempt your upgrade from GUI or CLI. If the upgrade stalls re-
peatedly or if you have alerts which cannot be cleared, call IBM Support.
============================================================================
5. Errata
-------------------------------
============================================================================
6. Release History
-------------------------------
[B ] = Bug Fixes
[C ] = Changes
[N ] = New Features
============================================================================
7. Contact Information
-------------------------------
1-800-IBM-SERV