Linux online course

Linux dmesg Command: View and Analyze Kernel Ring Buffer Messages

Learn how to use dmesg to inspect Linux kernel messages, troubleshoot hardware and drivers, analyze boot activity, and compare ring-buffer output with journalctl.

dmesg is a command-line utility for reading messages produced by the Linux kernel. It is especially useful when investigating boot activity, hardware detection, device drivers, storage errors, filesystem events, and other low-level problems.

This lesson covers the kernel ring buffer, basic dmesg usage, timestamps and severity levels, filtering, live monitoring, permissions, boot history, and a practical troubleshooting workflow.

What dmesg Reads: The Kernel Ring Buffer

The kernel ring buffer is a finite, in-memory circular buffer used by the Linux kernel to record important events. New records are added as the kernel operates. When the buffer becomes full, older records can be overwritten by newer ones.

The dmesg command reads and displays the current contents of this buffer. It focuses on kernel-level output rather than general application logs. For example, dmesg can show that a USB device was detected or that a storage controller reported a timeout, but it normally does not show ordinary messages written by a web server or text editor.

Why Kernel Messages Matter

Linux depends on the kernel to initialize hardware, load or activate drivers, expose devices, mount filesystems, manage memory, and communicate with hardware controllers. Kernel messages provide evidence of what happened during these operations.

• Startup activity: kernel initialization, CPU discovery, memory setup, and hardware enumeration.
• Devices: USB devices, disks, network adapters, graphics hardware, and virtual devices.
• Drivers: driver loading, initialization failures, firmware problems, and device resets.
• Filesystems: mount attempts, filesystem warnings, journal recovery, and corruption reports.
• Memory conditions: out-of-memory events, allocation failures, and memory-management warnings.
• Hardware failures: I/O errors, link resets, timeouts, controller failures, and repeated disconnects.

Early boot messages may scroll past too quickly to read on the console. After logging in, dmesg lets you review much of that activity instead of relying on what was visible during startup.

How dmesg Relates to the Boot Process

During boot, the kernel initializes itself, discovers hardware, initializes drivers, and prepares devices for use. It also participates in mounting filesystems and starting the early userspace environment. Messages from these stages commonly appear in the kernel ring buffer.

Boot loader messages and service-manager messages are related diagnostic sources, but they are not identical to kernel ring-buffer output. A boot loader can report its own actions, while a service manager can report whether services started successfully. dmesg primarily shows messages emitted by the kernel and, in some cases, kernel-integrated components.

Basic dmesg Usage

Display the current buffer

dmesg

This prints all currently available kernel messages. The output may include events from the entire current uptime and may be too long to read comfortably in a terminal.

Read output with a pager

dmesg | less

less displays one screen at a time. Use the arrow keys or Page Up and Page Down to move, / to search, and q to quit.

Save a snapshot

dmesg > ~/dmesg.txt

This uses standard output redirection: the shell writes the command's output to a file instead of displaying it. Save a snapshot before rebooting or changing hardware when you need to preserve evidence.

Displaying the full buffer and filtering it are different actions. The full command shows all available records. A filter, such as grep or a severity option, only narrows what is displayed; it does not remove matching or nonmatching records from the kernel buffer.

Reading dmesg Output

A dmesg line commonly contains a timestamp followed by message metadata and text. The exact appearance depends on the kernel, dmesg implementation, and selected options.

• Timestamp: usually the time elapsed since boot, often shown in seconds inside brackets.
• Facility: a category or subsystem associated with the record, such as the kernel or a device-related component.
• Priority or log level: the severity assigned to the message.
• Message text: details about initialization, detection, a warning, or a failure.

Kernel timestamps are generally relative to boot. They are useful for establishing event order, but they are not necessarily wall-clock times. The -T option requests human-readable time information; conversion can be approximate on some systems, particularly when the system clock was adjusted.

Kernel log severity levels

