mirror of
https://github.com/xcat2/confluent.git
synced 2026-10-15 08:12:04 +00:00
Markus Hilger
b0ae4f201d
Three things stopped a redfish firmware update on MegaRAC. The AMI handler opened by asking the bmc to preserve fourteen named settings, and a build that knows a different set rejects the whole request, which aborted the update before anything was uploaded; send only the keys the bmc advertises. The multipart push carried the image alone, and the specification has it carry an UpdateParameters part too, which this firmware enforces. AMI also wants an OemParameters part naming the kind of image, and nothing was supplying one. The kind of image is asked for rather than worked out from the file. The extension is vendor habit rather than format, and the leading bytes answer just as confidently about an image they have never seen, while being wrong means a bmc flashed with a bios image. So nodefirmware takes --type, it travels as far as the handler that wants it, and where the bmc publishes the types it accepts, an unknown one is refused with the list, as is asking with none. A platform that reads the kind of firmware out of the image itself refuses the option rather than dropping it, so nobody aims an update somewhere they did not mean to. A parameter file still wins, since it can carry more than the image type. Updating the bmc takes the bmc, and the task being watched, away for minutes. That is the update working rather than the monitoring failing, so wait a bounded while for it to answer again instead of reporting a successful flash as an error.
84 lines
4.0 KiB
Markdown
84 lines
4.0 KiB
Markdown
nodefirmware(8) -- Report firmware information on confluent nodes
|
|
=================================================================
|
|
|
|
## SYNOPSIS
|
|
|
|
`nodefirmware <noderange> [list][updatestatus][update [--backup] [--parameterfile <file>] <file>]|[<components>]`
|
|
|
|
## DESCRIPTION
|
|
|
|
`nodefirmware` reports and updates various firmware on nodes. By default it
|
|
will retrieve all firmware, but can be directed to fetch specific firmware by
|
|
calling out the name of the firmware (e.g. uefi or xcc) or request reading only
|
|
core firmware firmware by using the word 'core', which is generally a quicker
|
|
operation. Different hardwaremanagement.method indicated plugins may have
|
|
different capabilities available. For example, the 'core' distinction may
|
|
not be relevant to redfish. Additionally, the Lenovo XCC makes certain
|
|
information available over IPMI that is not otherwise available (for example
|
|
the FPGA version where applicable).
|
|
|
|
The updatestatus argument will describe the state of firmware updates on the
|
|
nodes.
|
|
|
|
In the update form, it accepts a single file and attempts to update it using
|
|
the out of band facilities. Firmware updates can end in one of three states:
|
|
|
|
* `error`: The attempted update encountered an error that prevented successful install. Nodes experiencing this state will be reported at the end and more detail on the error will be given
|
|
* `pending`: The firmware update process has completed, but the firmware will not be active until the relevant component next resets. Generally speaking, for UEFI update the system will need a reboot, and for BMC updates, the `nodebmcreset` command will begin the process to activate the firmware.
|
|
* `complete`: The firmware update process has completed and activation has proceeded. Note that while the activation process has commenced, the component may still be in the process of rebooting when nodefirmware exits.
|
|
|
|
## OPTIONS
|
|
|
|
* `-b`, `--backup`:
|
|
Target a backup bank rather than primary
|
|
|
|
* `-m MAXNODES`, `--maxnodes=MAXNODES`:
|
|
When updating, prompt if more than the specified number of servers will
|
|
be affected
|
|
|
|
* `-p PARAMETERFILE`, `--parameterfile=PARAMETERFILE`:
|
|
For updating, a parameter file to provide along with the update payload. See
|
|
PARAMETER FILE below
|
|
|
|
* `-h`, `--help`:
|
|
Show help message and exit
|
|
|
|
## PARAMETER FILE
|
|
|
|
The parameter file given with `-p` holds JSON that is sent alongside the image.
|
|
Its keys are the parts a Redfish multipart update accepts, so `UpdateParameters`
|
|
for the standard fields and `OemParameters` for whatever a vendor asks for on top
|
|
of them. Without one, an update names no targets, which means "whatever this
|
|
image is for", and that is what most platforms want.
|
|
|
|
Some platforms will not take an image without being told what kind of firmware it
|
|
holds, and refuse the update rather than guess. On an AMI MegaRAC that is an
|
|
`ImageType` under `OemParameters`:
|
|
|
|
{"OemParameters": {"ImageType": "BIOS"}}
|
|
|
|
Attempting the update without it names the types the platform accepts in the
|
|
error, so there is no need to look them up first. The value is checked against
|
|
the same list before anything is uploaded, so a name the platform does not accept
|
|
is refused rather than sent.
|
|
|
|
## EXAMPLES
|
|
|
|
* Pull firmware from a node:
|
|
`# nodefirmware r1`
|
|
`r1: IMM: 3.70 (TCOO26H 2016-11-29T05:09:51)`
|
|
`r1: IMM Backup: 1.71 (TCOO10D 2015-04-17T00:00:00)`
|
|
`r1: IMM Trusted Image: TCOO26H`
|
|
`r1: UEFI: 2.31 (TCE128I 2016-12-13T00:00:00)`
|
|
`r1: UEFI Backup: 2.20 (TCE126O)`
|
|
`r1: FPGA: 3.2.0`
|
|
`r1: Broadcom NetXtreme Gigabit Ethernet Controller Bootcode: 1.38`
|
|
`r1: Broadcom NetXtreme Gigabit Ethernet Controller MBA: 16.8.0`
|
|
`r1: Broadcom NetXtreme Gigabit Ethernet Controller Firmware Package: 0.0.0a`
|
|
`r1: ServeRAID M1215 MegaRAID Controller Firmware: 24.12.0-0038 (2016-10-20T00:00:00)`
|
|
`r1: ServeRAID M1215 Disk 28 MBF2600RC: SB2C`
|
|
`r1: ServeRAID M1215 Disk 29 MBF2600RC: SB2C`
|
|
`r1: ServeRAID M5210 Disk 0 MBF2600RC: SB2C`
|
|
`r1: ServeRAID M5210 Disk 1 MBF2600RC: SB2C`
|
|
`r1: ServeRAID M5210 Disk 2 MBF2600RC: SB2C`
|