How to Copy Kernel Log into Text Form: A Simple Tutorial

The fastest way to pull a kernel log off a Bitmain ASIC miner is straight from its web dashboard: open the miner’s IP in a browser, go to System → Kernel Log, click inside the log pane, select everything with CTRL+A, copy with CTRL+C, paste into a plain-text file, and save it as .txt. That log is the single most useful artifact a repair tech can receive — it records what the control board saw at boot: how many ASICs each hashboard enumerated, temperature and PSU readings, and the exact line where the miner gave up. This is the quick-reference. For the deeper SSH/dmesg capture method and full line-by-line analysis, jump to the detailed companion guide linked at the bottom.

The Web-UI Copy Method (60 seconds)

1. Find the miner on your network. Type its LAN IP into a browser (e.g. http://192.168.1.100) and log in. Default Bitmain credentials are root/root unless changed. If you don’t know the IP, use the manufacturer’s IP-reporter tool or check your router’s DHCP client list — ARP resolves the IP to the miner’s MAC.
2. Open the log. On stock Antminer firmware the menu is System → Kernel Log (older builds call it Log; third-party firmware may label it Logs or System Log). The page renders the running kernel buffer as scrollable text.
3. Select and copy. Click once inside the log box, press CTRL+A to select all, then CTRL+C. The whole buffer copies even though only part is visible on screen.
4. Paste into plain text. Open Notepad (Windows), TextEdit in plain-text mode (Mac), or any editor. Press CTRL+V. Do not use Word’s default .docx — rich-text formatting mangles the log’s alignment and can strip characters a tech needs.
5. Save as .txt. Name it so it’s identifiable: S19Pro_rig4_kernel_2026-07-12.txt. Model, unit ID, and date beat log.txt every time.

Grab the whole buffer, not just the screen

The failure line is often near the top of the boot sequence, not the bottom. CTRL+A selects the entire buffer regardless of scroll position, so use it rather than dragging with the mouse. If the miner has already been running for days, the kernel ring buffer may have wrapped and overwritten the boot messages — in that case reboot the unit, let it fail again, and capture the fresh log immediately.

What to Grep For

Before you send it, skim the log for the lines that actually diagnose the fault. Most Bitmain repair verdicts come from one of these patterns. Search (CTRL+F) for:

• ASIC count per chain — lines like chain[N] has X asic or find X asic. Compare against the expected count for the model: S9 boards run BM1387, S17/T17 run BM1397, S19/S19 Pro/T19 run BM1398, S19j Pro runs BM1362, S19 XP/S19k Pro run BM1366, S21 runs BM1368, S21 Pro/XP run BM1370. A board reporting fewer chips than it should has a broken chip chain — that’s your fault domain.
• Chain detection — check chain, chain[N] not detected, or a board dropping out of the loop. A missing chain usually means a dead hashboard, a seated-but-faulted data cable, or lost power to that board.
• Temperature — chain[N] temp, read temp failed, or overtemp shutdowns. Failed temp reads point at a dead sensor or the board’s I2C path, not always the ASICs.
• Power / voltage — get power, set voltage, PSU comms errors. Voltage on these boards is regulated per voltage domain (groups of chips in series), never per individual chip — a domain that won’t hit target isolates the bad section.
• EEPROM / calibration — eeprom, crc error, read freq failed. A corrupt board EEPROM makes a physically healthy board refuse to tune.
• Fans — fan_num, fan lost, fan speed low. Firmware halts hashing if it can’t confirm cooling, so a fan fault masquerades as a dead miner.

Common Mistakes

• Screenshotting the log instead of copying text. A tech can’t search or diff an image. Always send the actual .txt.
• Capturing after a reboot loop has wrapped the buffer. If the interesting lines have scrolled off, power-cycle and grab it clean.
• Sending only the last few lines. The root-cause line is frequently in the hashboard-enumeration phase near the start. Send the full buffer.
• Confusing the kernel log with the miner status page. The status/overview page shows current hashrate; the kernel log shows the boot and fault history. Techs need the latter.

Then What?

Attach the saved .txt to your support ticket or repair intake. If the log shows a board short a chip count, a chain that won’t detect, or repeated temp/PSU faults, that unit needs bench work rather than a firmware re-flash. The kernel log tells the tech which board and which domain to probe first, which is exactly what turns a slow diagnosis into a fast one.

Related: For the SSH/dmesg capture route and a full line-by-line breakdown of what each entry means, read the detailed kernel-log capture and analysis guide. Match the symptoms in your log against the ASIC fault finder, pull board diagrams and reference material from the miner manuals library, and when it’s a bench-repair job, start a repair with us.