DGX Spark FE: SoC capsule shows ESRT last_attempt SUCCESS but version stays 0x00000001; USB-C PD capsule staged since Feb, never attempted

Accelerated Computing DGX Spark / GB10 User Forum DGX Spark / GB10
,
1

System: DGX Spark Founders Edition · DGX OS 7.2.3 (base image 2025-09-10) · kernel 6.17.0-1014-nvidia · BIOS 5.36_0ACUM018 (2025-08-06) · fwupd 1.9.33

Summary: On Feb 21, 2026 we applied the then-current firmware set via fwupdmgr/LVFS. The EC update applied correctly (0x00000001 → 0x02004e12, verified). The SoC capsule was processed by UEFI — the ESRT records last_attempt_version = 0x02009418 with status SUCCESS — but the running version has remained 0x00000001 through today, across many reboots. A USB-C PD capsule has sat staged in the ESP since Feb 20 and the ESRT shows it was never attempted (last_attempt_version = 0). OsIndications is back to 0, so nothing ever retries. Customer Care routed us here.

Context (one line): the system later experienced an unexplained hard hang after months of uptime; given the PD stability fixes in newer bundles we suspect the incomplete firmware set may be a factor.

Questions:

  1. Is “ESRT SUCCESS, version unchanged at 0x00000001” a known ESRT readback quirk on Spark (flash actually landed), or genuine non-activation — and how do we tell conclusively?
  2. What is the supported path from this state to the July 2026 bundle (SoC 0x02009b0b / EC 0x03000508 / PD 0x00000516) — direct, or must the Feb update complete first?
  3. Is a fwupd upgrade from 1.9.33 required before attempting?
  4. Can someone confirm the correct activation procedure (we’ve seen full cold power-drain referenced) and whether any recovery path exists that does not wipe the SSD?

Technical evidence below (dates: capsules staged Feb 20, processed/recorded Feb 21, 2026).

Technical Evidence

fwupdmgr get-history (trimmed to essentials):

NVIDIA NVIDIA_DGX_Spark

├─ Embedded Controller

│ Previous version: 0x00000001 | Update State: Success | Last modified: 2026-02-21 07:04

│ GUID: 3d13c989-e6a8-4ead-95ee-921f09868f65

│ Applied: DGX Spark EC FW Update -> 0x02004e12 (LVFS Release 135056, created 2026-01-13)

├─ UEFI Device Firmware (SoC)

│ Previous version: 0x00000001 | Update State: Needs reboot | Last modified: 2026-02-21 07:04

│ GUID: b488217b-3895-4fc0-b1bf-ab7005a2d45a

│ Staged: DGX Spark SoC FW System Update -> 0x02009418 (LVFS Release 135015, created 2026-01-13)

└─ UEFI Device Firmware (USB-C PD)

Previous version: 0x00000001 | Update State: Needs reboot | Last modified: 2026-02-21 07:04

GUID: dd1a238a-5f8e-46bd-9401-a88da99c5a96

Staged: DGX Spark USB-C PD FW Controller Update -> 0x00000500 (LVFS Release 126800, created 2025-09-18)

ESRT current state (/sys/firmware/efi/esrt/entries/), read 2026-08-20:

entry0: fw_class=b488217b-3895-4fc0-b1bf-ab7005a2d45a  (SoC)

fw_version=1 last_attempt_version=33592344 (0x02009418) last_attempt_status=0 (SUCCESS)

entry1: fw_class=dd1a238a-5f8e-46bd-9401-a88da99c5a96 (USB-C PD)

fw_version=1 last_attempt_version=0 (never attempted) last_attempt_status=0

entry2: fw_class=3d13c989-e6a8-4ead-95ee-921f09868f65 (EC)

fw_version=33574418 (0x02004e12) last_attempt_version=33574418 last_attempt_status=0 (SUCCESS)

Note the contradiction on entry0: firmware recorded a successful attempt at 0x02009418, yet fw_version still reports 1.

ESP capsule directory (still present today):

/boot/efi/EFI/UpdateCapsule/

fwupd-b488217b-3895-4fc0-b1bf-ab7005a2d45a.cap 30411871 bytes Feb 20 2026 (SoC)

fwupd-dd1a238a-5f8e-46bd-9401-a88da99c5a96.cap 1051743 bytes Feb 20 2026 (USB-C PD)

OsIndications (current): data = 0x0000000000000000 — the EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY flag was consumed at the Feb boot and is never re-set, so subsequent reboots never retry the staged capsules. OsIndicationsSupported = 0x1F (capsule delivery supported).

Capsule result EFI variable: the only capsule-result variable present decodes to the EC’s capsule filename (fwupd-3d13c989-….cap) — consistent with the EC being the only device that both processed a capsule and changed version.

Current fwupdmgr get-devices (relevant lines):

Embedded Controller:        Current version 0x02004e12   Update State: Success

UEFI Device Firmware (SoC): Current version 0x00000001 Minimum Version 0x02007300

UEFI Device Firmware (PD): Current version 0x00000001 Minimum Version 0x00000400

2

Having a FW version of 0x00000001 typically means it is invalid. Usually you would see your firmware updates failing, not showing as a success.
Can you share the output of: sudo dmidecode -t 45 | egrep -A4 "EC|PD|UEFI|FLASH"

3

Thanks for the response. Requested output below.

sudo dmidecode -t 45 | egrep -A4 “EC|PD|UEFI|FLASH”

Firmware Component Name: FLASH
Firmware Version: SBP:R:2.117.42

Firmware Component Name: UEFI
Firmware Version: R:1.87.27

Firmware Component Name: EC Firmware
Firmware Version: 2.78.18.0

Firmware Component Name: PD Firmware
Firmware Version: PD0 FW1: 0.0, FW2: 0.0

Firmware Component Name: PD Firmware
Firmware Version: PD1 FW1: 0.0, FW2: 0.0

(Firmware ID / Release Date / Manufacturer report “Not Specified” on all of
these. Note dmidecode 3.5 warns it does not fully decode this SMBIOS 3.7.0
table, so that may be a parser limitation. Full 57-entry type 45 dump
available on request.)

Three observations from this table:

  1. EC 2.78.18.0 decodes exactly to the ESRT value 0x02004e12 (0x4e=78,
    0x12=18) — so the EC capsule genuinely applied. This confirms the ESRT
    is readable and accurate for devices that actually flashed.

  2. UEFI/STMM report R:1.87.27, while the staged SoC target 0x02009418
    would decode to 2.148.24. Consistent with ESRT: the SoC capsule never
    activated despite last_attempt_status = SUCCESS. That answers our Q1 —
    this is genuine non-activation, not a readback quirk.

  3. Both USB-C PD controllers report FW 0.0 / 0.0, matching ESRT’s
    “never attempted” on the PD capsule. Given this box is USB-C powered
    and the original symptom was an unexplained hard power cut, the
    unflashed PD controllers seem like the highest-priority item.

Given the above, could you advise on the remaining open questions:

Q2. What is the supported path from this state to the July 2026 bundle
(SoC 0x02009b0b / EC 0x03000508 / PD 0x00000516) — direct, or must
the Feb capsules complete/clear first?

Q3. Is a fwupd upgrade from 1.9.33 required before attempting?

Q4. What is the correct activation procedure (we have done full cold
power-drain), and is there a recovery path that does not wipe the SSD?

One additional data point: DMI type 0 reports BIOS date 08/06/2025 while
type 45 reports 09/12/2025 for the same 5.36_0ACUM018 version, in case
that inconsistency is meaningful.

4

Since the PD firmware is seen as invalid, future FW updates will probably not work. Please contact customer support to request RMA