By manufacturer
Dell PowerEdge HPE ProLiant Lenovo ThinkSystem Fujitsu Primergy Supermicro IBM System x / Power Acer AltosFirmware updates: planned, not improvised.
BIOS, BMC, RAID controller, NIC and expansion firmware, CPU microcode: vendor updates are often mandatory to close a security advisory or to stay compatible with the latest workloads, but applied without planning they can break production. Verified compatibility matrix, mandatory intermediate steps respected, documented rollback plan.
Three typical risks of a mismanaged firmware update.
- Unsupported version jumps: some firmware requires an intermediate upgrade (e.g. from iLO 5 v2.40 to v3.00 via v2.78). Skipping it is the number one cause of systems that fail to boot after the update.
- Firmware/workload mismatch: a new release can change a feature default (e.g. SR-IOV, UEFI Secure Boot), altering the behaviour of the operating system already installed.
- Licensing constraints: some vendor features are disabled from specific firmware versions onwards if the licence does not match.
Pre-flight, rollout, validation.
- Pre-flight: check the vendor compatibility matrix, read the release notes for licensing and feature impact, confirm mandatory intermediate steps.
- Configuration backup: BIOS export, iDRAC/iLO config backup, RAID controller config dump, screenshots of boot settings.
- Documented rollback plan: how to bring the machine back to the previous version if something goes wrong.
- Rollout in an agreed window: out-of-band where possible (via iDRAC / iLO / XClarity with no OS downtime), in-band if required.
- Post-update validation: targeted stress tests before going back into production, verification of critical features, pre/post sensor comparison.
The questions we get most often.
Which firmware needs updating most urgently?
In order of criticality: 1) CPU microcode covered by a security advisory (e.g. Spectre/Meltdown mitigations and later ones), 2) BMC firmware (iDRAC/iLO/XClarity) with open CVEs, because it is exposed on the management network, 3) RAID controller firmware where there are known bugs on rebuild or disk detection, 4) BIOS/UEFI for compatibility with new CPUs/RAM. Vendors publish security advisories: we monitor them for customers who ask us to.
Does the update require system downtime?
It depends on the component. iDRAC/iLO/BMC: often with no operating system downtime. BIOS/UEFI: requires a reboot. CPU microcode: requires a reboot. RAID controller: typically no downtime if the controller supports online updates (most recent models do). We plan updates into a single window to minimise the number of reboots needed.
Can I skip versions to reach the latest one faster?
Almost never without risk. The vendor compatibility matrix sets out the supported upgrade paths: where intermediate steps are prescribed, skipping them often breaks the process (system that will not boot, BMC stuck in recovery mode). We check this systematically before proposing a plan.