Read and Audit Linux Boot Arguments with /proc/cmdline

You will inspect the command line supplied when the running Linux kernel booted, find a named argument without changing the machine, and tell apart kernel, boot-loader and init arguments. Allow about 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, installed here through 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 ...

The output is one line of arguments passed to the kernel at boot. Its exact contents depend on the boot loader, kernel image, initramfs and machine configuration. It is not a saved configuration file that you can edit in place. Reading it does not require elevated privileges on this system.

Checkpoint: confirm that the file is present and readable:

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

If that check fails, inspect the mount rather than assuming that the kernel has no arguments:

$ mountpoint /proc
/proc is a mountpoint

A restricted container or unusual recovery environment may expose a different view of procfs. The file describes the kernel visible from the environment in which you read it.

2. Count arguments without printing sensitive values

Boot arguments can contain storage identifiers, network details or other operational information. When you only need a quick sanity check, count fields instead of copying the whole line into a ticket:

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

This uses whitespace-separated fields. It is a rough count, not a parser for every possible argument format. The kernel command line is conventionally a sequence of space-separated parameters, but a value containing spaces may need quoting or escaping in the component that creates it.

3. Check for one exact parameter

For a simple presence check, make the pattern match a complete whitespace-delimited token. This avoids treating quietly as a match for quiet:

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

The command only reads procfs and returns a useful status for a script. Replace quiet with the parameter you are investigating. For a key with a value, match the key and equals sign, then inspect 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 use an unreviewed substring search for security-sensitive decisions. A parameter can be repeated, and the subsystem that consumes it may define its own precedence rules.

4. Know what the tokens mean

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

Do not assume that every token is a kernel setting. The current kernel documentation marks some parameters as boot-loader parameters. It also documents a separator, --: kernel parsing stops there, and arguments after it are passed to init. An unrecognised argument before the separator may also be passed to init under the kernel's documented rules. This is why changing a token can affect early boot, userspace startup or both.

Module settings commonly use a prefix such as module.option=value. The kernel documentation explains that modprobe can scan /proc/cmdline for these settings when loading modules. Check the relevant module documentation before treating a spelling as valid. Parameter names are case-sensitive.

5. Investigate a mismatch safely

If a machine behaves differently after a reboot, record the relevant evidence before changing 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 associated with them. Access to the kernel log can be restricted, so a non-zero result from dmesg is a permissions or policy issue, not proof that the boot arguments are wrong.

Keep any captured command line private if it includes disk UUIDs, network addresses, console settings or debugging switches. Redact those values before sharing it. Reading this file changes nothing, but editing the boot-loader configuration or adding a kernel argument changes the next boot and can prevent a system starting. Do not make that change as part of this inspection. If you already changed a boot entry, undo the edit in the boot loader's configuration and regenerate its menu using that distribution's documented procedure, then reboot during an approved maintenance window.