When something breaks on a Linux system, the dmesg command is where the investigation begins. This essential tool displays messages from the kernel ring buffer – a log of everything the Linux kernel knows about your hardware, drivers, and boot process. If you want to check your Linux version or understand what’s happening under the hood, dmesg gives you direct access to the kernel’s perspective.
I still remember the first time dmesg saved me from hours of frustration. My homelab server was running painfully slow, and I couldn’t figure out why. Running dmesg | grep -i error revealed a cascade of SATA errors – my drive was failing. Without dmesg, I might have spent days chasing software bugs instead of the real culprit. Let me show you how to use this powerful diagnostic tool.
What is dmesg?
The dmesg command (short for “diagnostic message”) displays kernel-related messages retrieved from the kernel ring buffer. Think of it as your window into what the kernel sees and does during hardware detection, driver initialization, and system startup.
Understanding the Kernel Ring Buffer
The kernel ring buffer is a fixed-size memory area where Linux stores messages about hardware events and kernel operations. Unlike regular log files that grow over time, this buffer overwrites older messages when it fills up. That’s why you might see thousands of lines even on a system that’s only been running a few days.
The buffer captures information about:
Get a VPS from as low as $11/year! WOW!
- Hardware detection: CPUs, memory, storage devices, network interfaces
- Driver initialization: Loading and configuring kernel modules
- System events: USB connections, disk errors, memory issues
- Boot process: Everything that happens before user space starts
Why dmesg Matters for System Administration
While the journalctl command aggregates logs from multiple sources, dmesg shows you the raw kernel view. When your system crashes, freezes, or won’t boot properly, dmesg often contains the answer.
“dmesg is one of those easily forgotten troubleshooting tools that should stay at the top of your sysadmin arsenal… contains so much information about your system that dmesg should be the first place you look when something goes wrong.”
Basic dmesg Syntax and Usage
Using dmesg starts simple – just type the command. But there are a few things to know about getting the most useful output.
Viewing All Kernel Messages
The basic syntax is straightforward:
dmesgThis dumps the entire kernel ring buffer to your terminal. You’ll see timestamps (in seconds since boot), followed by kernel messages. On most systems, this produces hundreds or thousands of lines.
Using Pagination with less and more
Reading raw dmesg output is overwhelming. Pipe it through less for easier navigation:
dmesg | lessNow you can scroll with arrow keys, search with /, and quit with q. For more details on filtering techniques, check out our grep command guide.
Understanding Permissions
On modern Linux distributions, you often need root access for complete dmesg output:
sudo dmesgWithout sudo, you might see truncated output or nothing at all. This security measure prevents non-privileged users from viewing potentially sensitive hardware information. For complete documentation of all options, see the official dmesg man page.
Understanding dmesg Output and Log Levels
Raw dmesg output can look cryptic at first. Understanding timestamps and severity levels makes the data useful.
Decoding Timestamps
By default, dmesg shows timestamps as seconds since boot:
[ 5.234567] usb 2-1: new full-speed USB deviceThat number in brackets means “5.2 seconds after boot started.” Helpful for understanding boot sequence, but not great for matching events to real-world time.
Log Level Priority System
The kernel classifies messages by severity using 8 log levels:
- 0 – emerg: System is unusable
- 1 – alert: Action must be taken immediately
- 2 – crit: Critical conditions
- 3 – err: Error conditions
- 4 – warn: Warning conditions
- 5 – notice: Normal but significant
- 6 – info: Informational messages
- 7 – debug: Debug-level messages
A healthy system should have no emerg, alert, crit, or err level messages. If you see them, something needs attention.
Facility Codes Explained
Use the -x flag to decode facility and level information into human-readable prefixes:
sudo dmesg -xThis shows you exactly which subsystem generated each message and its priority level.
Essential dmesg Commands for Troubleshooting
Here are the commands I use most often. Master these and you’ll handle 90% of kernel-level diagnostics.
Filter by Log Level
Show only errors (the stuff that actually matters):
sudo dmesg -l errShow warnings and above:
sudo dmesg -l warn,err,crit,alert,emergSearch for Specific Hardware with grep
Find all USB-related messages:
sudo dmesg | grep -i usbCheck for disk errors:
sudo dmesg | grep -i 'sda\|sdb\|nvme\|ata'Look for memory issues (often indicates failing RAM or OOM killer activity):
sudo dmesg | grep -i 'oom\|memory'Real-Time Monitoring
Watch kernel messages as they happen (like tail -f for the kernel):
sudo dmesg -wThis is incredibly useful when plugging in new hardware or reproducing an issue. You’ll see messages appear the moment the kernel generates them.
Human-Readable Timestamps
Convert boot-relative timestamps to actual dates and times:
sudo dmesg -TOutput becomes much more useful:
[Mon Sep 15 14:23:45 2025] usb 2-1: USB disconnectCombine options for maximum readability:
sudo dmesg -T -l err,warn | lessReal-World Use Cases
Theory is nice, but let’s look at practical scenarios where dmesg proves its worth.
Diagnosing Boot Problems
System won’t boot or hangs during startup? If you can access a live USB or recovery mode, check dmesg for clues. Look for errors in the early boot sequence:
sudo dmesg | grep -i 'error\|fail\|timeout'For comprehensive boot diagnostics, see our guide on troubleshooting boot problems.
Troubleshooting USB Device Detection
Plug in a USB device, then immediately check what the kernel saw:
sudo dmesg | tail -30Or use watch mode before connecting:
sudo dmesg -wIf the kernel detects the device but shows errors, you’ve got driver or hardware issues. If it doesn’t appear at all, try a different USB port or cable.
Investigating Hardware Failures
Memory errors, disk failures, and hardware timeouts all show up in dmesg. When troubleshooting system freezes, dmesg often reveals the culprit:
sudo dmesg -T -l err,crit,alert,emergI once spent an evening debugging random application crashes, only to find ECC memory error messages in dmesg. Bad RAM stick – no amount of software debugging would have fixed that.
For memory-specific issues, combine dmesg with proper checking memory usage techniques.
Checking Driver Issues
When hardware doesn’t work correctly, check if the kernel loaded the driver:
sudo dmesg | grep -i 'driver\|module'Missing modules show up as warnings or errors. You can also use the systemctl guide to check service status, but dmesg shows the kernel-level driver initialization that happens first.
Advanced dmesg Options
Once you’ve mastered the basics, these options add more power to your troubleshooting.
Clearing the Ring Buffer
Start fresh by clearing all messages (requires root):
sudo dmesg -CThis is useful when you want to isolate new messages from system noise. Clear the buffer, perform the action you’re testing, then check dmesg for just the relevant output.
Saving Logs to File
Preserve kernel messages before a reboot:
sudo dmesg -T > kernel_messages.txtCritical for reporting issues to the Linux kernel documentation maintainers or getting help in forums. Include this output when asking for support.
Colorized Output
Make severity levels visually distinct:
sudo dmesg -LErrors pop out in different colors, making scanning long outputs much faster. Combine with human-readable format:
sudo dmesg -HThe -H flag enables both colors and automatic paging.
Decoding Facility and Priority
Get verbose output with facility and level prefixes:
sudo dmesg -x -TThis shows exactly which kernel subsystem generated each message.
Common Mistakes and Best Practices
After years of using dmesg, here’s what I wish I’d known from the start:
- Always run with sudo: Partial output leads to missed errors
- Don’t ignore timestamp context: Events 2 seconds after boot are different from events 2 days after boot
- Use grep to filter: Reading 3000 raw lines is painful and ineffective
- Check dmesg regularly: Don’t wait for problems – periodic checks catch issues early
- Save before rebooting: The ring buffer clears on restart – preserve critical errors first
“You should get into the habit of running dmesg on a regular basis on your systems. And, when something goes wrong, run it again to find out what the kernel knows about the problem.”
— Red Hat sysadmin guide
The lsof command pairs well with dmesg when tracking down resource issues – one shows kernel events, the other shows what processes have files open.
Wrapping Up
The dmesg command is one of those fundamental tools that separates effective Linux administrators from those who struggle with hardware issues. It gives you direct access to what the kernel knows – and the kernel knows everything about your hardware.
Start with the basics: sudo dmesg -T | less for browsing, sudo dmesg -l err for problems, and sudo dmesg -w for real-time monitoring. These three commands handle most situations.
Want to expand your Linux troubleshooting toolkit? Learn about journalctl for system logs, master grep for filtering output, or dive into systemctl for service management. Together, these tools give you complete visibility into what’s happening on your Linux systems.
