The Overview page (System > Overview) is the first screen to read whenever you log into an Antminer’s web interface. It is a plain-language identity card for the unit: which model the control board thinks it is, which firmware is loaded, and which mining program is running. When any of those three disagree with the hardware physically in front of you, the miner will underperform, throw hashboard errors, or refuse to hash at all. This guide explains every field, why it matters, and how to use the page to confirm a repair or firmware reload actually worked. It applies to all Antminer models.
How to reach the Overview page
- Confirm the miner is powered and on the same network as your computer. Find its IP with the Bitmain IP Reporter tool (press the physical IP Report button on the control board) or your router’s DHCP client list.
- Type the IP into a browser and log in. The stock default is user
root, passwordroot— change it if you never have. - From the top navigation, open System > Overview (some firmware builds label it Miner Status or System Information).
What each field means
1. Miner Type
The model the control board believes it is — for example Antminer S19 Pro. This value comes from the firmware image, not from the hashboards, so a freshly swapped control board can report the wrong type. Bitmain reuses one control-board platform across several models. A donor board pulled from an S19 dropped into an S19 Pro will boot, but until you reload the firmware that exactly matches your hashboards, the autotuner runs the wrong chip-count and voltage profile and the unit will hash low or error out.
If Miner Type is wrong, do not ignore it. Reload the correct firmware for the model printed on the chassis label. See D-Central’s per-model repair manuals to confirm the exact board and firmware pairing before you flash.
2. Model / Platform
The firmware platform or build identifier — the operating-system layer the miner runs, as opposed to the mining application on top of it. On stock units this reflects the Bitmain build family; on aftermarket firmware it names the OS. Read it together with Miner Type: the platform must be one that supports your control board’s SoC, or the image will not boot.
3. File System Version (Firmware Version)
The firmware build currently installed, usually a date-stamped string. This is the single most useful field for troubleshooting. An old build on new hashboards — or a build meant for a different model — is a leading cause of missing hashrate, chips dropping off a chain, and failed autotune. Always compare this string against the latest release for your exact model before assuming a hardware fault; a clean firmware reload resolves many apparent “dead board” reports.
4. BMMiner Version / Hardware (Logic) Version
The mining program and the FPGA/logic layer it talks to. BMMiner is Bitmain’s mining daemon — the process that drives the ASIC chains and reports hashrate. If this field is blank, or the Overview shows no mining status at all, the daemon is not running: the miner is powered and networked but not actually hashing. That points to a firmware mismatch, a corrupt image, or a hashboard the controller cannot enumerate. Cross-reference the Hardware/Logic Version too — a logic version that does not match the firmware is another mismatch symptom.
Other fields worth reading
- Hostname / MAC address — unique per unit; use them to tell identical miners apart in a fleet and to reserve DHCP leases.
- Network (DHCP/Static, IP, gateway, DNS) — confirm the miner has a valid address and can reach your pool. A miner with no gateway will hash locally-reported zero and never submit shares.
- Uptime — an uptime that keeps resetting to seconds means the miner is rebooting in a loop, typically a PSU, temperature, or firmware fault rather than anything you can fix on this page.
How to confirm a repair or reload worked
- After a firmware reload, refresh the Overview page and verify Miner Type now matches the physical model on the chassis label.
- Confirm File System Version shows the build you just flashed, not the old string (a stale value means the flash did not take — power-cycle and reflash).
- Confirm BMMiner is populated and a mining status is present. No daemon, no hashing.
- Move to the miner’s status/dashboard page and confirm all three chains (Chain0, Chain1, Chain2) are detected with their full expected chip count. A board short a few chips indicates a hardware fault, not a firmware one — the Overview page was doing its job by getting you this far.
Common mistakes
- Flashing “close enough” firmware. S19 and S19 Pro share a board family but carry different chip counts per board (76 vs 114) and different domain voltages. The wrong image will boot and hash badly. Match the firmware to the model, every time.
- Assuming a blank BMMiner field means a dead miner. More often it is a mismatched or corrupt firmware image. Reload before you open the case.
- Ignoring a wrong Miner Type after a control-board swap. It will not “settle” on its own — reload matching firmware.
- Trusting Miner Type over the chassis label. The label and your hashboards are the ground truth; the firmware string is only what the last flash told it to say.
When to escalate
If the Overview page reports the correct model and current firmware, BMMiner is running, and the miner still hashes low or drops a chain, the problem is now hardware — a hashboard, the PSU, or the control board itself. That is a bench-repair job: chain-by-chain diagnosis, domain-voltage checks (remember voltage on Antminer boards is regulated per power domain, where multiple chips share one DC-DC converter, not per individual chip), and component-level work. Match the symptom to a specific fault code before you start swapping parts.
Related: Look up your exact error string in the ASIC fault finder, follow the model-specific steps in D-Central’s repair manuals, source hashboards and control boards from ASIC repair parts, or hand the whole job to the bench and start a repair.
