12 Ways to Use the dmesg Command in Linux to View and Troubleshoot Kernel Messages

The dmesg command reads the kernel ring buffer; a circular log where the Linux kernel records messages from the time the system boots. When the kernel detects hardware, loads a driver, recognizes a USB device, or encounters a disk or hardware-related error, those messages are typically written to this buffer.

That makes dmesg especially useful when you’re troubleshooting problems related to hardware, drivers, storage devices, USB devices, networking, or the boot process. When something goes wrong at the hardware or driver level, dmesg is often one of the first places you should check.

The ring buffer has a fixed size, so it can only store a limited amount of information. On many systems, it holds roughly 512 KB to 1 MB of messages, although the actual size depends on the system configuration.

As new messages are added, older ones are overwritten. On a busy system, this means some boot-time messages may no longer be available after a few hours.

In this lesson, we’ll look at practical ways to use dmesg so you can find useful information quickly instead of scrolling through a wall of kernel messages.

All examples below are tested on Ubuntu 26.04 and RHEL 9 / Rocky Linux 9, with any differences between them noted where necessary.

Prerequisites: You should be comfortable with basic terminal commands. Most dmesg commands work without special permissions on Ubuntu 26.04. On RHEL 9, you generally need sudo to read the full kernel log; we’ll point this out in the relevant examples.

1. View All Kernel Messages

Running dmesg without any options displays the entire kernel ring buffer. On most systems, that means a lot of output usually much more than can fit on your screen. Instead of letting it scroll past, pipe the output through less or more so you can read it one page at a time:

dmesg | less
dmesg | more

When you view the output, you’ll notice that each line starts with a timestamp such as [4.832145]. This is the number of seconds since the system booted when the kernel recorded that message.

These timestamps are useful when troubleshooting because they let you see when a particular event happened relative to system startup. You can then compare that timing with application or system logs to find out what happened around the same time.

On RHEL 9 / Rocky Linux 9, you may need sudo to read the full kernel buffer:

sudo dmesg | less

2. Print Human-Readable Timestamps

By default, dmesg shows timestamps as seconds since boot. While this is useful for understanding the order of events, it isn’t very convenient when you want to match a kernel message with a specific time.

Use the -T option to display timestamps as human-readable local date and time:

dmesg -T | less

You’ll see output similar to:

[Thu Aug 27 10:48:21 2026] Linux version 6.8.0-137-generic …
[Thu Aug 27 10:48:21 2026] Linux version 6.8.0-137-generic …
[Thu Aug 27 10:48:21 2026] Linux version 6.8.0-137-generic

This is much easier to work with when troubleshooting a problem that happened at a known time. For example, if a disk error was reported around 09:45, you can use the timestamp to narrow down the relevant kernel messages and investigate what happened around that time.

Keep in mind that dmesg -T converts the kernel’s relative timestamps into human-readable times; it doesn’t change the underlying log data.

3. Filter Output by Log Level

The kernel assigns a log level to each message based on how important it is. dmesg supports eight levels, ranging from emerg (level 0), which indicates an emergency, to debug (level 7), which contains debugging information.

You can use the -l option to display messages from a specific log level. You can also provide multiple levels separated by commas:

dmesg -l err
dmesg -l warn
dmesg -l err,warn

For example, to see both errors and warnings with human-readable timestamps, run:

dmesg -T -l err,warn

This is one of the quickest ways to check whether the kernel has reported potential hardware, driver, or other system-level problems without having to go through thousands of informational messages.

If the command produces no output, that simply means there are no messages matching the selected log levels in the current kernel ring buffer.

4. Filter by Facility

In addition to log levels, dmesg can filter messages by their facility, which indicates where a message originated. Common facilities include kern, daemon, and user.

Use the -f option to filter messages by facility:

dmesg -f kern
dmesg -f daemon

You can also combine a facility filter with a log level to narrow the output even further:

dmesg -T -f kern -l err

