VMware ESXi and vSphere Cluster Management

dmesg Command in Linux: View and Filter Kernel Ring Buffer Messages

Learn how to use dmesg in Linux to inspect boot messages, hardware and driver events, filter kernel errors, follow new messages, and troubleshoot restricted or missing logs.

dmesg is a Linux command that displays messages from the kernel ring buffer. It is one of the quickest ways to investigate boot-time hardware detection, driver activity, device failures, and other kernel events.

This guide covers basic viewing, paging, saving, searching, timestamp formats, severity filtering, live monitoring, permissions, persistent alternatives, and safe interpretation of kernel messages.

What dmesg Shows

The kernel is the core part of Linux that manages hardware, memory, processes, and communication between software and devices. It can produce kernel messages containing diagnostic or status information from the kernel itself, drivers, and kernel subsystems.

dmesg reads these messages from the kernel ring buffer. A ring buffer is a bounded, in-memory log maintained by the kernel. It has a finite size: when it fills, newer messages can overwrite older ones.

This makes dmesg different from an application log. A web server, database, or desktop application writes its own log output. dmesg primarily shows events produced by the kernel and kernel-level components.

Why Kernel Messages Matter During Boot

During startup, the kernel emits messages as it initializes itself and discovers available hardware. This output may scroll past too quickly to inspect interactively, especially on systems with many devices or drivers.

After the system has started, dmesg lets you review that output. Common entries describe:

  • Kernel initialization
  • CPU and memory detection
  • Storage controllers and disks
  • USB device connection and enumeration
  • Network adapters and link changes
  • Filesystems being mounted or initialized
  • Kernel modules being loaded
  • Driver initialization, failures, and firmware loading

dmesg is especially useful immediately after startup, after changing hardware, when loading a kernel module, when a device fails, and while reproducing a kernel or driver event.

Basic dmesg Usage

dmesg

With no options, dmesg prints all currently accessible messages in the ring buffer. The output can be extensive, so use a pager or filter when investigating a particular event.

Depending on the command version and output format, lines may include a priority marker and a timestamp. A timestamp commonly represents elapsed time since boot rather than a calendar date. The message text normally identifies the subsystem, device, driver, or event.

Reading Long Output

Use less for page-by-page reading

dmesg | less

The vertical bar is a pipe. It passes dmesg's standard output to less, a pager that displays long output one screen at a time.

  • Use the arrow keys, Page Up, and Page Down to move.
  • Type /usb or another term to search forward.
  • Press n to move to the next search match.
  • Press q to quit less.

Save output to a file

dmesg > dmesg-output.txt

The > operator is output redirection. It writes standard output to the specified file, creating the file or replacing its previous contents.

dmesg >> dmesg-history.txt

The >> operator appends output to the end of a file instead of replacing it. Appending can be useful when collecting multiple captures, but include timing or event notes so the captures can be distinguished.

Search with grep

dmesg | grep -i 'usb\|nvme\|firmware\|error'

grep -i performs a case-insensitive text search. This example looks for several terms. You can also search for a device name, driver name, filesystem, or subsystem such as eth, wlan, or ext4.

A keyword match is only a starting point. A line containing “error” or “warning” does not, by itself, prove that the line identifies the root cause. Read nearby messages and correlate them with the actual symptom.

Timestamps and Readable Output

Kernel timestamps are commonly measured from system boot. For example, a value near 12 seconds usually means the message was emitted about 12 seconds after the kernel started, not at 12:00 on a clock.

dmesg -T

The -T option requests human-readable, calendar-style timestamps when supported. These are easier to compare with a user's report or another system log, but they are derived from system timing and may not be exact in every situation.

dmesg --time-format=iso

This requests ISO-like timestamps when supported and can make incident notes or log correlation easier. Timestamp options, formats, and availability vary with the dmesg version, util-linux version, and system configuration.

dmesg --human

--human requests a more human-oriented display on versions that provide this option. Color behavior can also vary:

dmesg --color=always
dmesg --color=never

Use color options only when supported by the installed version. Avoid forcing color when saving output intended for another tool or a report.

Common dmesg Options

OptionPurposeExample use
No optionDisplay currently accessible ring-buffer messages.dmesg
-TRequest readable calendar-style timestamps.dmesg -T
--time-format=isoRequest ISO-like timestamps where supported.dmesg --time-format=iso
--level=errShow messages at the error level.dmesg --level=err
--followWait for and display newly generated messages.sudo dmesg --follow
--humanRequest human-oriented formatting where supported.dmesg --human
--color=always or --color=neverControl color output where supported.dmesg --color=never

Filter Messages by Severity

Kernel messages can have a kernel log level, which is a severity classification. Filtering by level is different from searching for a word such as “error”: it uses the message's assigned priority.

dmesg --level=err
dmesg --level=err,warn
LevelMeaningTypical interpretation
emergEmergencyThe system is unusable or facing an extreme failure.
alertAlertImmediate action may be required.
critCriticalA serious condition affecting an important component.
errErrorAn operation or component reported a failure.
warnWarningA potentially problematic condition was detected.
noticeNoticeA significant but generally non-error event.
infoInformationalNormal status or diagnostic information.
debugDebugDetailed information intended for investigation.

