DCENT_OS Recovery

This unit

Hostname	(open over SSH and run `hostname`)
IP address	(the address in your browser's URL bar)
MAC	—
Firmware slot	—
Daemon (dcentrald)	not responding

Live values fill in automatically if the on-board status endpoint is reachable. If they stay blank, use the SSH commands below instead.

Recover now

Open full diagnostic Try the dashboard

The guarded action does not flash or change firmware slots. It writes a small persistent session marker before launch. If the previous hardware disposition is unresolved, it stops and reports that refusal.

1 · Connect over SSH

From a computer on the same network, connect as root over SSH (default DEV login is the root account; no password is shown on this page for safety):

ssh root@<this-miner-ip>

Replace <this-miner-ip> with the address shown in your browser's URL bar.

2 · Inspect and run guarded admission

Inspect persistent hardware-session state, then ask the init wrapper to restart. A refusal is intentional until the state is resolved:

/bin/sh /usr/libexec/dcentos/dcentrald-session-latch.sh status
/etc/init.d/S82dcentrald restart

If admission succeeds, confirm it is running:

pidof dcentrald
/etc/init.d/S82dcentrald status

3 · Check the logs

The daemon log shows why it stopped. Look at the tail and search for errors:

tail -n 100 /tmp/dcentrald.log
grep -i error /tmp/dcentrald.log | tail -20

The on-board web-server log can also help if the dashboard itself misbehaved:

tail -n 50 /tmp/dashboard.log

4 · Resolve a latched hardware session

A process exit code is not proof that hashboard rails are off. Before clearing a marker, stop the service, remove AC power, allow the unit to cool, and verify the PSU/hashboard rails are de-energized using the board's approved procedure. Then, as root, remove only the session state and retry admission:

/etc/init.d/S82dcentrald stop
cat /data/dcent/dcentrald-hardware-session.* 2>/dev/null
rm -f /data/dcent/dcentrald-hardware-session.unresolved
rm -f /data/dcent/dcentrald-hardware-session.crash-latched
rm -f /data/dcent/.dcentrald-session-latch.lock/admission-token
rmdir /data/dcent/.dcentrald-session-latch.lock 2>/dev/null || true
sync
/etc/init.d/S82dcentrald start

This is the interim operator resolver. Do not automate it. A future typed disposition journal will replace this manual verification step. To perform a sysupgrade, do not restart dcentrald after resolving the latch: keep AC removed and rails verified safe, then run sysupgrade from the management shell. The updater prevents hardware readmission until reboot.

5 · Re-flash or roll back (only if the daemon will not start)

DCENT_OS keeps two firmware slots (A/B). If the active slot is broken, you can roll back to the other slot from U-Boot environment. Do not use rollback to bypass an unresolved-session marker. Supported sysupgrade refuses unresolved hardware ownership before writing either payload, but a manual env rollback can select a slot with independent or older /data state and an older image may not enforce this latch. Remove AC power and resolve hardware state first. Then check which slot is active:

fw_printenv firmware
fw_printenv upgrade_stage

To boot the other slot on the next reboot, ask the operator/team for the exact fw_setenv firmware <slot> value for your hardware, then:

reboot

Do not raw-write NAND (dd / flash_erase / nandwrite) by hand. Use the supported sysupgrade / rollback flow only. If you are unsure, stop here and contact D-Central support — the unit is safe and reachable in this state.