Difficulties applying OA update 2.60

[Joshua Small_2]

Hi,

Last night we attempted to upgrade our firmware OA to 2.60.

We did this using "hpoa260.bin", downloaded from HP website, and using the web interface upgrade functionality.

First it flashed the standby OA (we have redundant) then it restarted it. The next message on the browser window was this:
The firmware update process failed because the standby onboard administrator could not verify the image.

The OA system logs show this:

Mar 3 23:50:56 Redundancy: Service started (STANDBY)
Mar 3 23:54:10 Redundancy: Error communicating with the other Onboard Administrator.
Mar 4 00:00:56 Redundancy: Network is not up after 10 mins. Reset to network defaults.
Mar 4 00:01:25 Cert: OA: Generated new SSH Key
Mar 4 00:01:28 Cert: New Certificate successfully installed
Mar 4 00:01:33 Redundancy: Enclosure IP mode configurations have been reset.
Mar 4 00:01:33 Kernel: Network link is up at 100Mbps - Full Duplex
Mar 4 00:02:33 OA: Timed out waiting for a valid DHCP server response. Will keep trying in the background

Following this, our active OA is running 2.41, the standby claims to be running 2.60. Except we can't get to the standby, it doesn't seem to have any IP settings and therefore doesn't seem to be accessible.

The assumption was that our download was corrupted, but I downloaded it again a few hours later from a different machine on a different network and appear to have got the same file. I tried to reapply the update and the exact same thing happened.

So there are two questions at this point:

How can I recover access to the standby OA? We originally configured the IPs by the pad on the front of the Bladecenter, but since we can get to the active OA in a browser/telnet it would be nice to think we can avoid a trip to the DC.

Has anyone seen this issue before and how are we likely to get the firmware upgrade completed without losing IP settings on our other OA?

[WFHC-WI]

Hi Joshua,

Try to re-seat both Onboard Administrators as well as the OA sleeve that they sit in. This seems to be the silver bullet that fixes OA-related issues.

Are/were the OAs configured to have static IPs? You can also force an IP assignment using the LCD unit on the front of the enclosure.

good luck

[Joshua Small_2]

Hi,

Thanks for the advice.

We have a technician going into the DC tonight to try this out. We'll update tomorrow on how this went.

Yes, both OAs were configured with static IPs. We have found that, if we telnet to the active OA, we can "SET IPCONFIG STATIC 2 ... " to set the standby, rendering it accessible again. In this situation, if we logon to the standby OA and reboot it, it comes up with the same issue on reboot and claims it had to reset its IP settings.


It does make it feel kind of wasteful purchasing a redundant OA if we're going to see issues that involve removing them both :p

[Joshua Small_2]

Can confirm, this resolved the issue.

[The Brit]

If you haven't done this, I suggest that you enable "Enclosure Mode" (Enclosure Settings > Enclosure TCPIP Settings). This will ensure that the Active OA always has the same IP, regardless of which physical module is Active.

Dave.

[Joshua Small_2]

Personally I'd prefer to be able to use network monitoring tools to tell me when an IP goes down - thereby knowing when one OA goes down, and which one.