Skip to main content
This guide covers auditing and upgrading firmware on SambaRack hardware components using the snctl firmware command group.

Key concepts

Read this section once. Everything after it depends on these six things.

Prerequisites

Firmware commands authenticate to the target devices, so device credentials must be registered first. See Device credentials.

Which device types support what

Not every component that can be audited can be upgraded through SambaRack Manager.

Choosing a target

Either --rack-id or --group must be specified. They are mutually exclusive. Both subcommands accept either one.

(Optional) Slotted device types and --index

xrdu and card are slotted — they have multiple instances per node, so --index can narrow the operation to specific slots. Pass a comma-separated list, for example 0,2,5.

XRDUs flash two components

Each XRDU contains two independently flashed components — OBMC and RDU-C. They are reported separately by firmware version, and both must be supplied separately when passing images manually.
An XRDU upgrade powers the chassis off before flashing, because the flashing tool refuses to write to a powered-on chassis. This power-off applies to every XRDU behind the endpoint, not only the slots named by --index. Plan XRDU upgrades as whole-node maintenance regardless of how many slots you are targeting.

Where firmware images come from

The cache directory is shown as Cache Location in snctl config show. Change it with snctl config update --cache-location <dir>. See Initial setup.

Check firmware versions

Audit installed firmware against the plan of record (POR).

Reading the output

FAIL means the firmware is out of date — not that the command failed. The check ran successfully and correctly reported a version mismatch.
XRDUs report their two components on separate rows:

Wide output

-o wide adds Protocol, Model, and Source columns. Source is the artifact URL of the POR firmware, which you need for airgapped upgrades:

Upgrade firmware

Push firmware to a rack’s components.
There is no strict dependency across the supported components. However, when upgrading more than one, use this order: CARD → BIOS → BMC → XRDU
BIOS and XRDU have opposite power pre-conditions — BIOS needs the host on, XRDU needs it off.
Verifying an upgrade. Run snctl firmware version --rack-id <rack_id> --device-type all about 5 minutes after a successful run to confirm the new version took effect.

Examples

Progress output

Each component reports staged progress as it flashes, followed by a per-component result list and a summary. Components already at the target version are skipped.

Airgapped environments

If your environment has no GCS access, supply the firmware file yourself with --image.
1

Look up the download URL

Run firmware version -o wide and read the Source column for the component you are upgrading:
2

Download the file out of band

From a host that does have GCS access, download it and transfer it into the airgapped environment:
3

Pass the local path

Image path format

XRDU upgrades report both components per slot, and step through staging, chassis power-off, flashing of the primary and recovery partitions for each component, a reboot, and verification:
Slots run in parallel, so lines from different slots interleave in practice.
A bare --image path is rejected for --device-type xrdu, and prefixed values are rejected for single-component types.

Upgrade procedures by device type

Follow these in the recommended order when upgrading more than one component. CARD → BIOS → BMC → XRDU

CARD (Thor NIC)

Pre-condition: the SambaNova driver daemon (snd) must be active on the host. SambaRack Manager waits for this automatically before flashing, so no manual check is required.
No power cycle is required for CARD upgradesbnxtnvm flashes take effect without a reboot. This is the one upgrade target that does not need a power operation afterward.
Verify the firmware version on every NIC interface:

BIOS

Pre-condition: the host must be powered on.
Applying the BIOS update and then immediately power-cycling the whole node can leave the host powered on but stuck before POST — it never reaches the OS. To apply the new BIOS reliably, cycle the host on its own first, confirm the SR-IOV setting, and only then power cycle the entire node. Follow every step below in order.
1

Confirm the host is powered on

2

Run the upgrade

3

Power off the node, then bring the host up alone

Omit --type so both the host and the XRDUs power off:
Then power on the host by itself. The new BIOS is applied during POST — the console shows the BIOS settings being applied, and the host may reboot once on its own before booting to the OS.
Wait 10–15 minutes after power-on for the host to finish POST and boot to the OS before continuing.
4

Confirm SR-IOV is disabled

SR-IOV must be disabled in the BIOS. The relevant attribute is PCIS007. These checks run over Redfish, directly against the BMC.Gather the BMC connection details. The BMC IP and username come from the node’s inventory — read them from the BMC row:
The BMC password comes from the secret store:
--show-value prints the password in clear text. Only use it in a secure environment, and never share the output.
Use these values for <bmc_ip>, <bmc_user>, and <bmc_password> below.Check the current value:
  • Reads "Disabled" — continue to the next step.
  • Reads anything else — disable it below.
Disable SR-IOV (a successful request returns no output):
Apply the change by cycling the host again:
Wait 10–15 minutes for the host to boot, then re-check PCIS007 and confirm it now reads "Disabled" before continuing.
5

Power cycle the entire node

Only once SR-IOV is confirmed disabled. snctl power cycle always targets the whole node, so there is no --type flag.
6

Verify the firmware version

BMC

Pre-condition: the host must be powered on.
1

Run the upgrade

2

Power cycle the node, then verify

XRDU

Pre-condition: the host must be powered off — the opposite of the BIOS pre-condition.
1

Confirm the host is powered off

2

Run the upgrade

Both components (OBMC and RDU-C) are upgraded together.
Remember that this powers off all XRDUs on the node, regardless of any --index you pass.
3

Power the node back on, then verify


Next step

Populate a new installation in one command instead of adding devices by hand. See Inventory file schema.