Last Modified: Apr 28, 2025
Affected Product(s):
BIG-IP Install/Upgrade, LTM
Known Affected Versions:
11.4.0, 11.5.0, 11.5.1, 11.5.1 HF1, 11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.1 HF10, 11.5.1 HF11, 11.5.2, 11.5.2 HF1, 11.5.3, 11.5.3 HF1, 11.5.3 HF2, 11.5.4, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.5.5, 11.5.6, 11.5.7, 11.5.8, 11.5.9, 11.5.10
Fixed In:
11.6.0
Opened: Aug 19, 2013 Severity: 3-Major Related Article:
K15103
In a multi-blade cluster, when a cluster primary is determined, it tries to upgrade the chassis annunciator firmware if a newer version is available. If the primary also needs to reboot to another volume, due to a user request either as part of an earlier install command or a reboot command in tmsh, it interrupts the chassis firmware update, putting the chassis annunciator in boot loader mode, which in turn causes TMOS startup failures after reboot because the system needs the annunciator to access the critical data on the chassis PROMISE.
When this occurs, TMOS startup fails after reboot.
This occurs when upgrading the chassis annunciator on the cluster primary of a multi-blade chassis.
To work around this, use the bladectl utility to manually update the chassis annunciator firmware.
Blades in a VIPRION chassis will wait until a pending chassis firmware update is completed before rebooting.