Uninstall DCENT_OS — Restore Stock Firmware

Closed firmware keeps you by locking the door. DCENT_OS keeps you — or doesn't — on the merits, so the exit is documented before the entry is recommended. The project's own testing doctrine puts it first: "always keep a known-good recovery path (SD card, stock/BraiinsOS slot, or a full NAND backup) before writing anything persistent to a miner." Here is every exit door, with its evidence status stated plainly.

Golden-rule quote: DCENT_OS repo TESTING.md ("Golden rule"), verbatim, fetched 2026-08-13.

The exit doors, by how you tried DCENT_OS

How to leave DCENT_OS, per trial lane
How you're running it	How you leave	What survives
Bitaxe / ESP device (flashed at /flash/)	Reflash the vendor's stock firmware over USB, any time	Everything — the ESP flash is fully rewritable; nothing is permanent
`/tmp` runtime trial on an Antminer	Reboot	The incumbent firmware, untouched — the trial lived in RAM
S9 SD-boot trial	Power off, remove the card, power on	The previous NAND firmware boots — the trial never wrote to NAND
Persistent NAND install (Tier 3)	The Toolbox revert-to-stock lane — see below, and read it before you install, not after	Whatever recovery path you verified before flashing

Sources: repo TESTING.md Tier 1 undo ("reflash stock ESP-Miner with esptool/Bitaxe web flasher at any time — the flash is fully rewritable over USB; nothing is permanent") and Tier 2 undo ("reboot. /tmp is RAM — the incumbent firmware boots untouched"); DCENT_OS_Antminer/docs/INSTALL/S9_XILINX.md ("Pulling the SD card returns the unit to its previous NAND firmware"); DCENT_Toolbox README.md (revert lane).

S9 SD trial: the full uninstall is removing a card

Power the miner off.
Remove the SD card and undo the boot-select you set on the way in — JP4 jumper back to its original position, or remove the uEnv.txt override.
Power on. The previous NAND firmware boots, exactly as you left it — the trial never wrote to NAND.

The trial is "SD-boot only" — not SD-to-NAND. That is why the exit is this short.

Source: S9_XILINX.md — "That is SD-boot only — not 'SD install to NAND.'"; "Preferred path #1: SD-boot try (keep the card)" steps 3–5. Step-by-step detail with boot-log context: the rollback & recovery guide.

Persistent installs: the documented exit, and its honest status

For persistent Antminer installs, DCENT_Toolbox documents a per-vendor revert-to-stock lane — dcent install --revert-to-stock — covering BraiinsOS recovery-mode NAND rewrite, VNish firmware/remove, and DCENT_OS/LuxOS uninstall.sh. The honest label from its own README: this lane is code-complete and operator-gated, with BraiinsOS/VNish live proof still pending.

# The Toolbox revert lane (persistent installs; operator-gated)
dcent install --revert-to-stock

Two honesty notes, so this page never overstates its own exit:

The DCENT_OS repository itself does not yet publish a witnessed restore-stock runbook for a persistent NAND install (we checked docs/FAQ.md and docs/INSTALL/README.md, 2026-08-13). The revert lane above is documented in the DCENT_Toolbox repository — and it carries that repository's own proof-pending label.
When a witnessed restore-stock runbook ships in the DCENT_OS repo, this page will carry it the same day, with the same sourcing discipline as everything above.

The guardrails around the persistent-install boundary

Guardrails around the persistent-install boundary
Guardrail	Published behavior
Gates before any permanent write	Tier 3 goes through DCENT_Toolbox, which enforces the safety gates: backup-first, degraded-hardware refusal, dry-run by default, signed-package verification. The dry run previews exactly what would be written — run it freely; it writes nothing
Recovery-path prerequisite	The install guide requires a known-good recovery path and warns "Automatic failed-boot rollback is not guaranteed — keep serial and SD or a verified full-NAND restore path" before flashing — the exit is a precondition, not an afterthought
Rollback primitive on A/B-slot Zynq boards	The atomic `fw_setenv` firmware-slot flip — bench-proven on our S19j Pro XIL unit, and the same primitive BraiinsOS uses to survive power loss on that exact board family. Credit where due: we learned the durable method by studying theirs.
Residual safety net	A serial or SD console available before the first post-flash power-cycle

Sources: repo TESTING.md Tier 3 (gates list, dry-run paragraph); DCENT_OS_Antminer/docs/INSTALL/README.md (rollback-not-guaranteed warning, quoted verbatim); Bible BIBLE_2026_05_17_DCENTOS_XIL_PERSISTENT_FW_SETENV.md §4–§6 (fw_setenv slot flip, BraiinsOS teardown, §6.5 console safety net).

The consequence, without hedging: if you cannot verify a stock or known-good slot, or hold a complete NAND backup, before a persistent write — do not make the persistent write. The reversible SD trial exists precisely so you never have to gamble.

Verify before you flash anything back

Whichever direction you are flashing — out of DCENT_OS or back into it — check the artifact first. The firmware verification guide covers SHA-256 and signature checks; the ASIC firmware compatibility matrix tells you which install media and recovery path your exact model and control board actually use; and the readiness checklist is the pre-flight we run ourselves.

Reviewed 2026-08-13 against the DCENT_OS repository (TESTING.md, INSTALL docs) and the DCENT_Toolbox README. A firmware you cannot leave is a firmware you do not own.

Related products, repair, and setup paths

Last reviewed August 13, 2026.