You can combine severity filtering with a pager or keyword search:

dmesg --level=err,warn | less
dmesg --level=err,warn | grep -i 'usb\|nvme\|firmware'

Follow New Kernel Messages

Follow mode continuously waits for new messages and prints them as they arrive:

sudo dmesg --follow

This is useful when you want to observe a specific action, such as:

  • Plugging in a USB device
  • Loading a kernel module
  • Reconnecting a disk
  • Reproducing a driver problem
  • Observing network link changes

Start the command first, perform the action, and then examine the new lines. Stop a foreground follow command safely with Ctrl+C.

Permissions and Restricted Kernel Logs

Some Linux systems restrict unprivileged access to the kernel ring buffer. A normal user may see an error such as “permission denied” or “operation not permitted.”

sudo dmesg

Use sudo only when you are authorized to obtain these diagnostics. A common reason for restricted access is the kernel setting named dmesg_restrict:

sysctl kernel.dmesg_restrict

A value of 1 commonly indicates that non-root access is restricted, although the exact access result also depends on system permissions and security policy. If sudo is unavailable, try a permitted journal view instead.

Persistent and Alternative Kernel Logs

The ring buffer is memory-resident. It can be reset by rebooting, and older entries can be overwritten when the buffer fills. If you need messages from before a reboot, inspect a persistent log source.

journalctl -k -b

journalctl -k displays kernel messages stored in the systemd journal. The -b option selects the current boot. Journal permissions, retention, and storage configuration determine what is available.

less /var/log/dmesg

Some distributions provide a saved boot log at /var/log/dmesg, but this file may not exist, may have a different name, or may not represent the current boot. File names, retention, and persistence differ across distributions.

SourceBest usePersistenceNotes
dmesgQuickly inspect the current kernel ring buffer.Usually temporary and memory-resident.May require elevated access and may lose old entries.
journalctl -kReview kernel messages through systemd's journal.Can persist across boots if journal storage is configured.Use -b to select a boot; availability depends on systemd journal configuration.
/var/log/dmesgRead a distribution-provided saved boot log.Depends on log-management configuration.It may not exist or may not contain the current boot.

Safe Troubleshooting with dmesg

Do not treat every startup message as a failure. Many systems report informational events, optional hardware that is absent, or warnings that are handled by a fallback. Begin with the incident and collect output around the relevant time.

  1. Record what happened, when it happened, and what hardware or software action triggered it.
  2. Capture the current output before rebooting if the problem is transient.
  3. Use less, severity filters, and subsystem keywords to narrow the search.
  4. Read surrounding lines instead of copying only one matching line.
  5. Check whether the message repeats and whether it matches an observable malfunction.
  6. Compare the message with journal entries and any recent hardware, driver, firmware, or configuration changes.

Repeated errors, input/output failures, driver failures, firmware-load failures, kernel warnings, and hardware disconnect/reconnect events are common signals worth investigating. They still require context before assigning a root cause.

Practical Troubleshooting Examples

“Reading the kernel buffer is not permitted”

  • Check whether elevated access is allowed in the environment.
  • Run sudo dmesg if you are authorized.
  • Inspect sysctl kernel.dmesg_restrict when administrative access is available.
  • Try journalctl -k if journal permissions and retained logs allow access.

There is too much output

  • Use dmesg | less for navigation and interactive searches.
  • Filter with dmesg --level=err,warn.
  • Search for a device, subsystem, driver, or terms such as error, fail, and firmware.
  • Use follow mode while reproducing the event to capture only newly generated messages.

A USB, disk, or network device is not recognized

sudo dmesg --follow

Start follow mode, then reconnect or enable the device. Look for connection, enumeration, driver-binding, firmware, timeout, and I/O messages. Record the relevant lines together with the device model and the exact action that triggered them. These messages can indicate connection, power, driver, firmware, or hardware problems, but further testing is usually required.

Expected messages are missing after reboot

  • The ring buffer may have been reset or its entries may have been overwritten.
  • Check journalctl -k -b for retained records from the current boot.
  • Check whether /var/log/dmesg exists on the distribution.
  • Capture dmesg output before rebooting when investigating a transient problem.

A warning or error appears, but the system works

Check the assigned severity and surrounding messages. Determine whether the line repeats, whether it corresponds to an actual symptom, and whether the system recovered through a fallback. An isolated nonfatal warning is different from a repeated error associated with a device failure.

Quick Reference

dmesg
sudo dmesg
dmesg | less
dmesg > dmesg-output.txt
dmesg >> dmesg-history.txt
dmesg -T
dmesg --time-format=iso
dmesg --level=err,warn
dmesg | grep -i 'error\|fail\|warning'
sudo dmesg --follow
journalctl -k -b
sysctl kernel.dmesg_restrict

For related material, continue with the Linux dmesg command reference and connect the results with your system's journal, module, and hardware-detection tools.