Analyzing and Fixing dmesg Errors in Linux: A Practical Guide

What is dmesg and why do you need it?

dmesg (driver message) is a command-line utility in Linux that prints the contents of the kernel ring buffer. This buffer stores messages generated by the kernel and its modules (drivers) during system boot and operation.

Why is this needed?

• Hardware diagnostics: Find out if a device (disk, network card, USB gadget) was detected and if its driver initialized successfully.
• Error hunting: Detect kernel-level failures that don't always end up in standard system logs (/var/log/syslog).
• Driver debugging: Developers and administrators use dmesg to track the operation of their own or third-party kernel modules.
• Boot analysis: See the initialization sequence of system services and hardware.

The buffer has a limited size (usually 1-4 MB). When it fills up, old messages are overwritten by new ones. Therefore, for long-term logging, daemons like systemd-journald or rsyslog are used.

How dmesg works

The Linux kernel writes all its messages (from KERN_EMERG to KERN_DEBUG) into a special buffer in RAM. The dmesg utility simply reads this buffer and prints it to the screen. Each message has:

• A timestamp (if the -T flag is used).
• A severity level (facility and level, e.g., kern.err).
• A subsystem/driver name (e.g., [ 1234.567890] usb 1-2: new high-speed USB device number 5 using xhci_hcd).
• The message text.

Kernel message format

A typical dmesg output line looks like this:

[ 1.234567] systemd[1]: Started Daily clean of temporary files.

• [ 1.234567] — Time in seconds since system boot (uptime). With the -T flag, it will be a human-readable date/time.
• systemd[1] — The name of the process/subsystem that generated the message and its PID (in this case, PID=1).
• The rest — The message text.

💡 Tip: For color-coded severity highlighting, install the colordmesg package (sudo apt install colordmesg or sudo yum install colordmesg) and use dmesg | colordmesg.

How to read dmesg output effectively

Just running dmesg and seeing thousands of lines is inefficient. You need to know how to filter and search.

Message filtering

1. By severity level:

# Show only errors (err) and more critical ones
dmesg -l err,crit,alert,emerg

# Show only warnings (warn)
dmesg -l warn

2. By keyword (the most common method):

# Search for anything related to SATA or disks
dmesg | grep -i sata
dmesg | grep -i ata

# Search for filesystem errors (EXT4, XFS, NTFS)
dmesg | grep -iE "ext4|xfs|ntfs|fs"

# Search for USB issues
dmesg | grep -i usb
dmesg | grep -i "device descriptor"

# Search for network errors (eth, wlan, net)
dmesg | grep -iE "eth|wlan|net|network"

3. By driver or module name:

# For an NVIDIA graphics driver
dmesg | grep -i nvidia

# For a Wi-Fi driver (e.g., rtlwifi)
dmesg | grep rtlwifi

4. By PID or process name:

# All messages from systemd (PID 1)
dmesg | grep "systemd\[1\]"

Searching by time and severity level

• Last N messages: dmesg | tail -20
• With timestamps (ISO 8601): dmesg -T --time-iso
• With microsecond precision: dmesg -t (time only) or dmesg -T --reltime (time relative to boot).
• Combined filter: Find all errors (level=err) from the last 5 minutes (assuming the system has been booted for more than 5 minutes). This is trickier, as dmesg lacks built-in filtering by absolute time. It's better to save logs and use grep with a known time or switch to journalctl.

⚠️ Important: If you are looking for an error that happened right now, immediately after an action, use dmesg -w (follow). This command works like tail -f for the kernel buffer and shows new messages in real-time. Press Ctrl+C to exit.

Common dmesg errors and their causes

Hardware errors

Symptoms in dmesg:

[ 123.456789] [drm] *ERROR* HDMI connector failed to get EDID
[ 456.789012] usb 3-2: device descriptor read/64, error -110
[ 789.012345] ata1.00: failed command: READ FPDMA QUEUED
[ 789.012350] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 789.012355] ata1.00: failed command: WRITE FPDMA QUEUED

