What is the Linux kernel ring buffer that the `dmesg` command prints, and why might messages from early boot be missing from it on a host that has been running for weeks?

## What it is The kernel cannot call a logging library — it runs before any user-space logger exists and must be able to log while holding locks, in interrupt context, or while a device is failing. So it writes into a **ring buffer**: a fixed-size block of kernel memory treated as a circle. The function kernel code calls is `printk`, and `dmesg` is the user-space command that reads the buffer's contents out and prints them. "Fixed size" is the whole story behind most surprises here. The size is chosen when the kernel is compiled and can be raised at boot with the `log_buf_len=` kernel command-line parameter. When the buffer is full, the next message overwrites the oldest one — there is no growth and no eviction policy to tune beyond making it bigger. ## Why boot messages disappear On a machine that has just started, the buffer holds exactly what you want: firmware handover details, CPU and memory setup, driver probes, the root filesystem mount. But every later kernel message competes for the same space. A host with a flapping link, a disk reporting errors, or a packet filter logging drops can generate thousands of lines an hour, and the buffer wraps. Weeks later, `dmesg` shows the last few minutes of kernel chatter and nothing about the boot at all. The buffer is also **per-boot**. It lives in RAM and is not written anywhere by the kernel itself, so a reboot loses everything in it. Persistence comes from a user-space logging daemon that reads the buffer and writes to disk. That means the live buffer answers "what has the kernel said recently", while the on-disk logs answer "what did the kernel say during the last boot" — and those are genuinely different questions. ## The timestamp trap The numbers in brackets at the start of each line are **seconds since the kernel started**, not a date. The kernel does not know the wall-clock time when it prints its first messages. `dmesg -T` converts them for you by adding the boot time, which is convenient and slightly unreliable: the conversion assumes a steady clock, so entries can be reported at the wrong wall-clock time on a host that suspended or had its clock stepped by time synchronisation. When correlating a kernel message with an application event, prefer the persisted logs, which carry real timestamps. ## Who can read it Many distributions ship with `kernel.dmesg_restrict` enabled, which limits reading the buffer to processes with the appropriate privilege. The symptom is a plain permission error from `dmesg` as an ordinary user, on a system where everything else works — not a broken command, a deliberate hardening setting, because kernel messages leak addresses and hardware details useful to an attacker. ## Filtering what you get Every `printk` carries a severity level, so you can ask for only the serious lines rather than reading thousands: ```bash dmesg --level=err,crit,alert,emerg # only the messages that indicate trouble dmesg -T # approximate wall-clock timestamps ``` ## Why this matters at boot time The ring buffer is the only narration you get for the stage between the kernel taking control and user space starting. If a machine is failing to boot, the messages on the console *are* this buffer being echoed as it is written. And the converse is the diagnostic rule worth remembering: if a machine shows no kernel messages at all on the console, the failure happened before the kernel was running — in firmware or the bootloader — and the ring buffer will never have anything to say about it.