Dell iDRAC9 Firmware Update: Lifecycle Controller & RACADM

Firmware updates on Dell PowerEdge servers are easy to get wrong because the components
are not independent: updating a PERC controller before the iDRAC, or interrupting a PSU flash,
produces failures that look like hardware faults. This guide covers the update order Dell
recommends, the four update paths (Lifecycle Controller GUI, RACADM, Redfish, and Dell System
Update), and the verification steps that confirm an update actually landed. It is written for
14th-generation and later platforms where iDRAC9 is the management controller.

Know Which Components You Are Updating

An iDRAC9 firmware update (.d9) bundles the controller and the Lifecycle
Controller. A Dell Update Package (.exe/.BIN) targets one component.
The two have different privilege requirements: the .d9 image needs Configure
privilege and is applied through RACADM; the DUP needs System Control privilege for
out-of-band methods and can be pushed from the iDRAC UI, WSMan or Redfish.

• iDRAC + Lifecycle Controller — update first, no host reboot required (iDRAC restarts)
• BIOS — requires host reboot
• CPLD — requires host reboot, rarely updated
• PERC / RAID controller — requires reboot, and after 12.2 use a cold reboot, not warm
• NIC / HBA and backplane expander — requires reboot
• PSU — hot update, but every server in the chassis must be powered off first

Option 1: Lifecycle Controller GUI

Boot the server and press F10 to enter Lifecycle Controller, choose
Firmware Update, then either point it at downloads.dell.com or upload a
local DUP. This is the safest path for engineers who rarely touch servers, and it produces a
difference report showing installed versus available versions before anything is written.

Option 2: RACADM from the iDRAC or the host OS

RACADM over SSH to the iDRAC IP is the fastest remote method. Stage rather than force the
reboot so you control the maintenance window:

# iDRAC + Lifecycle Controller image from Dell's FTP/HTTPS
racadm -r 192.168.1.100 -u root -p 'password' update \
  -f iDRAC-with-Lifecycle-Controller_Firmware_XXXXXX_LN64_7.20.80.50_A00.BIN \
  -e downloads.dell.com -t HTTPS -a FALSE

# From a local TFTP or NFS share
racadm -r 192.168.1.100 -u root -p 'password' update \
  -f firmimg.d9 -g -u -a tftp://192.168.1.50/firmware/
racadm -r 192.168.1.100 -u root -p 'password' update \
  -f firmware.bin -e 192.168.1.50:/exports/firmware -t NFS

# Watch the job queue and confirm the version afterwards
racadm -r 192.168.1.100 -u root -p 'password' jobqueue view
racadm -r 192.168.1.100 -u root -p 'password' getversion
racadm -r 192.168.1.100 -u root -p 'password' racadm get iDRAC.NIC

Use -a FALSE while other workloads are running so the update stages and waits
for your reboot. Note that if a job has been Running with no status change for six hours,
iDRAC marks it failed — check jobqueue view rather than assuming it is still
working.

Option 3: Redfish

Redfish is the right choice when you are updating a fleet with Ansible or a script. Check
the running version, POST the image, then poll the task.

# Current inventory and version
curl -sk -u root:password https://192.168.1.100/redfish/v1/Systems/System.Embedded.1 | jq '.Model, .PowerState'
curl -sk -u root:password https://192.168.1.100/redfish/v1/Managers/iDRAC.Embedded.1 | jq '.FirmwareVersion'

# Remote share based update (SimpleUpdate)
curl -sk -u root:password -H 'Content-Type: application/json' -X POST \
  https://192.168.1.100/redfish/v1/UpdateService/Actions/UpdateService.SimpleUpdate \
  -d '{"ImageURI":"https://downloads.dell.com/FOLDER.../BIOS_XXXXXX.exe","TransferProtocol":"HTTPS"}'

# Uploaded image path
curl -sk -u root:password -H 'Content-Type: application/json' -X POST \
  https://192.168.1.100/redfish/v1/UpdateService/upload \
  -F 'file=@BIOS_XXXXXX.exe'

If a real-time job completes as Completed, Virtual AC Pending, perform a virtual AC
power cycle — the OEM extended reset action exists for exactly this case and returns an error
if the host is powered on:

curl -sk -u root:password -H 'Content-Type: application/json' -X POST \
  https://192.168.1.100/redfish/v1/Chassis/System.Embedded.1/Actions/Oem/DellOemChassis.ExtendedReset \
  -d '{"ResetType":"PowerCycle","FinalState":"On"}'

Option 4: Dell System Update on Linux

curl -O https://linux.dell.com/repo/hardware/dsu/bootstrap.cgi
bash bootstrap.cgi
yum install dell-system-update        # or apt install dell-system-update on supported distros
dsu --preview
dsu --apply-upgrades
reboot

Update Order and Verification

Apply iDRAC, then BIOS, then CPLD if present, then PERC, then NIC/HBA, then backplane, and
PSU last. Update only one iDRAC at a time inside a blade chassis. After the reboot, verify
with:

racadm -r 192.168.1.100 -u root -p 'password' getversion
dmidecode -t bios | grep Version
omreport chassis info        # if OpenManage Server Administrator is installed

If iDRAC becomes unresponsive after a failed flash, reset the controller before assuming
the worst: racadm racreset hard, or ipmitool mc reset cold from the
host, or a full AC power drain for 30 seconds. On 14th-generation and later platforms the BIOS
keeps a redundant image and rolls back automatically, but a corrupt iDRAC needs the AC drain.

For the wider picture — licensing tiers, IPMI fallback, and how iDRAC compares with HPE iLO
— see iDRAC vs iLO vs IPMI: out-of-band server management, and if you are scripting the fleet, iDRAC Redfish API automation with Python and PowerShell pairs well with this article.

原文链接：https://www.dell.com/support/manuals/en-us/poweredge-r6415/idrac9_7.xx_ug_14g/updating-device-firmware