How to Copy New Kernel Log into Text Form

The kernel log is the single most useful diagnostic a miner can hand you. It is the running record of what the control board saw as it powered up and talked to the hashboards — ASIC chip counts, voltage-domain init (plus PIC init on the older models that carry a PIC chip — S21-generation boards have none), temperature-sensor reads, fan RPM, network state, and every error the firmware threw along the way. When a board won’t hash, a chip count comes up short, or a unit drops off the pool for no obvious reason, the answer is almost always sitting in that log. This guide shows you how to pull the kernel log off an Antminer and save it as a clean text file you can search, archive, or attach to a repair ticket.

Why capture the log instead of just reading it on screen

The web dashboard shows the log in a small scrolling pane that clears on reboot and truncates older entries. A saved text file gives you three things the live view doesn’t: a permanent record from before the fault (rebooting to “try again” often erases the evidence), a document you can keyword-search for terms like fail, eeprom, chain, or temp, and something you can send to a repair tech without needing physical access to the machine. Capture first, diagnose second.

What you need

• The miner’s IP address on your LAN (find it on your router’s DHCP client list, or with an IP scanner / the Bitmain IP Reporter tool).
• A computer on the same network as the miner.
• A web browser, plus the miner’s login (stock Antminer firmware ships with user root / password root unless you changed it).
• A plain-text editor — Notepad, TextEdit (set to plain text), or any code editor. Avoid word processors that add formatting.

Method 1 — Capture from the web interface (stock firmware)

1. Open the dashboard. Type the miner’s IP into your browser (for example http://192.168.1.50) and log in.
2. Go to the log page. On stock Antminer firmware this is under System → Kernel Log; some builds label the equivalent view Miner Log or Logs in the left-hand menu. Choose the current log to analyze a live fault, or the history log when you’re chasing an intermittent problem or a unit that was unstable earlier.
3. Select the entire log. Click into the log pane and select from the very first line to the very last. For a long log, click the first line, scroll to the bottom, then hold Shift and click the last line to grab everything in between. Miss the top and you’ll cut off the boot sequence — which is exactly where hashboard-init failures show up.
4. Copy it. Press Ctrl+C (Cmd+C on macOS).
5. Paste into a new text file. Open your text editor, paste with Ctrl+V, and save. Name the file after the miner’s IP and the date — for example 192.168.1.50_2026-07-12.txt. When you’re troubleshooting a shelf of machines, an IP-and-date filename is the difference between a usable archive and a folder of unnameable logs.
6. Verify the paste. Scroll the saved file top to bottom and confirm the first and last lines match what was on screen. Browsers sometimes drop the tail of a long selection.

Faster: save the whole page

Instead of selecting text by hand, you can often press Ctrl+S on the log page to save it directly, or right-click → Save as. If the firmware exposes the raw log at a fixed URL, browsing straight to it and saving gives you the complete file with nothing truncated.

Method 2 — Pull the log over SSH (DCENT_OS and other SSH-enabled firmware)

If the machine runs DCENT_OS or any other firmware with SSH enabled, you can grab the log non-interactively, which is cleaner and never truncates. From a terminal:

• ssh root@192.168.1.50 to log in, then run dmesg for the kernel ring buffer. dmesg works on essentially every build; on firmware that ships systemd you can also use journalctl -k.
• Or dump it straight to a file in one shot: ssh root@192.168.1.50 "dmesg" > 192.168.1.50_2026-07-12.txt

This is the method to prefer for scripting or for logging a whole hashcenter — you can loop it across a range of IPs and archive every machine’s kernel log automatically.

What to look for once you have the log

You don’t have to be an engineer to spot the usual suspects. Search the file for:

• Chip / ASIC count mismatches — lines reporting fewer chips found than the board should have. A board that reads well under its rated chip count (for example an S19-generation board showing far fewer than its normal per-board population) points to a dead chip or a broken chain, not a software glitch.
• Chain / hashboard init failures — entries mentioning chain, eeprom, or a board failing to open. A hashboard whose EEPROM won’t read usually needs a physical repair, not a firmware reflash.
• Voltage-domain and PIC errors — the log records power-up of each hashboard’s series-connected voltage domains (voltage is regulated per domain, not per individual chip). A domain that won’t come up isolates the fault to one region of the board.
• Temperature-sensor faults — missing or out-of-range sensor reads, which can shut a board down even when the ASICs are fine.
• Fan and PSU warnings — low or zero RPM, or the controller reporting a power-supply problem.

Log the machine while the fault is happening. A log captured after a reboot often looks clean because the failing board was dropped from the config on restart.

How to confirm you captured it correctly

• The file opens in a plain-text editor and shows readable log lines, not garbled characters or HTML tags.
• It starts at the boot / power-up sequence (the earliest timestamps) and runs to the most recent entry.
• Searching for an obvious keyword like chain or temp returns hits — proof the content pasted and isn’t an empty or partial file.
• The filename identifies which machine and when, so the log is still meaningful a week from now.

Safety and good practice

Capturing a log is a read-only, keyboard-and-browser task — there’s nothing electrically dangerous about it, and you never need to open the unit. That said: keep miner web interfaces off the public internet (put them behind your LAN or a VPN, and change the default root password), and never paste a raw log into a public forum without scrubbing your local IP addresses, pool credentials, and any worker names you’d rather not share.

Related

With the log in hand, run the symptoms through the ASIC fault finder to map error patterns to likely failures, keep the machine’s manual handy for the correct chip count and layout of your model, and when the log points to a hardware fault, start a repair and attach the file so the diagnosis is done before the board even lands on the bench.