A warning or error is not automatically proof of the cause of a failure. Some messages are expected during normal operation, so interpret severity together with the device, timing, and surrounding messages.

Frequently Used dmesg Options

Other display controls can remove details that are not useful for a particular review. For example, -t omits timestamps and -P omits message prefixes on implementations that support those options. Use dmesg --help to confirm options provided by your installed version.

Filtering and Searching Messages

Searching is often more useful than reading thousands of lines. The pipe operator sends dmesg output to another command, while grep selects lines containing a pattern.

Search without regard to capitalization

dmesg | grep -i usb

The -i option performs a case-insensitive search, so it matches USB, Usb, and usb.

Search for several failure terms

dmesg | grep -iE 'error|fail|warn'

The extended pattern matches any of the listed terms. Such a search is a starting point, not a complete diagnosis: a message may contain none of these words even when a problem exists.

Search by hardware or subsystem

dmesg | grep -iE 'usb|eth|wlan|nvme|sd[a-z]|ext4|timeout|reset'

• Use a device name, such as nvme or sda, for storage investigations.
• Use usb and the device identifier for USB problems.
• Use an interface or driver name for network and graphics issues.
• Use terms such as timeout, reset, disconnect, or firmware when looking for initialization failures.

Filtering does not alter the ring buffer. It only narrows the text sent to the terminal or to the next command in the pipeline.

Live Monitoring with Follow Mode

sudo dmesg -w

Follow mode waits for newly emitted kernel messages and prints them as they arrive. Stop it with Ctrl+C.

Use follow mode immediately before an action that should generate kernel activity:

1. Start sudo dmesg -w.
2. Connect a USB device, load hardware, bring up a network adapter, or reproduce the driver problem.
3. Read the new lines that appear after the action.
4. Look for detection, driver, firmware, reset, disconnect, or error messages.

On a system using systemd, a comparable live view is:

journalctl -k -f

dmesg -w follows the kernel ring buffer directly. journalctl -k -f follows kernel-originated records in the systemd journal, which may provide more persistent context when journal storage is enabled.

Boot Logs and Persistent Storage

The current ring buffer does not necessarily preserve previous boot messages. It can be reset during reboot, and older records can be overwritten while the system remains running.

Linux logging services may copy kernel messages into persistent storage. The exact files and configuration are distribution-dependent.

Inspect the current and previous boot with journalctl

journalctl -k -b

This limits the systemd journal to kernel records from the current boot.

journalctl -k -b -1

This requests kernel records from the previous boot, if they were retained. It is often more useful than dmesg after a reboot caused by a crash or failed startup.

less /var/log/dmesg

Some distributions create /var/log/dmesg. Do not assume that this file exists or contains the same information on every Linux installation.

Permissions and Security Restrictions

Kernel messages can reveal hardware details, memory addresses, device identifiers, and information about system behavior. Hardened systems may prevent ordinary users from reading them.

The kernel.dmesg_restrict sysctl controls whether non-root users may access dmesg output. Check its value with:

cat /proc/sys/kernel/dmesg_restrict

A restricted read commonly produces an error such as “Operation not permitted.” If administrative access is appropriate, try:

sudo dmesg

You can also try journalctl -k with suitable privileges on a systemd system. In a container or restricted environment, host security policy may block access even when the command is run inside the container.

It is possible for an administrator to temporarily lower the restriction:

sudo sysctl kernel.dmesg_restrict=0

A Practical Troubleshooting Workflow

1. Collect relevant evidence. Start with dmesg -T, dmesg --level=err,warn, or a saved snapshot.
2. Identify the scope. Decide whether the problem involves a device, driver, filesystem, network interface, memory, or boot stage.
3. Filter carefully. Search by device name, driver name, subsystem, severity, and terms such as error, failed, timeout, or reset.
4. Compare timing. Check messages before and after reproducing the problem. A newly emitted error is more relevant than an unrelated old warning.
5. Check surrounding lines. The first failure may be followed by several secondary errors. Read enough context to find the earliest meaningful event.
6. Use related tools and logs. dmesg alone may not identify the cause. Depending on the issue, also inspect journalctl, lsusb, lspci, lsblk, driver information, SMART data, or filesystem-specific tools.
7. Preserve evidence before rebooting. Save dmesg output or verify that persistent journal storage is available.