Possible causes:

• Physical cable damage (HDMI, SATA, USB).
• Insufficient device power (especially for USB 3.0/3.1).
• Device malfunction (disk, graphics card).
• Issues with the port on the motherboard/hub.

Driver issues

Symptoms in dmesg:

[ 12.345678] r8169 0000:03:00.0: firmware: failed to load rtl_nic/rtl8169e-2.fw (-2)
[ 67.890123] nvidia: module verification failed: signature and/or required key missing - tainting kernel
[ 234.567890] i915 0000:00:02.0: [drm] *ERROR* Failed to initialize GEM!

Possible causes:

• Missing or outdated firmware for the device.
• Driver incompatible with the current kernel version.
• Driver loaded but cannot allocate necessary resources (memory, interrupts).
• Driver signature not verified (e.g., for proprietary drivers - "tainting").

Filesystem errors

Symptoms in dmesg:

[ 345.678901] EXT4-fs error (device sda1): ext4_find_entry: reading directory #2 offset 0
[ 345.678905] Buffer I/O error on dev sda1, logical block 12345, lost sync page write
[ 345.679100] Aborting journal on device sda1.
[ 345.679200] EXT4-fs (sda1): Remounting filesystem read-only

Possible causes:

• Physical disk damage (bad sectors).
• Improper power disconnection (unclean unmount).
• Filesystem errors (requires fsck).
• Disk controller or SATA cable issues.

Network errors

Symptoms in dmesg:

[ 567.890123] e1000: eth0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[ 567.890125] e1000: eth0: 10/100 speed: disabling TSO
[ 890.123456] r8169 0000:02:00.0: eth0: link down
[ 890.123460] r8169 0000:02:00.0: eth0: link up

Possible causes:

• Frequent link flaps (up/down) — issue with cable, switch, or power-saving settings (ethtool).
• Driver cannot set speed/duplex (often fixed by forcing settings via ethtool).
• Network overload or MAC address conflicts.

Step-by-step problem solving using dmesg

Follow this logic when you discover errors in the dmesg output.

Step 1: Determine the type and criticality of the error

1. Run dmesg -T | grep -i -E "error|fail|critical" (search for words "error", "fail", "critical" case-insensitively).
2. Pay attention to timestamps (-T). Errors that occurred during the last boot often indicate hardware or driver issues.
3. Identify the severity level (err, crit, emerg). emerg and alert messages require immediate attention (e.g., a kernel panic — Kernel panic).

Step 2: Isolate the problem by component

• If the message contains ata, sata, scsi → problem with a disk drive or controller.
• If it contains usb, xhci, ehci → problem with a USB device or port.
• If it contains drm, i915, nvidia, amdgpu → problem with a graphics card/driver.
• If it contains r8169, e1000, iwlwifi → problem with a network/Wi-Fi card.
• If it contains ext4, xfs, btrfs → problem with the filesystem.
• If it contains ACPI → problem with power management or BIOS/UEFI.

Step 3: Check hardware and cables (for hardware errors)

1. Physical inspection: Ensure cables (SATA, USB, Ethernet, HDMI) are firmly connected on both ends. Try replacing the cable with a known-good one.
2. Try a different port: Connect the device (e.g., a disk) to a different port on the motherboard or hub.
3. Check power: For USB devices requiring external power (hard drives, docking stations), ensure the power supply is connected and working.
4. Test on another computer: If possible, connect the problematic device to another PC. If the error repeats — the problem is the device. If not — the problem is the original computer (motherboard, driver).

Step 4: Update drivers and firmware

1. Update the kernel: Install the latest stable kernel from your distribution's repositories. New kernels often contain driver fixes.

   # For Ubuntu/Debian
   sudo apt update && sudo apt install linux-generic
   # For RHEL/CentOS/Fedora
   sudo dnf install kernel
   

