Kernel Logging

The kernel emits messages about boot, drivers, devices, filesystems, networking, memory, and failures. These records can explain low-level symptoms, but a warning string alone does not prove that hardware is defective.

Reading the Kernel Ring Buffer

dmesg reads messages from the kernel ring buffer:

$ dmesg --human

The buffer has finite capacity, so newer messages can overwrite older ones. Access may also be restricted to privileged users. dmesg --follow follows new kernel messages on implementations that support it; stop after a bounded reproduction.

CheckWhy might an older kernel event be absent from current dmesg output?

Kernel events can only contain one character. dmesg permanently deletes every line after displaying it. The finite ring buffer may have overwritten it.

Using Readable Timestamps

Raw kernel timestamps are commonly relative to boot. dmesg --ctime or --human can render wall-clock times, but converted values depend on clock history and can be inaccurate if the clock changed after boot. Preserve boot-relative timing when precise sequencing matters.

CheckWhy should converted dmesg wall-clock timestamps be treated carefully?

They always refer to a different machine. They depend on mapping boot-relative time to a clock that may change. They show filesystem free space instead of time.

Querying Persistent Kernel Records

On a systemd host, query kernel records from the current boot with:

$ journalctl -k -b

If persistent journal storage retained earlier boots, inspect the boot list and select one:

$ journalctl --list-boots
$ journalctl -k -b -1

Traditional syslog routing may create /var/log/kern.log or another file, but this is configuration-dependent. A saved /var/log/dmesg file is also not universal and may represent only a boot-time snapshot.

CheckWhich command requests kernel messages from the previous retained boot?

journalctl -u kernel -f dmesg --clear journalctl -k -b -1

Investigating a Kernel Event

Identify the boot, timestamp, device, subsystem, and the action occurring at that moment. Query surrounding kernel and service records, then compare hardware inventory and current state:

$ journalctl -k -b --since '10 minutes ago'
$ lspci -k
$ lsblk

Use only tools relevant to the subsystem. Before reloading a driver, unbinding a device, or rebooting, assess storage, network, console, and service impact and preserve recovery access.

CheckWhat is the best response to one kernel warning line?

Immediately unload every loaded driver. Assume the entire machine must be replaced. Correlate it with surrounding events and current subsystem state.

Summary

You can now distinguish live kernel-buffer messages from retained kernel logs.

1. Read the finite ring buffer with dmesg.
2. Interpret boot-relative and converted timestamps carefully.
3. Query current or previous boots with journalctl -k.
4. Correlate kernel messages before making disruptive changes.