Loading...
Loading...
An Onboard Administrator module installed in Bay 1 (OA1) will start functioning as an active OA when powering up an HPE Superdome 2 complex, regardless if either OA1 or OA2 is the active OA. If the OA1 battery is exhausted, GiCAP configuration data kept in battery-backed OA1 NVRAM will be lost, together with some enclosure configuration data.Since active_gm (and standby_gm) user(s) is(/are) removed from OA1, GiCAP Group Manager(s) cannot contact the member OA. Furthermore, the factory-installed OA certificate will be restored to OA1. This may cause the member to be unable to contact GiCAP Group Manager(s).The following possible symptoms may be observed at the OA1 battery depletion:The following are reset:Date, time, and time zone settingsOA Administrator passwordOA1 certificateOA1 network settingsAll user accounts except AdministratoriCAP and Partition commands such as the icapstatus and parstatus commands fail."cannot be contacted "error appears with the "icapmanage –sv" command from GM(s).The member cannot loan/borrow core usage rights or TiCAP to/from other members in the same GiCAP group.Since OA1 syncs its content to OA2, the "FORCE TAKEOVER" command from OA2 would not be able to improve the anomalous situation.
Any HPE Integrity Superdome 2 Systems configured as a Global Instant Capacity (GiCAP) group member.
To prepare for the above scenario, refer to the following three recommendations:The current runtime configuration should be stored with the "UPLOAD CONFIG" command.The OA battery should be replaced when both of the following symptoms occur:The "SHOW OA STATUS" command in Complex Firmware version 4.2.48 or later displays "OA Battery Failed."ANDThe following message appears in the "SHOW OA SYSLOG" command output:Jun 26 14:29:18 mgmt: The OA battery is low or has failed. Configuration settings may be lost if the OA loses power. Replace the OA Battery with spare part #708907-001.NOTE: If the OA battery is low or has failed, both of the above can be seen only when the complex is powered up or the OA is reinstalled.The symptoms described above may occur when removing standby OA followed by reinstalling it. The same operations can be also executed for active OA only when the complex is configured as a GiCAP group member in either of the following manners:Enclosure IP ModeWhen adding a member to GiCAP groupDisabledBoth OAs are specifiedEnabledActive OA is specifiedRecover GiCAP system configurations when the above data loss occurs:Power off the enclosure.Replace the OA1 battery with a new one.Power on the enclosure.Restore the runtime configuration saved in the script file by using the "DOWNLOAD CONFIG" command. Suppose that the configuration script is stored as the "prod-1.cfg" file in a USB key. OA> show usbkey OA> download config usb://d2/prod-1.cfgRestart the OA1. OA> restart oaRe-generate a self-signed OA1 certificate. OA> generate certificate selfsigned. The OA will automatically reboot after successfully installing a new self-signed certificate.Re-create GiCAP certificate files from AGM. # cd /etc/opt/iCAP # mkdir GiCAP-cert.orig # mv GiCAP_CA GiCAP*.pem GiCAP-cert.orig # ./GiCAP_keygen(Superdome 2 complex firmware version <= 4.1.34) # ./GiCAP_OA_keygen(Superdome 2 complex firmware version >= 4.2.54) # cp GiCAP_OA_keygen /tmp # vi /tmp/GiCAP_OA_keygen # diff GiCAP_OA_keygen /tmp/GiCAP_OA_keygen 164a165,169 > # Workaround to overcome the situation that SHA256 fingerprint files > # cannot be overwritten after replacing the OA battery in OA1. > epoch=`perl -e 'print time();'` > DNSNAME=${DNSNAME}_${epoch} > # # /tmp/GiCAP_OA_keygenNOTE: Since version 4.2.36 and 4.2.48 can cause serious symptoms after running the "icapmanage -Q" command, this should be avoided for GiCAP membersRe-create GiCAP certificate files from SGM if SGM is configured. # cd /etc/opt/iCAP # mkdir GiCAP-cert.orig # mv GiCAP_CA GiCAP*.pem GiCAP-cert.orig # ./GiCAP_keygen(Superdome 2 complex firmware version <= 4.1.34) # ./GiCAP_OA_keygen(Superdome 2 complex firmware version >= 4.2.54) # cp GiCAP_OA_keygen /tmp # vi /tmp/GiCAP_OA_keygen # diff GiCAP_OA_keygen /tmp/GiCAP_OA_keygen 164a165,169 > # Workaround to overcome the situation that SHA256 fingerprint files > # cannot be overwritten after replacing the OA battery in OA1. > epoch=`perl -e 'print time();'` > DNSNAME=${DNSNAME}_${epoch} > # # /tmp/GiCAP_OA_keygenRun updateGiCAPCert from AGM to update GM OS certificates between GMs and upload them to each member OA. # cp GiCAP-cert.orig/GiCAP_OA_CA_CERT.pem /tmp/ # /opt/icod/bin/updateGiCAPCertNOTE: It is not necessary to restart each member OA if SGM is configured. If SGM is not configured, restart each member OA except the battery replaced OA.Run updateGiCAPCert from SGM to update GM OS certificates between GMs and upload them to each member OA. # cp GiCAP-cert.orig/GiCAP_OA_CA_CERT.pem /tmp/ # /opt/icod/bin/updateGiCAPCertRe-add all the GiCAP members from AGM. # icapmanage -a -m prod1:prod1-oa1.corp.com -g Production # icapmanage -a -m prod2:prod2-oa1.corp.com -g Production # ...RECEIVE PROACTIVE UPDATES: Receive support alerts (such as Customer Advisories), as well as updates on drivers, software, firmware, and customer replaceable components, proactively via e-mail through HPE Subscriber's Choice. Sign up for Subscriber's Choice at the following URL:Proactive Updates Subscription Form.NAVIGATION TIP: For hints on navigating HPE.com to locate the latest drivers, patches, and other support software downloads for HPE systems and Options, refer to theNavigation Tips document.SEARCH TIP: For hints on locating similar documents on HPE.com, refer to theSearch Tips Document.
Operating Systems Affected:HP-UX 11.x
Click on a version to see all relevant bugs
Hewlett Packard Enterprise Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.