Run DCENT_OS From Your Own Build

You compiled dcentrald. This page gets that binary onto a miner and running, without flashing anything. It is the shortest honest distance between a build artifact and a live daemon — and it stops exactly where our evidence stops.

Who this page is for

You are comfortable with a Linux shell and SSH. You have built software before, but you have probably never built embedded firmware, and you do not want to learn Buildroot to find out whether this works on your hardware. You own the miner you are pointing this at.

If that is not you, two better doors:

• You want the firmware, not the compiler — start at DCENT_OS and install routes by control board.
• You want a managed path — DCENT_Toolbox handles discovery and readiness checks for you.

You will also need the binary. Build DCENT_OS from source covers the toolchain, including the C cross-compiler prerequisite that stops most first builds.

Deploy lands is not mining runs

Two different things get confused constantly, so we separate them everywhere on this page:

• Deploy lands — the binary is on the miner and the process starts.
• Mining runs — the daemon accepts a hash board and dispatches work.

The second does not follow from the first. The daemon admits an exact control-board row before it will construct a mining arm, and most rows are refused at that gate.

What you actually get, per control board

The last row is the one to plan around. The helper fingerprints the board from /etc/bos_platform first, then falls back to a UIO-count and model-string heuristic. If none of those match — no /etc/bos_platform, fewer than 19 UIO devices, no recognised model string — the final branch defaults to AM1, persistent, writing to /data. It does not default to the RAM-only path. On an unfamiliar unit, pass --runtime-only and force /tmp yourself rather than trusting detection.

Same chassis, different board. An "S19j Pro" can be a Zynq, a BeagleBone, an Amlogic or a CVitek unit, and the model on the sticker does not tell you which. Fingerprint the control board first — install routes by control board lists what each board target is authorized for.

The S17 and T17 refusal is real, and we are not going to soften it

The board target am2-s17p carries a hard refusal in the source. Its runtime status is management-only by policy, gated on "TD-003 scaffold; S17/BM1397 promotion pending", and its work engine is management-only. The gate matches the family by model string and again by the baked board-target marker as defence in depth, and parks the daemon management-only before I2C, fan, FPGA, voltage, ASIC initialisation or hash dispatch. The API stays reachable in a read-only management posture; the daemon neither exits nor continues to mining. The deploy helper will happily copy a binary to an S17 — the transport does not know about the gate — but the daemon will not build a mining arm on it. There is no S17 install route and we do not claim one. If you see a hashrate number attached to DCENT_OS on an S17 anywhere, it did not come from us.

The packaging driver does list an am2-s17pro target, labelled experimental and package-only. Package-only means a tarball can be produced; it does not mean the daemon will mine with it. Those are different claims and we keep them apart.

If you want to change the firmware on one of these machines today, the vendor and third-party images for that family — stock Bitmain, BraiinsOS, VNish — are the routes that exist, and our troubleshooting library covers that hardware in depth. Chip canon while you are here: BM1397 is the S17, S17 Pro, T17, S17+ and T17+; the S17e and T17e are BM1396, a distinct silicon family, not a "plus" variant.

Before you touch the miner: back up NAND

The repository ships backup and plan/validate helpers per family under DCENT_OS_Antminer/scripts/ — am1_nand_backup_plan.sh then am1_nand_backup_execute.sh for the S9, with am2_ and am3_bb_ siblings. Run the plan step first and read what it intends to do. Keep the resulting image and its manifest somewhere that is not the miner.

On boards where this page only deploys to /tmp, a power cycle is already a complete rollback — nothing on flash was modified. That is most of the safety story on AM2 and Amlogic, and it is why the helper defaults those families to RAM.

Deploy

The entry point is scripts/dev_deploy.sh, called directly. It detects the control-board family, picks the conservative policy for it, selects the cross-compile target, builds --release, copies the binary over SSH, stops the incumbent mining process and launches dcentrald. The Makefile also carries a one-argument deploy alias; it forwards here but cannot pass the flags the policy gates below require, so it refuses on every board family. Call the script directly.

The invocation differs by family, and the difference is not cosmetic — the wrong one refuses before it does anything.

AM2 Zynq and Amlogic — runtime-only, so --config is mandatory

cd DCENT_OS_Antminer
scripts/dev_deploy.sh 203.0.113.97 \
    --config my-pool.toml \
    --verify \
    --rollback-on-fail

AM1 / S9 — persistent, so --output is mandatory

cd DCENT_OS_Antminer
scripts/dev_deploy.sh 203.0.113.97 \
    --output deploy-receipt.json \
    --verify \
    --rollback-on-fail

Any board, forced into RAM — a reasonable first move even on an S9

cd DCENT_OS_Antminer
scripts/dev_deploy.sh 203.0.113.97 \
    --runtime-only \
    --config my-pool.toml \
    --verify

--runtime-only switches the board into runtime-only mode before the policy gates run, so it takes --config and no longer takes --output.

The flags, all of which do what they say:

• --config FILE — deploy a specific dcentrald.toml alongside the binary. Mandatory on runtime-only boards.
• --output FILE — write a JSON transaction receipt. Mandatory on persistent boards.
• --runtime-only — never write to persistent storage, on any family.
• --verify — check the daemon answered after launch instead of assuming it did.
• --rollback-on-fail — restore the previous binary if the new one does not come up.
• --tail — stream the log.
• --dashboard-only — push only the web UI, skipping the Rust rebuild. The repository's own figures put a cold Rust cycle at roughly ten minutes and this at about thirty seconds; those are its numbers, not a measurement of ours.
• --skip-build — deploy an already-built binary.

