When something goes wrong below the level of userspace, the kernel writes about it. A disk reporting read errors, a USB device failing to enumerate, a network interface resetting, a process killed for exhausting memory: all of it lands in the kernel ring buffer, and none of it appears in your application logs.

Reading it

sudo dmesg
sudo dmesg -T            # human-readable timestamps
sudo dmesg -T | less
sudo dmesg -w            # follow new messages live

Default timestamps are seconds since boot, which is precise and unhelpful when you are trying to correlate with something that happened at 14:32. -T converts them.

-w is the one to remember. Run it in one terminal, plug in the device or trigger the fault, and watch what the kernel says about it as it happens.

Filtering

sudo dmesg --level=err,crit,alert,emerg     # problems only
sudo dmesg --level=warn,err                 # and warnings
sudo dmesg -f kern,daemon                   # by facility
sudo dmesg | grep -i usb
sudo dmesg | grep -iE "error|fail|warn"

The priority levels follow syslog: emerg, alert, crit, err, warning, notice, info, debug. Most of what fills the buffer is info, so filtering to err immediately makes a long buffer readable.

The messages worth recognising

Disk problems. These are the ones to act on immediately.

ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
blk_update_request: I/O error, dev sda, sector 234567

A drive reporting I/O errors is failing or has a cable problem. Check it properly with SMART before deciding which. Our smartctl guide covers reading the attributes that actually predict failure.

The OOM killer.

Out of memory: Killed process 4242 (mysqld) total-vm:8388608kB

The system ran out of memory and the kernel picked a process to kill so the machine would survive. The victim is usually the largest consumer, not the culprit. Investigate what grew, and consider whether the machine needs more RAM, more swap, or a memory limit on the offending service.

USB enumeration.

usb 1-2: new high-speed USB device number 5 using xhci_hcd
usb 1-2: device descriptor read/64, error -71

The first line is normal. The second means the device failed to negotiate, which is typically a cable, a port, or insufficient power from an unpowered hub.

Segfaults.

myapp[1234]: segfault at 0 ip 00007f... sp 00007f... error 4 in libc.so.6

A process crashed dereferencing bad memory. The library named is where it happened, which is not necessarily where the bug is.

Filesystem trouble.

EXT4-fs error (device sda1): ext4_find_entry:1455: inode #2: comm ls: reading directory lblock 0

Filesystem corruption. Unmount and fsck when you can, and treat the underlying disk as suspect.

Hardware discovery at boot

The early part of the buffer is the kernel enumerating hardware, which is useful when something is not detected:

sudo dmesg | grep -i "cpu\|memory\|nvme\|firmware"
sudo dmesg | grep -i "microcode"

Missing firmware shows up plainly:

i915 0000:00:02.0: Direct firmware load for i915/skl_dmc_ver1_27.bin failed

That means installing the linux-firmware package or its vendor equivalent, and it is a common reason graphics or wireless does not work on a fresh install.

Why it might be empty or truncated

The ring buffer is a fixed size and old messages are discarded once it fills. On a busy system that can take hours.

# How big is it?
cat /proc/sys/kernel/printk_ringbuffer_log_buf_shift 2>/dev/null

The durable answer is the journal, which keeps the same messages across reboots:

journalctl -k                      # kernel messages, this boot
journalctl -k -b -1                # previous boot
journalctl -k -p err --since today

journalctl -k -b -1 is how you investigate a crash after the fact, and it is the single most useful command here. Our journalctl guide covers the rest, and the journalctl query builder generates the filters.

Permission

sysctl kernel.dmesg_restrict

If this is 1, unprivileged users cannot read the buffer, because kernel messages can leak memory addresses useful for exploitation. Use sudo, or read through the journal if your user is in the systemd-journal group.

Clearing it

sudo dmesg -C     # clear
sudo dmesg -c     # print then clear

Occasionally useful to get a clean buffer before reproducing a problem. It does not affect the journal, so nothing is permanently lost.

Frequently Asked Questions

What is the kernel ring buffer?

A fixed-size in-memory log the kernel writes to. Because it is a ring, old messages are overwritten once it fills, so a long-running system may have lost the message you are looking for. journalctl -k keeps the same messages persistently.

Why does dmesg need root on my system?

Many distributions set kernel.dmesg_restrict to 1, because kernel messages can leak addresses and other details useful to an attacker. Use sudo, or read the same content with journalctl -k if your user has journal access.

How do I see only errors?

dmesg --level=err,crit,alert,emerg filters by priority. Adding -T converts timestamps to readable dates and -w follows new messages live, which is how you watch what happens when you plug something in.

What does the OOM killer message mean?

The system ran out of memory and the kernel chose a process to terminate to recover. The message names the victim and its score. It means you need more RAM, more swap, or lower memory usage, not that the killed process was faulty.

Why are dmesg timestamps wrong?

By default they are seconds since boot, not wall clock time. Use -T to have dmesg convert them. The conversion can drift slightly on systems that have suspended, since the counter and the clock diverge.

Should I use dmesg or journalctl?

journalctl -k for anything historical, because the journal persists across reboots and the ring buffer does not. dmesg -w is still the nicer way to watch messages appear in real time while you plug a device in or trigger a fault.