This shows only kernel errors with human-readable timestamps, giving you a much cleaner starting point when troubleshooting problems such as a driver crash or hardware failure.

5. Search for a Specific Device or String

When you’re looking for messages related to a particular device or component, you don’t need to read the entire dmesg output. Just pipe it through grep command and search for the term you’re interested in.

Use -i with grep to make the search case-insensitive:

# Find messages about SATA/NVMe disks
dmesg | grep -i sda
dmesg | grep -i nvme

# Find USB-related messages
dmesg | grep -i usb

# Find memory-related messages
dmesg | grep -i memory

# Find network interface messages
dmesg | grep -i eth0
dmesg | grep -i ens

On modern Linux systems, SATA drives commonly appear as sda, sdb, and so on, while NVMe drives typically appear as nvme0n1, nvme1n1, and so on.

For example, if your system uses an NVMe drive, you can search for all messages containing nvme:

dmesg | grep -i nvme

You might see output similar to:

[    1.054638] nvme 0000:02:00.0: platform quirk: setting simple suspend
[    1.054759] nvme nvme0: pci function 0000:02:00.0
[    1.081443] nvme nvme0: allocated 64 MiB host memory buffer.
[    1.103926] nvme nvme0: 8/0/0 default/read/poll queues
[    1.107981]  nvme0n1: p1
[    2.154888] EXT4-fs (nvme0n1p1): mounted filesystem 57cd5bee-10f3-49d8-b752-09c160a0d824 ro with ordered data mode. Quota mode: none.
[    2.731648] EXT4-fs (nvme0n1p1): re-mounted 57cd5bee-10f3-49d8-b752-09c160a0d824 r/w.
[    5.511438] block nvme0n1: No UUID available providing old NGUID

This gives you a quick way to see when the kernel detected the drive, initialized its controller, and recognized its partitions.

The same approach works for almost any device or subsystem. If you’re troubleshooting a USB device, network interface, memory issue, or storage problem, search dmesg for the relevant keyword first.

6. View Only the First N Lines

If you only need to see the beginning of the kernel log, pipe dmesg through head. This is useful for checking early boot messages, such as the kernel version, CPU detection, and system memory information.

For example, to display the first 20 lines:

dmesg | head -20

You might see output similar to:

[ 0.000000] Linux version 6.8.0-137-generic (buildd@lcy02-amd64-064) ...
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-6.8.0-137-generic...
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009efff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000009f000-0x00000000000fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000005f72afff] usable
[ 0.000000] BIOS-e820: [mem 0x000000005f72b000-0x0000000063510fff] reserved
...

You can change 20 to any number of lines you want. For example, head -50 displays the first 50 lines.

7. View Only the Last N Lines

To see the most recent kernel messages, use tail command instead. This is particularly useful after plugging in a USB device, connecting external storage, or triggering a hardware event that you want to investigate.

For example:

dmesg | tail -20

This displays the last 20 messages currently available in the kernel ring buffer.

For example, if you just plugged in a USB drive, the latest messages might look like this:

[45821.003212] usb 1-1: new high-speed USB device number 4 using xhci_hcd
[45821.152015] usb 1-1: New USB device found, idVendor=0781, idProduct=5583
[45821.152021] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[45821.152023] usb 1-1: Product: Ultra Fit
[45821.152025] usb 1-1: Manufacturer: SanDisk
[45821.167883] usb-storage 1-1:1.0: USB Mass Storage device detected
[45821.168211] scsi host6: usb-storage 1-1:1.0
[45822.184335] scsi 6:0:0:0: Direct-Access     SanDisk  Ultra Fit        1.00
[45822.185014] sd 6:0:0:0: [sdb] 120127488 512-byte logical blocks: (61.5 GB/57.2 GiB)
[45822.185987] sd 6:0:0:0: [sdb] Write Protect is off

These messages show the kernel detecting the USB device, identifying its manufacturer and model, loading the USB storage driver, and finally recognizing it as the sdb block device.

