Read and Audit Boot Arguments with /proc/cmdline

Every argument the kernel booted with is sitting in /proc/cmdline, plain to read. The trick is knowing which tokens came from GRUB, which from the kernel image, and which get handed straight to init. This guide covers reading the line, finding one named argument, and keeping the machine untouched while you do it. Budget ten minutes; you need a shell and a running Linux system with /proc mounted. The examples use the local proc_cmdline(5) page from Linux man-pages 6.7, package version 6.7-2.

1. Read the current boot command line

Read the virtual file directly:

$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-... root=UUID=... ro ...

That is one line of arguments passed to the kernel at boot. Its contents depend on the boot loader, kernel image, initramfs and machine configuration, and it is not a saved configuration file you can edit in place. Reading it needs no elevated privileges on this system.

$ test -r /proc/cmdline && echo 'readable'
readable

If that check fails, look at the mount rather than assuming the kernel booted with no arguments at all:

$ mountpoint /proc
/proc is a mountpoint

A restricted container or an unusual recovery environment can present a different view of procfs. The file only ever describes the kernel visible from wherever you happen to be reading it.

2. Count arguments without printing sensitive values

Boot arguments can carry storage identifiers, network details or other operational information you would rather not paste into a ticket. For a quick sanity check, count fields instead:

$ awk '{print NF " arguments"}' /proc/cmdline
7 arguments

This splits on whitespace, so treat it as a rough count rather than a full parser. The kernel command line is conventionally a sequence of space-separated parameters, but a value containing spaces may need quoting or escaping wherever it was originally set.

3. Check for one exact parameter

Make the match a complete whitespace-delimited token so you never mistake quietly for quiet:

if grep -qE '(^| )quiet( |$)' /proc/cmdline; then
    printf '%s\n' 'quiet is present'
else
    printf '%s\n' 'quiet is absent'
fi

This only reads procfs and hands back a usable status for a script. Swap quiet for whatever parameter you are actually chasing. For a key with a value, match the key and the equals sign, then handle the value deliberately:

value=$(sed -n 's/.*\(^\| \)loglevel=\([^ ]*\).*/\2/p' /proc/cmdline)
if [ -n "$value" ]; then
    printf 'loglevel=%s\n' "$value"
else
    printf '%s\n' 'loglevel is absent'
fi

Do not lean on an unreviewed substring search for a security-sensitive decision. A parameter can repeat, and whatever subsystem consumes it may apply its own precedence rules that a naive grep will not reflect.

4. Know what the tokens actually mean

The manpage says arguments can arrive from a boot manager such as GRUB or LILO, and it also records arguments embedded in the kernel image or initramfs through CONFIG_BOOT_CONFIG. So seeing a token in /proc/cmdline tells you what reached the running system, not which configuration file originally set it.

Do not assume every token is a kernel setting either. The current documentation marks some parameters as boot-loader parameters, and it documents a separator, --: kernel parsing stops there, and everything after it is passed straight to init. An unrecognised argument before that separator can also end up passed to init, under the kernel's own documented rules. That is exactly why changing one token can affect early boot, userspace startup, or both at once.

Module settings commonly use a prefix like module.option=value, and the kernel documentation explains that modprobe can scan /proc/cmdline for these when loading a module. Check the relevant module's own documentation before trusting a spelling: parameter names are case-sensitive.

5. Investigate a mismatch without changing anything yet

If a machine behaves differently after a reboot, record the evidence before you touch boot configuration:

$ uname -r
6.8.0-139-generic
$ sed -n '1p' /proc/cmdline
BOOT_IMAGE=/vmlinuz-... root=UUID=... ro ...
$ dmesg --level=err,warn | tail -n 20

uname -r identifies the running kernel, the second command records the active arguments, and the third may show warnings tied to them. Access to the kernel log can be restricted, so a non-zero result from dmesg is a permissions or policy issue rather than proof the boot arguments themselves are wrong.