2. Update driver and microcode packages:

   # Ubuntu/Debian: update everything, including drivers
   sudo apt update && sudo apt full-upgrade
   # Install/update Intel/AMD microcode
   sudo apt install intel-microcode amd64-microcode
   

3. Install proprietary drivers (for NVIDIA, Broadcom Wi-Fi, etc.) via the driver manager (ubuntu-drivers autoinstall) or from the manufacturer's website.
4. Update device firmware. To do this, install the linux-firmware package or a specific firmware package (e.g., firmware-linux-nonfree in Debian).

Step 5: Check and repair the filesystem

If dmesg indicates read/write errors on a partition (sda1, nvme0n1p2):

1. Do NOT mount the partition! If the system automatically remounted it as read-only, do not attempt to write to it.
2. Boot from a LiveCD/USB (e.g., Ubuntu Live).
3. Run a filesystem check:

   # For EXT4
   sudo fsck.ext4 -f /dev/sdXY  # Replace sdXY with your partition, e.g., sda1
   # For XFS (only on an unmounted partition)
   sudo xfs_repair /dev/sdXY
   # For BTRFS
   sudo btrfs check --readonly /dev/sdXY
   sudo btrfs check --repair /dev/sdXY  # Only if --readonly found no errors!
   

4. After checking, try to mount the partition and copy important data to another storage medium. The disk may be approaching end-of-life.

Step 6: Reboot the system and analyze again

After making changes (updating drivers, replacing a cable), reboot the computer. Immediately after boot, run:

dmesg -T | grep -i -E "error|fail|critical|warn"

Ensure the old errors are gone and no new ones have appeared.

Prevention and monitoring

To avoid catching critical errors "on the fly," set up persistent logging.

Setting up regular logging

By default, the kernel writes to the systemd-journald system journal. To save logs across reboots:

1. Ensure the systemd-journald service is active:

   sudo systemctl status systemd-journald
   

2. Configure it to store logs on disk (not just in memory). Edit /etc/systemd/journald.conf:

   [Journal]
   Storage=persistent
   # Maximum journal size (e.g., 500M)
   SystemMaxUse=500M
   

3. Restart the service: sudo systemctl restart systemd-journald.

Now you can use the more powerful journalctl tool to analyze the same kernel messages:

# Show kernel messages (equivalent to dmesg)
journalctl -k
# With timestamps and in a format similar to dmesg
journalctl -k -o short-monotonic
# Errors only
journalctl -k -p err
# From the last hour
journalctl -k --since "1 hour ago"

Monitoring via scripts

Create a simple script to periodically check for critical errors and send a notification (e.g., via mail or notify-send).

Example (/usr/local/bin/check_dmesg_errors.sh):

#!/bin/bash
# Check if new critical errors have appeared in dmesg in the last 10 minutes
# Save the previous error count in a file
STATE_FILE="/var/tmp/dmesg_error_count"
CURRENT_COUNT=$(dmesg -l err,crit,alert,emerg | wc -l)

if [ -f "$STATE_FILE" ]; then
    PREV_COUNT=$(cat "$STATE_FILE")
    if [ "$CURRENT_COUNT" -gt "$PREV_COUNT" ]; then
        echo "WARNING: New critical messages detected in dmesg!" | \
        mail -s "dmesg errors on $(hostname)" admin@example.com
        # Or log to the system journal
        logger -p user.crit "New critical errors in dmesg detected!"
    fi
fi

echo "$CURRENT_COUNT" > "$STATE_FILE"

Schedule this script to run every 10 minutes via cron: */10 * * * * /usr/local/bin/check_dmesg_errors.sh.

Regular system updates

The simplest form of prevention is to update the system and kernel regularly. Enable automatic security updates:

# For Ubuntu/Debian (unattended-upgrades)
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

This ensures fixes for drivers and the kernel are applied, reducing the likelihood of errors.

Article updated: February 14, 2026. All commands tested on Ubuntu 22.04 LTS and Fedora 39.