Two guardrails you will hit, and why they are there

Both are refusals by design. Neither is a bug, and neither can be worked around by omitting the flag.

Runtime-only boards demand an explicit config

On AM2 and Amlogic the deploy stops and tells you that runtime-only mode requires --config, so the launched process can be bound to immutable content. A /tmp process must be bound to configuration you chose rather than inheriting whatever happened to be lying around on the unit. Write a small TOML with your pool in it and pass it.

Persistent boards demand a receipt

On an S9 — and on any board the script could not fingerprint — the deploy writes to /data, so it insists on --output FILE before it proceeds: the mutation has to leave a retained transaction record. It then probes the target for persistent-recovery transaction schema v4 and aborts if the unit cannot confirm support.

First boot behaviour, and the donation

A fresh DCENT_OS start comes up management-only: dashboard, SSH and API are up, hash power is off, until you turn mining on. A deploy will not surprise-start a loud miner in your house.

DCENT_OS has no dev fee. There is nothing skimmed off the top and nothing you cannot turn off. What it does have is an optional donation, and we are straight about it: it ships on, at 2%. You set it at first boot — the wizard has a step called "Optional donation" with a 0–5% slider and a one-click 0% preset — or change it any time from Settings, or through POST /api/config/donation. At 2%, your miner spends 72 seconds of each hour on D-Central's pool and the other 3,528 on yours, with a "DONATING" badge visible the whole time. Set it to zero and every share is yours.

We would rather ask than take. The setup wizard says so in as many words: "Please leave at least 1% enabled. This is the project's revenue model." You can decline — that is the point. The line that sets the number is in the public GPL-3.0 source, and the daemon shows the split while it runs.

Verify you got what you think you got

Do not trust "it deployed". Check the daemon's own view of the board:

ssh root@203.0.113.97 'ps | grep dcentrald'
curl -s http://203.0.113.97/api/status

A daemon that is up and reporting management-only on an AM2 board is a correct result, not a failure. That is the ceiling for that family today.

Getting back to stock

Honest summary, family by family:

• Deployed to /tmp (AM2, Amlogic, or any board with --runtime-only) — power-cycle the miner. Nothing on flash changed. This is a complete rollback and it is why the helper defaults to it.
• Deployed persistently to an S9 — remove /data/dcentrald and /data/dcentrald.toml and reboot. The scripted stock restore is disabled, so if flash itself was modified, your NAND backup is the route back.
• Zynq AM2 S19 stock restore — the compatibility entry point performs no storage, environment or boot-selector writes and refuses. Use signed model-specific recovery media.
• Amlogic S21 — a revert script exists and is code-complete, but it is marked not live-tested in its own header. Treat it as untested.

Before you deploy persistently to an S9, there are four things worth doing and one of them is almost always better than the persistent route:

• Take a full NAND backup and verify it.
• Keep serial console access available. Automatic failed-boot rollback is not guaranteed on any board.
• Prefer the fully reversible path first: the S9 boots DCENT_OS straight from an SD card with no NAND write at all — pull the card to revert. See the reversible S9 SD trial.
• Or force the runtime path with --runtime-only, which puts even an S9 in /tmp.

If you are not willing to lose the miner, do not go past the RAM-only route. We would rather you stop here than discover the recovery gap yourself.

Where each model actually stands

We separate two things that our own copy used to run together, because collapsing them always flatters the firmware: whether the silicon has been proven to mine, and whether we ship an install for it. Neither column is a support claim, and one column being green does not colour the other.

On the S19 Pro specifically: the shipped configuration sets no mining model, so hardware admission bails before the experimental driver loader runs. Reaching it takes a config the operator wrote themselves. That is what "operator-edited config" means everywhere on this site, and it is a deliberate barrier rather than an oversight.

The board registry and the platform notes do not agree perfectly about the S9: the install matrix marks it public-beta-installable, while the platform notes still call for a witnessed live-install capstone. Where the two disagree, this page follows the stricter one.

Credit where it is due

Board detection reads /etc/bos_platform, a file written by BraiinsOS. Braiins made the Antminer control board an open, scriptable Linux target years before we shipped anything, and the warm-takeover route on this page depends on that work. We kept the option name rambo_mode_max_bad_responses from bosminer verbatim so the ecosystem's vocabulary keeps working. Buildroot, the Rust project and Xilinx all publish better documentation for their own layers than we could write, and we link to it rather than clone it.

Report what you find

Per-model validation is expanding and community bench evidence is how rows move. If you run this on hardware we have not proven, the useful thing to send is what the daemon detected, what it refused, and what it did next. See how to contribute.

Where to go next

• Build from source — the toolchain, the C cross-compiler prerequisite, and what the repository does and does not contain.
• Install routes by control board — every board target and its authorization level, generated from the board registry.
• S9 SD trial — the fully reversible way to try DCENT_OS with no write to the unit at all.
• Configuration — the dcentrald.toml reference.
• Uninstall — going back.

Checked against the public GPL-3.0 tree at commit 6f61603. No hardware outcome is asserted anywhere on this page. No miner was touched by any author of it; every statement describes what the published code does when you run it. Rows marked Verified were read at file and line or executed; rows marked Experimental follow the repository's own per-model notes; where the repository and our bench notes disagree, this page follows the more conservative of the two.