I have 2 ASUS GX10’s both froze on the ASUS splash screen the day after i apt update and apt upgrade. I think the problem happened because i run headless and when they didnt start up immediately i assumed i didnt power then up again and just power cycled them (probably during the flash) both broke differently.
the first one i was able to get back with the “unplug from power, hold power button 60 seconds and give it time to rebuild when you power back on”
the other did not. I tried booting to the nvidia provided rescue image. i could get to grub but trying to run installer or rescue black screened.
however, after 4 days of hazing with vendor support, and today they finally recommended rma.. i went down the rabbit hole and figured out i could get booted to a ubuntu image and reload the the firmware .cap files i got from the asus web site. This is the end of the human. i had opus dump what it thinks will help people that have the same issue. i am too worn out and frustrated to proofread it, sorry and good luck!
Recovering a Bricked ASUS Ascent GX10 (DGX Spark / GB10) After a Failed Firmware Update — Without RMA
TL;DR
A firmware update bricked two GX10 units. One came back with a power-drain reset. The
other did not. The official recovery/rescue image black-screened on both the installer
and rescue options, but a stock Ubuntu 24.04 arm64 live USB booted fine — and from
that live session I manually staged the firmware capsule onto the internal EFI partition,
armed OsIndications, and let it flash on reboot. Unit fully recovered, no data loss,
now running the current BIOS. Below is the exact procedure plus how I locked things down so
it can’t happen again unattended.
What bricked it
Both units went down after a firmware update applied through the normal package/OTA flow.
The failure mode is the dangerous part: the firmware flash takes several minutes and cycles
through multiple resets (SoC → BIOS → EC). It looks hung partway through. If you
power-cycle it because you think it’s stuck — that’s what bricks it. That is almost
certainly what happened to me.
Key takeaway: the firmware updates themselves aren’t inherently fatal. The lethal
combination is a firmware capsule applying + an interrupted reboot mid-flash.
The ASUS support experience (facts only)
- ~4 hours on the phone with ASUS support.
- They directed me to flash from a firmware/BIOS menu action that does not exist in this
BIOS for this update type — the.capcapsules use OS-driven capsule-on-disk, not an
in-BIOS flash menu. - Support eventually recommended RMA.
- I recovered the unit myself instead.
Recovery, step by step
1. Power-drain reset (try this first — it’s free)
This revived my first unit:
- Unplug the unit.
- Hold the power button ~60 seconds with power disconnected.
- Reconnect AC, power on, let it sit.
The first unit rebuilt itself and came back. The second unit did not — so I continued
below. (Everything that follows is because the drain reset did not work on the second unit.)
2. Rescue/installer image black-screens — but a stock arm64 live image boots
- I tried to boot the official GX10 recovery image. Both the installer and the rescue
options went to a black screen and locked up. Could reach the recovery image’s GRUB,
but selecting installer or rescue → black screen, dead. - I could, however, boot a stock Ubuntu 24.04 desktop arm64 live USB (“Try Ubuntu”).
That gave me a working terminal — which is all that’s needed.
Note: it must be an arm64 / aarch64 image. The GX10 is Grace-Blackwell (GB10) ARM.
3. From the live session: stage the capsule onto the internal EFI partition
First, confirm efivars is accessible (this is what makes capsule arming possible):
ls /sys/firmware/efi/efivars | head
If that lists variables, you’re good.
Identify the internal EFI System Partition. On mine it was the small FAT32 partition on the
NVMe (nvme0n1p1, labeled efi). The capsule USB was a separate FAT32 stick holding the
ASUS .cap files.
sudo mkdir -p /mnt/esp /mnt/fw
sudo mount /dev/nvme0n1p1 /mnt/esp
mount | grep nvme # MUST show: /dev/nvme0n1p1 on /mnt/esp type vfat
sudo mount /dev/sda1 /mnt/fw
Verify the ESP mount actually took. The internal ESP contains the real bootloader files
(grubaa64.efi,shimaa64.efi,BOOTAA64.CSV,grub.cfg). Ifls /mnt/esp/EFI/ubuntu/
shows those, you’re on the real disk. If you skip the mount, you’ll copy into a RAM
directory that vanishes on reboot and does nothing. (Ask me how I know.)
Copy only the combined SoC+BIOS+EC capsule to the ESP:
sudo mkdir -p /mnt/esp/EFI/UpdateCapsule
sudo cp /mnt/fw/<vendor_folder>/bsp*signed.cap /mnt/esp/EFI/UpdateCapsule/
sync
ls -l /mnt/esp/EFI/UpdateCapsule/ # confirm size matches the .cap (~30 MB for mine)
Do NOT stage the separate USB-C PD capsule here. Per the ASUS release notes, the system
can be bricked if PD firmware updates first and the system power-cycles while SoC firmware
is still updating. The combined capsule already bundles SoC+BIOS+EC.
4. Arm the capsule (OsIndications)
This is the step the vendor capsule_update.sh script omits — it copies the capsule but
only prints OsIndications instead of setting it. You have to write it yourself.
The value: 4-byte attribute header (07 00 00 00 = NV+BS+RT) followed by the 8-byte value
with bit 2 set (04 00 00 00 00 00 00 00) = “process capsule on next boot.”
printf '\x07\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00' | \
sudo tee /sys/firmware/efi/efivars/OsIndications-8be4df61-93ca-11d2-aa0d-00e098032b8c > /dev/null
Read it back to confirm:
sudo hexdump -C /sys/firmware/efi/efivars/OsIndications-8be4df61-93ca-11d2-aa0d-00e098032b8c
Expected:
00000000 07 00 00 00 04 00 00 00 00 00 00 00
0000000c
(If tee returns “Operation not permitted,” the file may be immutable — clear it with
sudo chattr -i on that path, then retry.)
5. Reboot and DO NOT TOUCH IT
sudo reboot
On reboot the firmware applies the capsule. Expect:
- ASUS splash with a green progress bar.
- The bar may reach near-full, then the screen flickers like a reset and it starts over
— this is normal. It’s applying SoC → BIOS → EC in stages, each with its own reset. - Mine flickered/reset twice, then booted to the OS.
Keep it on AC. Do not power-cycle. Do not press anything. A blank screen or a restarting
progress bar during this is expected, not a hang. Interrupting here is the one thing that
genuinely bricks it. Let it run 10–15 minutes if needed.
6. Confirm success
sudo dmidecode -s bios-version
Should report the new BIOS version. Mine came back on the updated firmware, booting normally,
no data loss.
Stop it from happening again (unattended)
The firmware reaches the machine through an OTA metapackage and fwupd. A plain
apt upgrade held the metapackage back and did NOT touch firmware in my testing — but
apt dist-upgrade/full-upgrade (and the official update steps) will pull it, and fwupd
can surface/apply it. To make sure firmware never applies by surprise:
# Pin the firmware trigger so nothing applies it without you
sudo apt-mark hold dgx-spark-ota-update-meta
sudo apt-mark showhold # confirm it's listed
# Kill the scheduled/background update paths
sudo systemctl disable --now apt-daily-upgrade.timer fwupd-refresh.timer apt-daily.timer
Do this on every unit. After this, firmware only moves when you deliberately
apt-mark unhold (or run fwupdmgr update by hand) — on AC, uninterrupted, watching it.
If/when you DO want the pending firmware (e.g. the PD update)
- Do it as its own deliberate operation, on AC, fully uninterrupted.
- Apply EC-type updates first if you want a low-risk proof (it applied cleanly on my
already-recovered unit). - Treat the USB-C PD capsule with the most caution — it’s the one with the documented
brick-on-interruption note. Give it its own undisturbed run. - Expect the long multi-reset green-bar flash. That’s normal. Don’t “rescue” it.
Summary
- Power-drain reset (60s unplugged) recovered one unit; did not recover the other.
- Official rescue/installer image black-screened on both options.
- A stock Ubuntu arm64 live USB booted fine and provided the recovery environment.
- Manually staged the combined capsule to the internal ESP’s
EFI/UpdateCapsule, armed
OsIndications, rebooted, and let the multi-reset flash complete. - Recovered with no data loss, no RMA.
- Locked the OTA metapackage and disabled background update timers so it can’t recur
unattended.
