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
/usbor another term to search forward. - Press
nto move to the next search match. - Press
qto 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
| Option | Purpose | Example use |
|---|---|---|
| No option | Display currently accessible ring-buffer messages. | dmesg |
-T | Request readable calendar-style timestamps. | dmesg -T |
--time-format=iso | Request ISO-like timestamps where supported. | dmesg --time-format=iso |
--level=err | Show messages at the error level. | dmesg --level=err |
--follow | Wait for and display newly generated messages. | sudo dmesg --follow |
--human | Request human-oriented formatting where supported. | dmesg --human |
--color=always or --color=never | Control 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
| Level | Meaning | Typical interpretation |
|---|---|---|
emerg | Emergency | The system is unusable or facing an extreme failure. |
alert | Alert | Immediate action may be required. |
crit | Critical | A serious condition affecting an important component. |
err | Error | An operation or component reported a failure. |
warn | Warning | A potentially problematic condition was detected. |
notice | Notice | A significant but generally non-error event. |
info | Informational | Normal status or diagnostic information. |
debug | Debug | Detailed 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.
| Source | Best use | Persistence | Notes |
|---|---|---|---|
dmesg | Quickly inspect the current kernel ring buffer. | Usually temporary and memory-resident. | May require elevated access and may lose old entries. |
journalctl -k | Review 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/dmesg | Read 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.
- Record what happened, when it happened, and what hardware or software action triggered it.
- Capture the current output before rebooting if the problem is transient.
- Use
less, severity filters, and subsystem keywords to narrow the search. - Read surrounding lines instead of copying only one matching line.
- Check whether the message repeats and whether it matches an observable malfunction.
- 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 dmesgif you are authorized. - Inspect
sysctl kernel.dmesg_restrictwhen administrative access is available. - Try
journalctl -kif journal permissions and retained logs allow access.
There is too much output
- Use
dmesg | lessfor navigation and interactive searches. - Filter with
dmesg --level=err,warn. - Search for a device, subsystem, driver, or terms such as
error,fail, andfirmware. - 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 -bfor retained records from the current boot. - Check whether
/var/log/dmesgexists 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.