VNISH Ninja · Academy
Before Changing ASIC Firmware: Evidence and Recovery Checklist
Before changing firmware, freeze a small evidence pack that identifies the device, the planned bytes and the recovery owner. The pack does not choose a file for you; it makes a wrong assumption visible before the miner is changed.
Working method
- Identify the exact model, submodel, cooling type and control-board platform using read-only evidence. Family names such as S21 are not enough.
- Capture the current firmware version, security or lock state, relevant configuration, screenshots and recent logs. Store secrets outside the pack.
- Resolve the target only through the current VNISH route for the exact combination. Record filename, version, byte size, SHA-256, source URL and retrieval time.
- Write the recovery path before change: required image or method, who owns the decision, access dependencies and the condition that triggers recovery.
- Define stop conditions. Any mismatch, UNKNOWN mandatory field, unexpected reboot loop, missing boards or unsafe cooling state means stop and escalate.
Work through a situation
Learning scenario - not a reported customer result.
Consider a hypothetical handover in which the next operator receives an archive and the message 'This worked before'. The missing information matters more than the confidence of the message. Which device was involved, what was its starting state, and was the earlier result actually checked?
Turn that handover into a small evidence pack before any change. Keep one record for the planned device identity, a second for the current firmware and configuration observations, and a third for the intended file and its source. Add the permitted recovery method, its dependencies and the person responsible for the decision.
A configuration export is a record of settings; it is not automatically a complete recovery image. Keep credentials and other access secrets outside the shareable pack. If a required fact cannot be established, write 'unknown' and hold the change.
This process does not require opening the case or testing a flashing command to discover what happens. Its practical output is a clear list of resolved facts and remaining questions that another operator can review without repeating unsafe assumptions.
Limits and stop conditions
- Aftermarket firmware is not made or approved by BITMAIN. BITMAIN warns that unauthorized firmware or overclocking can cause malfunction and affect warranty; current vendor terms and the sales contract control.
- Do not open a miner merely to identify a board when a read-only method is available.
- Do not assume rollback is universal or that returning to stock restores warranty or removes traces.
Reusable artifact
| # | Field | Checked | Evidence / note |
|---|---|---|---|
| 1 | Device identity and board evidence | □ | |
| 2 | Before-state screenshots, config export and logs | □ | |
| 3 | Target file identity and SHA-256 | □ | |
| 4 | Recovery owner, method and dependencies | □ | |
| 5 | Change window and explicit STOP triggers | □ |
Copy this structure into a change record; never place passwords, keys or private access details in it.
Terms used in this guide
- Baseline
- The recorded state before a planned change.
- Configuration export
- A saved representation of settings; its scope must be checked rather than assumed.
- Recovery dependency
- A resource or access condition required by the chosen recovery method.
Check your understanding
These questions check understanding. They do not approve an installation or certify a result.
Is 'worked before' sufficient installation evidence?
Show answer
No. The device, starting state, artifact, procedure and checked result must be identified.
Is a settings export automatically a recovery image?
Show answer
No. Configuration evidence and a usable recovery method are different items.
Where should passwords or private access tokens be kept?
Show answer
Outside the shareable evidence pack, using the operator's approved secret-handling process.
Primary sources
- BITMAIN - generic online-upgrade precautions (updated 2026-03-03) Reviewed 2026-09-10
- BITMAIN - read-only control-board information Reviewed 2026-09-10
- BITMAIN - Product Warranty Reviewed 2026-09-10
- BITMAIN - Malware and remote attacks Reviewed 2026-09-10