A USB drive disappears, a network card disconnects, an SSD malfunctions, or a machine displays an error right after startup? Before randomly changing the configuration, I almost always check the kernel messages.
Under Linux, dmesg It allows you to read these messages quickly. It’s not a magic tool, but it often provides the first useful clue: an I/O error, a reset USB device, missing firmware, a complaining driver, or an unstable network link.
In this guide, I’ll show you how to use dmesg Properly speaking, cross it with journalctl -kfilter the useful lines and avoid the false good idea of changing a system option before understanding the message.
What dmesg actually displays
dmesg displays the Linux kernel message buffer. In simpler terms, you will find low-level events there: hardware detection, drivers, disk errors, USB, network, ACPI, firmware, memory, device mounting, etc.
On a modern machine, some of these messages are also visible in the systemd log. That’s why I advise you to keep both commands handy: dmesg for quick reading, journalctl -k for cleaner reading in the system log.
dmesgOn some distributions, reading may require administrator privileges. If you get a permissions error, try again with sudo.
sudo dmesgThe manual page of dmesg It details all the options. For routine diagnostics, a few commands are already more than enough.
Read the last lines without drowning
The first thing to do is not to display 800 lines at once. When a problem has just occurred, start with the end of the kernel log.
sudo dmesg -T | tail -n 80The option -T makes dates more readable. Note that while this format is convenient for quick reading, it doesn’t replace a thorough analysis of newspapers if you’re comparing very specific events. For that, journalctl remains more comfortable.
You can also display only warnings and errors:
sudo dmesg -T --level=err,warnIf the command returns nothing, it’s not necessarily a bad sign. It simply means that the kernel hasn’t recorded any recent errors or warnings in that buffer.
Filtering a USB, disk, or network problem
The real time-saving comes when you filter. If you’re looking for why a USB drive won’t mount, why a hard drive is malfunctioning, or why a network card is resetting, don’t read everything. Look for the words that correspond to the hardware.
sudo dmesg -T | grep -iE 'usb|sda|sdb|nvme|ata|error|fail|reset'For a record, the lines to watch out for are often quite self-explanatory: I/O error, reset, failed command, blk_update_request, read error, write errorIf you see this kind of message repeatedly, don’t start by rewriting it. /etc/fstabFirst check the cable, the USB enclosure, the power supply, then the condition of the disk.
For a USB device, cross-reference with the commands already seen in the guide on the USB ports in Linux or the one on the mounting a USB key. dmesg tells you what the core observes, but lsusb, lsblk And findmnt help to understand what is actually detected and mounted.
lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINTS
findmnt
lsusbFor a network issue, look for the interface name or terms like link, renamed, firmware, timeout, down, upIf the topic mainly concerns listening TCP ports, switch to ss or netstat, because dmesg does not replace a network inventory.
Follow the messages while you connect the equipment
When a device disconnects intermittently, the easiest way is to monitor the live messages. Open a terminal, run the command, then connect the disk, USB drive, or network adapter.
sudo dmesg -wH-w follow new messages. -H makes the output more readable. If you prefer to stay in the systemd log, use:
sudo journalctl -k -fThe manual page of journalctl This is useful if you want to refine the search by startup, priority, or unit. For a simple hardware failure, live monitoring is often sufficient to see if the kernel detects the branch, and then the error.
Cross-reference with journalctl for the last startup
dmesg It’s quick, but I don’t stop there if the problem affects a server or recurs after a reboot. The systemd log allows you to reread the kernel messages from the current boot, with its own filters.
sudo journalctl -k -b --no-pager
sudo journalctl -k -b -p warning..alert --no-pagerThe first command displays the kernel messages from the current boot process. The second only keeps warnings, errors, and alerts. This is useful after a reboot where a mount failed, where a network interface is not mounted correctly, or when a driver reports a problem at boot.
If you have just modified /etc/fstabDon’t restart just to see. Test the assembly first and check for errors. The guide on fstab under Linux This point needs to be explained in detail, because a bad line can block the start-up faster than you might imagine.
sudo mount -a
findmnt
sudo journalctl -k -b -p warning..alert --no-pagerKnowing when the message indicates a real hardware problem
An isolated line in dmesg This is not always enough to draw a conclusion. A USB device can reset itself once without it being serious. However, an error that recurs with every copy, a drive that alternates between disconnecting and reconnecting, or repeated I/O errors should be taken seriously.
In this case, I perform three checks before touching the configuration:
- change the cable, USB port or power supply if the device is external;
- verify that the disk is correctly identified with
lsblkAndblkid; - Check the SMART status if it is a disk or an SSD.
lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS
sudo blkid
sudo smartctl -a /dev/sdXReplace /dev/sdX by the correct disk. Do not blindly copy this command to a machine with multiple disks. If you are unsure, stop at lsblk and identify the model, size and mounting point before going any further.
Before correcting, note the exact error.
The best use of dmesgThe goal isn’t to find a magic bullet. It’s to capture a specific error before taking action. Copy a few lines around the message, note the time, the device involved, and the action that triggers the problem.
sudo dmesg -T | tail -n 120 > core-diagnostic.txt
sudo journalctl -k -b -p warning..alert --no-pager >> core-diagnostic.txtOnly then can you decide: which cable to replace, which disk to back up, which driver to check, which fstab rule to correct, which firmware to install, or which service to monitor. This step seems basic, but it prevents a lot of absurd diagnoses, especially for intermittent faults.
If you’re administering a remote machine, be even more careful. A disk or network error detected in the kernel can eventually cut off your access. Keep a session open, provide console access if possible, and don’t reboot until you understand what the kernel is trying to tell you.