For quick hardware troubleshooting, dmesg | tail -20 is often much more useful than dumping the entire ring buffer.

8. Follow dmesg Output in Real Time

Sometimes you don’t want to look at messages that have already been logged, you want to see what the kernel reports as it happens. That’s where dmesg -w comes in.

Available since Linux kernel 3.5.0, this option keeps dmesg running and displays new kernel messages as they are added to the ring buffer. It works much like tail -f when following a regular log file.

dmesg -w

This is especially useful when you’re plugging in a USB device, loading a kernel module, connecting hardware, or reproducing a driver problem. Start the command first, perform the action, and watch the kernel messages appear in real time.

Press Ctrl+C when you’re done.

On older systems where dmesg -w isn’t available, you can use watch as a simple alternative:

watch "dmesg | tail -20"

This repeatedly runs the command and refreshes the last 20 lines of the kernel buffer.

9. Display Messages with Color

When dmesg produces a lot of output, color coding can make important messages easier to spot. The --color option lets you control whether dmesg uses colors for different log levels.

To force color output while piping it through less, use:

dmesg --color=always | less -R

Here’s what the options do:

• --color=always forces dmesg to use colors even when its output is being piped to another command.
• -R tells less to display the color escape sequences correctly.

Depending on the terminal and dmesg version, different log levels may be displayed in different colors, making warnings and errors easier to pick out from routine messages.

This can be particularly helpful when you’re scanning a long dmesg output and want to quickly identify messages that need attention.

10. Show Only Messages Since Last Boot

dmesg reads the current kernel ring buffer, but it doesn’t provide a convenient way to select messages from a specific boot. On systems using systemd, journalctl command is a better choice when you need kernel messages from the current or an earlier boot.

To view kernel messages from the current boot:

journalctl -k

To view kernel messages from the previous boot:

journalctl -k -b -1

And to view messages from two boots ago:

journalctl -k -b -2

This becomes especially useful after a crash, kernel panic, or unexpected reboot. If the system restarted before you had a chance to inspect dmesg, the previous boot’s kernel messages may contain useful clues about what happened.

Unlike dmesg, which only shows what is still available in the kernel ring buffer, journalctl can retrieve older kernel messages when they have been retained by the system journal.

11. Clear the Ring Buffer

The -C option clears the current kernel ring buffer. Once you run it, the messages are removed from the output of dmesg.

sudo dmesg -C

This can be useful when troubleshooting a specific hardware problem. For example, if a USB device is not working, you can clear the buffer first, plug in the device, and then run dmesg to see only the messages generated by that event.

12. Save dmesg Output to a File

When you’re troubleshooting a system, filing a bug report, or sharing diagnostic information with another administrator, it can be useful to save the dmesg output to a file.

The following command saves the messages with human-readable timestamps:

dmesg -T > /tmp/dmesg-$(hostname)-$(date +%F).txt

The command creates a file with the hostname and current date in its name, such as:

dmesg-web01-2026-08-14.txt

This makes it easier to identify which server and date the log belongs to.

On RHEL 9 / Rocky Linux 9, use sudo if your system requires elevated permissions to read the kernel buffer:

sudo dmesg -T > /tmp/dmesg-$(hostname)-$(date +%F).txt

Quick Reference

Conclusion

dmesg command is much more useful than simply dumping thousands of kernel messages to the terminal. With a few simple options, you can quickly find errors, check hardware, monitor new devices, follow kernel events in real time, and investigate problems after a crash or reboot.

The most useful commands to remember are dmesg -T for readable timestamps, dmesg -l err,warn for finding problems, dmesg | grep -i for searching specific devices, and dmesg -w for watching new messages as they happen.

Once you get comfortable with these options, dmesg becomes a quick and practical troubleshooting tool for everyday Linux administration.

What’s your go-to dmesg command when troubleshooting Linux hardware or driver problems? Share your favorite command or troubleshooting tip in the comments below.