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.

Plan the exit for the package you actually chose

A settings export preserves configuration; it is not a full storage backup or a controller recovery image. Keep the package identity, original firmware or boot media, exact-unit backup and selected route's recovery instructions off the miner. A different controller's recovery image is not a substitute.

Current Experimental package routes and their recovery boundaries

Route	Before using it	Normal exit or failed-boot boundary
Exact native raw SD trial	Preserve internal firmware and the original boot selection; verify the full image layout and selected removable device	Complete Stop and shutdown, disconnect power, remove the card and restore the original boot selection if changed. These packages declare no NAND writes; a trial is not permission to rewrite internal storage
Base S9 first-install-only archive	Toolbox must confirm an eligible source-firmware route, accept the full backup for this exact unit and require appropriate controller recovery preparation	Use the retained route-specific restore procedure if the persistent installation does not boot. Removing a card is not a general undo for a persistent write; automatic failed-boot rollback is not guaranteed
S19j Pro Xilinx existing-runtime update	Eligible existing DCENT_OS runtime and inactive slot, full exact-unit backup and verified restore preparation	Keep backup and recovery media off the miner. Follow the recorded recovery procedure if the new slot fails; do not improvise raw boot-environment writes or assume an automatic slot rollback
S19j Pro BeagleBone developer SD payload	Keep original media; external AM335x boot assets, preparation and recovery are not supplied or verified by the public payload. No supported consumer installation path is provided	Any recovery depends on independently verified developer preparation for the exact board; this public payload does not supply a consumer trial or restore procedure. Keep original firmware and media. NAND installation and NAND revert remain disabled; a signature does not turn them into supported operations

If the miner has not booted, do not assume a dashboard Stop is available. Keep power disconnected while changing media or boot selection and use only the exact controller's retained recovery instructions. Preserve failed-trial media and diagnostics. Physical recovery qualification remains pending for the current packages.

Check the method before entering it; Match the exact package and recovery card

Historical August 2026 exit references

The following material records earlier trial and recovery doctrine. It does not authorize a current package method, consumer BeagleBone installation or generic NAND revert. Use the current method-specific recovery table above.

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

1. Power the miner off.
2. Remove the SD card and return JP4 to the original position you photographed before the trial.
3. 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.

Historical persistent-install reference and proof limits

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.

This historical command fragment is not a complete restore procedure or a runnable instruction for every current package. Use only the exact-unit route and retained recovery inputs verified before the write. It does not apply to the BeagleBone developer payload; NAND installation and NAND revert are disabled there.

# 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

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.