Example: A USB Device Is Not Recognized

First start a live view:

sudo dmesg -w

Reconnect the device and look for messages containing USB, a device identifier, a driver name, reset attempts, disconnects, or errors. You can then compare the result with:

lsusb

If the device appears in dmesg but fails during setup, the kernel detected something but may have encountered a power, cable, firmware, or driver problem. If there is no new message at all, investigate the port, cable, power, hardware, and the environment in which the command is running.

Example: Disk or Filesystem I/O Errors

Search for the disk name and common storage failure terms:

dmesg | grep -iE 'I/O|timeout|reset|nvme|sd[a-z]|ext4'

Repeated I/O errors, controller resets, or timeouts can indicate a degrading storage device, a faulty connection, a controller problem, or a filesystem issue. Protect important data first. Then use appropriate tools such as SMART diagnostics and filesystem-specific repair or inspection tools.

Example: A Boot Warning Scrolled Past

After login, review the current kernel messages in a readable format:

dmesg -T | less

On a systemd distribution, compare that output with:

journalctl -k -b

If the problem occurred during the previous boot, try:

journalctl -k -b -1

If the previous boot is missing from both views, the ring buffer may have been reset and persistent journal storage may not be enabled. In future investigations, save a snapshot before rebooting or configure appropriate log retention.

Common Problems and Their Solutions

“Reading the kernel buffer is not permitted”

• Try sudo dmesg if you have a valid administrative reason and permission.
• Check cat /proc/sys/kernel/dmesg_restrict.
• Use journalctl -k with appropriate privileges.
• Consider whether a container, sandbox, or host security policy blocks kernel access.

Expected messages from the previous boot are absent

• The in-memory ring buffer was reset during reboot.
• Older entries were overwritten because the buffer filled.
• Persistent journal storage or syslog collection is not configured.
• Try journalctl -k -b -1 if the system retains prior boots.

The output contains many warnings

Do not assume every warning is the root cause. Filter by the affected device and compare timestamps. Look for the earliest event that coincides with the problem, then check related logs and hardware-specific tools.

Quick Reference

dmesg                         # Print the current kernel ring buffer
dmesg | less                  # Browse long output
dmesg -T | less               # Browse with human-readable times
dmesg --level=err,warn        # Show errors and warnings
dmesg -x                     # Decode facility and priority
dmesg | grep -i usb          # Search for USB messages
dmesg | grep -iE 'error|fail|warn'  # Search common failure terms
sudo dmesg -w                 # Follow new kernel messages
dmesg > ~/dmesg.txt           # Save a snapshot
journalctl -k -b             # Current-boot kernel records
journalctl -k -b -1          # Previous-boot kernel records

Key Exam and Troubleshooting Notes

• dmesg reads the kernel ring buffer, which is finite, in memory, and circular.
• Kernel timestamps are usually relative to boot; -T requests human-readable times.
• Severity is not the same as root cause. Interpret warnings and errors with context.
• Filtering changes only the display, not the contents of the kernel buffer.
• -w follows new messages and is useful while reproducing hardware or driver events.
• Previous boots require persistent logs, such as a retained systemd journal or distribution-specific log files.
• Access may be restricted by kernel.dmesg_restrict or by an execution environment's security policy.
• Boot loader and service-manager logs complement dmesg but are not identical to kernel messages.

For broader command-line practice, review Linux command-line topics, then strengthen your shell skills with Bourne Again Shell Bash. Understanding pipes, redirection, permissions, and command output makes dmesg much easier to use effectively.