Compared to the previous ordeal of the HMC Update to 7.7.5.0 the recent HMC update to v7.7.6.0 SP1 went smooth as silk. Well, as long as one had enough patience to wait for the versions to stabilize. IBM released v7.7.6.0 (MH01326), an eFix for v7.7.6.0 (MH01328) and v7.7.6.0 SP1 (MH01329) in short succession. Judging from this and from the pending issues and restrictions mentioned in the release notes, one could get the impression, that the new HMC versions were very forcefully – and maybe prematurely – shoved out the door in order to make the announcement date for the new Power7+ systems in October 2012.

On the upside, the new versions are now easily installable from the ISO images via the HMC GUI again. On the downside, if you're running a dual HMC setup, you might – depending on your infrastructure – still need a trip to the datacenter. This is necessary in order to shut down, disconnect or otherwise prevent your second HMC, still running at a lower code version from accessing the managed systems while the first HMC is being updated or already running the newer version. The release notes for MH01326 state this:

“Before upgrading server firmware to 760 on a CEC with redundant HMCs connected, you must disconnect or power off the HMC not being used to perform the upgrade. This restriction is enforced by the Upgrade Licensed Internal code task.”

This is kind of an annoyance, since the whole purpose of a dual HMC setup is to have a fallback in case something goes south with one of the HMCs. Unfortunately the release notes aren't very clear as to whether this restriction applies only during the update process or if you can't run different HMC versions in parallel at all. I decided to play it save and physically disconnected the second HMCs network interface, which is facing the service processor network for about two weeks until the new HMC version had proven itself to be ready for day to day use. After this grace period i updated the second HMC as well and plugged it back into the service processor network.

Like with earlier updates there are still error messages with regard to symlink creation appearing during the update process. E.g.:

HMC corrective service installation in progress. Please wait...
Corrective service file offload from remote server in progress...
The corrective service file offload was successful. Continuing with HMC service installation...
Verifying Certificate Information
Authenticating Install Packages
Installing Packages
--- Installing ptf-req ....
--- Installing RSCT ....
src-1.3.1.1-12163
rsct.core.utils-3.1.2.5-12163
rsct.core-3.1.2.5-12163
rsct.service-3.1.0.0-1
rsct.basic-3.1.2.5-12163
--- Installing CSM ....
csm.core-1.7.1.20-1
csm.deploy-1.7.1.20-1
csm_hmc.server-1.7.1.20-1
csm_hmc.hdwr_svr-7.0-3.4.0
csm_hmc.client-1.7.1.20-1
csm.server.hsc-1.7.1.20-1
--- Installing LPARCMD ....
hsc.lparcmd-2.0.0.0-1
ln: creating symbolic link `/usr/hmcrbin/lsnodeid': File exists
ln: creating symbolic link `/usr/hmcrbin/lsrsrc-api': File exists
ln: creating symbolic link `/usr/hmcrbin/mkrsrc-api': File exists
ln: creating symbolic link `/usr/hmcrbin/rmrsrc-api': File exists
--- Installing InventoryScout ....
--- Installing Pegasus ....
--- Installing service documentation ....
--- Updating baseOS ....
Corrective service installation was successful.

This time i got fed up and curious enough to search for what was actually breaking and where. After some loopback mounting and sifting through the installation ISO images i found the culprit in the shell script /images/installImages which is part of the /images/disk2.img ISO image inside the installation ISO image:

/images/installImages

 515     # links for xCAT support - 755346
 516     if [ ! -L /usr/sbin/rsct/bin/lsnodeid ]; then
 517        ln -s /usr/sbin/rsct/bin/lsnodeid /usr/hmcrbin/lsnodeid
 518     fi
 519     if [ ! -L /usr/sbin/rsct/bin/lsrsrc-api ]; then
 520        ln -s /usr/sbin/rsct/bin/lsrsrc-api /usr/hmcrbin/lsrsrc-api
 521     fi
 522     if [ ! -L /usr/sbin/rsct/bin/mkrsrc-api ]; then
 523        ln -s /usr/sbin/rsct/bin/mkrsrc-api /usr/hmcrbin/mkrsrc-api
 524     fi
 525     if [ ! -L /usr/sbin/rsct/bin/rmrsrc-api ]; then
 526        ln -s /usr/sbin/rsct/bin/rmrsrc-api /usr/hmcrbin/rmrsrc-api
 527     fi
 528
 529     # defect 788462 - create the lspartition for the restricted shell after rsct.service rpm installed.
 530     if [ -L /opt/hsc/bin/lspartition ]
 531     then
 532        ln -s /opt/hsc/bin/lspartition /usr/hmcrbin/ 1>&2 2>/dev/null
 533     else
 534        ln -f /opt/hsc/bin/lspartition /usr/hmcrbin/ 1>&2 2>/dev/null
 535     fi

So this is either a semantic error and the goal was actually to check for the symlinks to be created already being present, in which case e.g. /usr/hmcrbin/lsnodeid should be in the test brakets. Or this is not a semantic error, in which case the aforementioned test for the symlinks to be created already being present should actually be implemented or the symlink creation should be forced (“-f” flag). Besides that i would've probably handled the symlink creation in the RPM that installs the binaries in the first place. Well lets open a PMR on this and find out what IBM thinks about this issue.

Another issue - although a minor one - with the above code expamle is in lines 532 and 534. The shells I/O redirection is used in the wrong order, causing STDOUT to be redirected to STDERR instead of - what was probably intended - both being redirected to /dev/null.

Aside from that we're currently not experiencing any issues with the new HMC version. I've opened up a RPQ to get the feature 5799 - HMC remote restart function, which is again supported with v7.7.6.0 SP1 (MH01329). This will come in quite handy for the simplification of our disaster recovery procedures. But that'll be material for another post. Stay tuned until then …

Leave a comment…