VNISH Ninja · Academy
The Miner Booted: What to Verify Before Calling the Install Successful
A reachable web interface proves only that part of the device booted. Call the installation successful only after the expected build identity, hardware inventory, cooling, pool connection and accepted work are read back over an appropriate observation window.
Working method
- Read back the exact build/version and compare it with the planned target. A familiar logo is not build evidence.
- Confirm detected hashboards and chips against the pre-change inventory. Record missing or unstable components rather than masking them with an aggregate hashrate.
- Check fans or cooling loop state, temperatures, PSU and electrical observations for the exact hardware class. Air, Hydro and Immersion are not interchangeable.
- Confirm the intended pool endpoints, worker identity and accepted work. Keep local hashrate, pool-side hashrate and share categories separate.
- Review new error logs and compare with baseline. Decide GO, HOLD or STOP; do not use a universal number of minutes as a stability guarantee.
Work through a situation
Learning scenario - not a reported customer result.
Imagine a hypothetical first boot that presents the expected logo and a readable dashboard. The useful next action is a comparison with the pre-change record, not an immediate declaration of success. Confirm that the reported build is the one planned for this device.
Compare the detected boards with the earlier inventory, then review cooling observations and new errors. Next, identify the intended worker and establish whether its pool record shows accepted work over the chosen observation period. If one board is absent but the aggregate hashrate still looks substantial, the missing board remains an unresolved condition; the total cannot cancel it.
Conversely, a brief mismatch between two dashboards is not a diagnosis until their sources and time windows are understood. Record each observation with its timestamp, keeping 'not checked' separate from 'checked and passed'. The final decision can be GO, HOLD or STOP under the site's pre-agreed conditions.
No universal number of minutes replaces this evidence. A successful first screen is a starting point for readback, not a guarantee of stable mining.
Limits and stop conditions
- A reboot loop, missing board, uncontrolled temperature, repeated pool rejection or an identity mismatch is a STOP condition.
- One healthy screen is not an end-to-end test.
- Observation duration must match the risk and site process; there is no universal stabilization window.
Reusable artifact
| # | Field | Checked | Evidence / note |
|---|---|---|---|
| 1 | Planned versus observed build | □ | |
| 2 | Board/chip inventory before and after | □ | |
| 3 | Cooling and power observations | □ | |
| 4 | Pool target, worker and accepted-work evidence | □ | |
| 5 | Errors, observation window and GO/HOLD/STOP decision | □ |
Copy this structure into a change record; never place passwords, keys or private access details in it.
Terms used in this guide
- Readback
- An observation of the device's actual state compared with the planned result.
- Inventory mismatch
- A difference between the expected and observed device components.
- HOLD
- A decision not to progress while required evidence or an operational question remains unresolved.
Check your understanding
These questions check understanding. They do not approve an installation or certify a result.
Can a high aggregate hashrate cancel a missing-board observation?
Show answer
No. The inventory mismatch remains unresolved.
Does 'not checked' mean 'passed'?
Show answer
No. These states must remain distinct in the record.
Can one fixed waiting time establish stability for every device?
Show answer
No. The observation period and acceptance conditions depend on the exact test and site.
Primary sources
- BITMAIN - generic online-upgrade precautions (updated 2026-03-03) Reviewed 2026-09-10
- BITMAIN - Antminer S21 air-cooled specification Reviewed 2026-09-10
- Bitcoin Developer Guide - Mining Reviewed 2026-09-10
- Stratum V2 - Mining Protocol Reviewed 2026-09-10