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 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 return JP4 to the original position you photographed before the trial.
- 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-stockTwo 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.mdanddocs/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
| 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.
Companion tool — DCENT_Toolbox: DCENT_Toolbox backup & recovery commands · Revert-to-stock with DCENT_Toolbox.