Firmware updates

Firmware — BMC, BIOS, NIC, drive, CPLD — is updated out of band from a small catalogue: an entry names the hardware, the component, the version that hardware should run, and the image file. Luna compares the catalogue with the inventory it holds, says what a push would do, and flashes only what you ask it to. It needs BMC access with an Operator account, and a BMC that offers an update service.

The catalogue

# luna firmwarecatalog add r181-bmc --manufacturer GIGABYTE --model R181-Z91-00 \
      --component BMC --version 12.61.25 --imagefile rom_v12.61.25.ima_enc
# luna firmwarecatalog list
# luna firmwarecatalog show r181-bmc
  • Manufacturer and model are written as the board reports them — see showinventory. The catalogue is keyed on hardware, never on a group: one group can hold several platforms.
  • The component is named as the board's own firmware inventory names it (BMC, BIOS, …), for the same reason.
  • The version is a string the vendor defines. Luna never orders versions; wanted is whatever the catalogue says, and a node whose running version the inventory does not know is refused a push rather than guessed at.
  • The image is a bare file in Luna's files directory on the active controller, placed there by the administrator. The entry is refused when it names a path, or a file type the file server would demand a token for — a BMC has none to present. Whether the file is actually there is checked again at push time, on whichever controller is active.

Preview, push, status

# luna node firmwarepush node002 --dry-run
# luna group firmwarepush gpu --dry-run           # thousands of nodes, grouped by cause
# luna node firmwarepush node002
# luna group firmwarepush gpu --component BMC
# luna firmwarecatalog status
# luna firmwarecatalog status node002

A dry run contacts nothing: it compares catalogue against inventory, checks the image is staged, and reports per node — or, for a group, by reason (already at the wanted version, no catalogue entry for this hardware, no inventory, image missing, …).

A push records one request per node. Requests are replicated between the controllers, so either answers status the same way, and a push survives a failover. The flash itself runs from the active controller only, in bounded batches; a flash can take ten to thirty minutes per board.

status shows the newest request per node with its state, and keeps a restore a flash still owes on the node's row until it settles.

How an image reaches a board, and what is checked

Where the board can fetch, it is given a URL on the controller and downloads the image itself; where it cannot, the controller streams the file to it. The board's own update task is followed to the end, and then the one question that matters is asked: what are you running now? A task that reports "completed" proves the service finished; the running version is the evidence, and the check waits out the BMC's own reboot rather than reading silence as failure.

When a flash resets the BMC

On some boards a BMC flash reinitialises the BMC to factory defaults — DHCP, default credentials, gone from the network Luna put it on. Luna does not fight that; it restores it, in band, the next time the node installs:

  1. The request is marked as owing a restore, on both controllers.
  2. At the node's next install, the BMC setup gives the BMC its address and credentials back, and the install holds a bounded time so the reset lands inside the hold rather than mid-install.
  3. The controller verifies the BMC answers on its intended address with the stored credentials and re-applies the BIOS configuration it last recorded for the node. The outcome lands on the request.

The hold is only rendered into an install when something is actually owed, so a machine that owes nothing installs at full speed.