The Three Places Where printk Messages Can Go

Before diving into how to control log levels, it helps to understand where kernel messages actually land. There are three destinations:

Understanding this architecture is important: even if a message does not appear on your console, it is almost certainly in the ring buffer. If you cannot see a message on screen, your first action should always be to check dmesg.

How to Change the Console Log Level at Runtime

The most common need during kernel module development is to raise the console log level so that all pr_info() and pr_warn() messages appear directly on the terminal without needing dmesg. Here are the methods, from most convenient to most permanent:

Method 1: Write directly to /proc/sys/kernel/printk

This is the most direct method. You write four space-separated values representing the four log level parameters. The change takes effect immediately but is lost after a reboot.

# Show current values
cat /proc/sys/kernel/printk

# Set console log level to 8 — all printk messages appear on console
# Format: current_level  default_level  min_level  boot_default_level
echo "8 4 1 7" | sudo tee /proc/sys/kernel/printk

# Verify the change
cat /proc/sys/kernel/printk
# Output: 8    4    1    7

# Restore to the typical production default
echo "4 4 1 7" | sudo tee /proc/sys/kernel/printk

Method 2: Use sysctl

The sysctl command provides a cleaner interface to the same kernel parameter. It reads from and writes to /proc/sys/ under the hood.

# Read the current value
sysctl kernel.printk

# Set all four values: console  default  min  boot_default
sudo sysctl -w kernel.printk="8 4 1 7"

# Read back to verify
sysctl kernel.printk
# Output: kernel.printk = 8    4    1    7

Method 3: Make it persistent across reboots via /etc/sysctl.conf

If you want a custom log level to survive reboots — common on a dedicated development board — add it to the sysctl configuration file.

# Open /etc/sysctl.conf or create a drop-in file
sudo nano /etc/sysctl.d/99-kernel-debug.conf

# Add this line:
kernel.printk = 8 4 1 7

# Apply immediately without rebooting:
sudo sysctl -p /etc/sysctl.d/99-kernel-debug.conf

Method 4: Use the kernel boot parameter

For embedded Linux systems or systems where you want to set the log level very early in the boot process (before the filesystem mounts), you can set it as a kernel command-line parameter.

# Add to the kernel command line in your bootloader (GRUB, U-Boot, etc.)
# This sets console log level to 8 from the very beginning of boot

loglevel=8

# Example GRUB entry in /etc/default/grub:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash loglevel=8"

# After editing, regenerate GRUB config:
sudo update-grub

Comparison: Which Method Should You Use?

A Practical Pattern: Startup Script for Development Boards

When you regularly develop kernel modules on a dedicated board (a Raspberry Pi, BeagleBone, or any ARM SBC), it is convenient to set the console log level automatically when you log in as root. A lightweight way to do this is via a startup script or your shell’s profile.

#!/bin/sh
# /etc/profile.d/kernel-dev-setup.sh
# Automatically configure kernel log level for development
# Only applies when running as root

if [ "$(id -u)" -eq 0 ]; then
    # Set console log level to 8: all printk messages go to console
    echo "8 4 1 7" > /proc/sys/kernel/printk
    echo "[kernel-dev] Console log level set to 8. All printk visible."
fi

Filtering dmesg Output by Log Level

Even when messages are not appearing on your console, dmesg shows everything in the ring buffer. Modern versions of dmesg (from util-linux 2.21 onwards, which covers most Linux distributions using kernel 4.x and above) support powerful filtering options.

# Show messages from the current boot session only
dmesg

# Follow kernel messages in real time (like tail -f for kernel log)
dmesg -w

# Show messages with human-readable timestamps instead of seconds since boot
dmesg -T

# Filter by log level — useful to see only critical problems
dmesg --level=err
dmesg --level=crit,alert,emerg
dmesg --level=warn,err,crit,alert,emerg

# Show the last 30 lines
dmesg | tail -30

# Search for your module's messages by filtering on your module name or prefix
dmesg | grep "EP Demo"

# Clear the ring buffer before loading your module for a clean slate
sudo dmesg -C
sudo insmod my_module.ko
dmesg

Unlocking pr_debug() with Dynamic Debug

As covered in the previous tutorial, pr_debug() is compiled out unless the DEBUG macro is defined. However, the Linux kernel offers a more powerful and flexible system called Dynamic Debug (CONFIG_DYNAMIC_DEBUG), which lets you enable and disable debug messages at runtime without recompiling the kernel or your module.

Step 1: Check if Dynamic Debug is available

# Check if the dynamic debug control file exists
ls /sys/kernel/debug/dynamic_debug/control

# If the path does not exist, mount debugfs first:
sudo mount -t debugfs debugfs /sys/kernel/debug

Step 2: Enable pr_debug() for a specific module

# Enable all debug messages from a specific module
# Replace 'my_module' with your module's name
echo "module my_module +p" | sudo tee /sys/kernel/debug/dynamic_debug/control

# Enable debug messages from a specific source file only
echo "file my_module.c +p" | sudo tee /sys/kernel/debug/dynamic_debug/control

# Enable debug messages from a specific function only
echo "func my_init_function +p" | sudo tee /sys/kernel/debug/dynamic_debug/control

# Disable debug messages again
echo "module my_module -p" | sudo tee /sys/kernel/debug/dynamic_debug/control

Step 3: Alternative — Define DEBUG in your Makefile

If your kernel does not have CONFIG_DYNAMIC_DEBUG enabled, you can define the DEBUG macro specifically for your module in your Makefile. This causes pr_debug() and pr_devel() to be compiled in for that module only, without affecting the rest of the kernel.

# In your module's Makefile, add this line:
CFLAGS_my_module.o := -DDEBUG

# Full Makefile example:
obj-m += my_module.o
CFLAGS_my_module.o := -DDEBUG

all:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

Putting It All Together: The Complete Log Level Decision Flow

Common Mistakes When Working With Kernel Log Levels