Server Firmware Updates: When, In What Order, and Recovery
Firmware updates fix real problems and cause real outages, and the difference is usually sequence and timing rather than the update itself. This covers doing it without breaking things.
Should I update firmware at all?
Not reflexively, and not never.
Update when: you are commissioning a machine, a known issue affects you, a security advisory applies, you are adding hardware that needs newer support, or you are about to change hypervisor or operating system version.
Do not update when: a production machine is working fine, there is no specific reason, and nothing is changing. "Latest is best" is not a strategy on production hardware.
The exception that overrides all of this: update before installing hardware that needs firmware support, not after. A processor generation the firmware does not recognise will not post, and a machine that will not post cannot be updated. Our processor guide covers this.
Sequence matters
Components depend on each other, and updating in the wrong order can leave a machine in a state it cannot recover from.
Vendors publish a recommended sequence, and on most platforms a bundled update package that handles it. Use the bundle where one exists rather than updating components individually.
Where you must do it manually, the general order is management controller first (so you keep remote access if something goes wrong), then system firmware, then controllers and adapters, then drives.
The management controller first rule matters more than it sounds. If a later step fails, remote access is how you recover without a site visit. Our out-of-band guide covers why.
Before you start
Five things.
Read the release notes, particularly for prerequisites and for versions you cannot skip past. Some updates require an intermediate version first.
Confirm remote access works before you need it.
Take a backup, and for controllers, record the array configuration.
Check power. A firmware update interrupted by power loss can brick a component. On a machine with redundant supplies, confirm both are healthy first. Our power supply guide covers checking.
Know how long it takes. Some updates take far longer than expected, and a machine mid-update must not be interrupted.
Drive firmware: the one people skip
Drive firmware fixes real problems — data integrity issues, premature failures, compatibility with specific controllers — and almost nobody updates it.
Three points.
Vendor-coded drives get firmware through the server vendor’s bundle. Bare manufacturer drives do not, which is one practical argument for vendor-coded drives in a managed estate. Our OEM guide covers the trade.
Update drives one at a time in an array, allowing each to come back before the next.
Check for advisories on your specific drive models. Some drive firmware issues have caused data loss at specific hour counts, and those are exactly the advisories worth acting on. Our drive health guide covers monitoring alongside.
Consistency across a fleet
Two reasons it matters.
Diagnosis. When three identical machines run three firmware levels, every problem needs checking against three configurations.
Clustering. Some platforms require consistent firmware across cluster members, and mismatches cause behaviour that is hard to attribute.
Adopt a level, apply it across the fleet, and record it. Our standardisation guide covers this across sites, and our inherited estate guide covers establishing what you currently have.
When an update goes wrong
Three situations.
Machine does not post after a system firmware update. Most platforms have a recovery mechanism — a backup firmware image, a jumper, or a management controller recovery path. Check the vendor documentation for yours before you need it.
Controller does not see its array after an update. Usually the configuration is intact and needs importing rather than recreating. Import, do not clear. Our drive detection guide covers the distinction.
A component is unresponsive mid-update. Do not power cycle immediately. Some updates take much longer than expected and interrupting them is what actually breaks the component.
Frequently asked questions
Should I always update server firmware?
No. Update when commissioning, when a known issue or security advisory applies, when adding hardware that needs newer support, or before an OS or hypervisor change. Do not update a working production machine for no specific reason.
What order should I update firmware in?
Use the vendor bundle where one exists. Manually, the management controller first so you keep remote access if something goes wrong, then system firmware, then controllers and adapters, then drives.
Do I need to update drive firmware?
It is the one people skip and it fixes real problems including data integrity issues and premature failures. Update one drive at a time in an array, and check for advisories on your specific models.
Should I update firmware before or after adding a processor?
Before, where the processor is a newer generation than the board shipped with. It fits physically and will not post without firmware support, and a machine that will not post cannot then be updated.
My controller lost its array after an update. Is the data gone?
Usually not. The configuration is frequently intact on the drives and needs importing rather than recreating. Import preserves the data; clear destroys it. Be certain which you are choosing.
A firmware update seems stuck. Should I power cycle?
Not immediately. Some updates take much longer than expected, and interrupting them is what actually breaks the component. Know the expected duration before starting.
Tell us the platform and what you are changing, and we will tell you which firmware matters and in what order.
