mirror of
https://github.com/xcat2/confluent.git
synced 2026-09-05 12:37:56 +00:00
Markus Hilger
dda9b47a51
Some will not take an image without being told which kind it is, and the only way to find out was to attempt an update and read the error, which writes to the bmc before it gets that far.
96 lines
4.5 KiB
Markdown
96 lines
4.5 KiB
Markdown
nodefirmware(8) -- Report firmware information on confluent nodes
|
|
=================================================================
|
|
|
|
## SYNOPSIS
|
|
|
|
`nodefirmware <noderange> [list][updatestatus][updatetypes][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.
|
|
|
|
The updatetypes argument will name the kinds of firmware image the platform has
|
|
to be told about, for use in a parameter file. Platforms that read the kind of
|
|
firmware from the image itself have none to name and say so.
|
|
|
|
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"}}
|
|
|
|
`nodefirmware <noderange> updatetypes` names the accepted types without
|
|
attempting an update. The value is also checked against the same list before
|
|
anything is uploaded, so a name the platform does not accept is refused rather
|
|
than sent.
|
|
|
|
## EXAMPLES
|
|
|
|
* Ask what kinds of firmware image a node has to be told about:
|
|
`# nodefirmware n1 updatetypes`
|
|
`n1: BMC,BIOS,MB_CPLD,SCM_CPLD,BPB_CPLD,HPM_BMC,HPM_BIOS,HPM_SCP,HPM_BIOS2`
|
|
|
|
* Update the BIOS on a platform that has to be told:
|
|
`# echo '{"OemParameters": {"ImageType": "BIOS"}}' > /tmp/bios.json`
|
|
`# nodefirmware n1 update -p /tmp/bios.json /tmp/image.bin`
|
|
|
|
* 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`
|