Table of Contents
Introduction
Kernel parameters are configuration values that control how the Linux kernel behaves. They influence hardware support, performance, security, debugging, and many other aspects of the system. Unlike recompiling the kernel, changing parameters lets you tune behavior at boot time or even while the system is running, in a controlled and reversible way.
This chapter focuses on what kernel parameters are, how they are passed and interpreted, where to see them, and how to change them safely, both temporarily and persistently.
What kernel parameters are
The kernel accepts name–value pairs such as loglevel=3 or intel_iommu=on at boot. Many of these parameters are read once at startup and then fix certain policies. Others are connected to tunable variables that you can inspect and adjust later through interfaces like /proc and /sys.
Kernel parameters fall into a few broad categories. There are global kernel behavior parameters, such as those controlling logging verbosity or memory overcommit. There are hardware and driver parameters that tell the kernel how to deal with specific devices. There are security and mitigation parameters for features like Spectre and Meltdown. There are debugging and development parameters that enable tracing, early logging, or special diagnostic modes.
Once you understand that many of these parameters correspond to values that live in procfs and sysfs, you can think of kernel parameters as the initial values or configuration switches that the kernel consults when it first starts.
Where kernel parameters come from
On a typical Linux system that uses GRUB2, the bootloader is responsible for passing kernel parameters to the kernel. Other bootloaders, and firmware features like UEFI, do something similar. The parameters are part of the linux line in a boot entry, immediately following the kernel image path.
For example, in a GRUB menu entry you might see a line similar to:
linux /boot/vmlinuz-6.8.0-xyz root=UUID=... ro quiet splash
Everything after /boot/vmlinuz-6.8.0-xyz is a parameter. Here root=UUID=... tells the kernel which block device contains the root filesystem, ro tells it to mount the root read-only at first, and quiet and splash adjust console output and the graphical splash screen.
Bootloaders build this command line from configuration files in /boot or /etc. On some distributions a single variable such as GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub is expanded into the kernel argument list. When you change kernel parameters persistently, most of the time you are editing these bootloader configuration files or tools that generate them.
Viewing the current kernel command line
After the system has booted, you can see exactly which parameters were passed to the kernel by reading /proc/cmdline. This is a virtual file that exposes the kernel command line as a single line of text.
For example:
cat /proc/cmdlinemight produce something like:
BOOT_IMAGE=/boot/vmlinuz-6.8.0-xyz root=UUID=... ro quiet splash intel_iommu=on mitigations=auto
This shows both the parameters the distribution configured and any custom parameters you may have added. BOOT_IMAGE is added by the bootloader. The rest are the effective kernel parameters.
You can use this file to confirm that a particular parameter has taken effect, which is essential when testing performance or security changes.
Reading and changing runtime tunables
Some kernel parameters have a runtime representation in /proc/sys. This is the interface used by the sysctl tool. At boot you might set a value such as vm.swappiness=10 through the kernel command line or a sysctl configuration file, and at runtime you can inspect it with:
cat /proc/sys/vm/swappinessYou can also change it, as root, by echoing a numeric value:
echo 20 > /proc/sys/vm/swappiness
In practice it is more convenient and safer to use sysctl:
sysctl vm.swappiness
sysctl -w vm.swappiness=20
Some kernel parameters only exist at boot time. Once the kernel has processed them, there is no equivalent file in /proc/sys or /sys. For these, you must modify the bootloader configuration and reboot to change them.
Kernel parameters that affect memory management, security features, or I/O scheduling can have large performance and stability impacts. Always test changes in a non-production environment first and document exactly which parameters you changed and why.
Temporary kernel parameters at boot
A very common way to experiment with a parameter is to add it only for a single boot. With GRUB, you can usually do this from the interactive boot menu without editing any configuration files.
On many systems, you interrupt the boot process to reach the GRUB menu, select a kernel entry, then press a specific key (for example, e) to edit that entry temporarily. GRUB will show the script-like definition of that menu entry, including the line that starts with linux. You move the cursor to the end of that line and append parameters, separated by spaces.
For instance, to boot with serial console logging and a debugging parameter, you might add:
console=ttyS0,115200 earlyprintk=serialThen you instruct GRUB to boot with these modifications. They apply only to that one boot. After the system restarts again, the configuration reverts to the original state.
This method is also used during troubleshooting, for example to add systemd.unit=rescue.target or init=/bin/bash in order to gain minimal access to a system that is otherwise unable to boot fully.
Persistent kernel parameters with GRUB
To make persistent changes, you need to adjust how the bootloader constructs the kernel command line each time the system boots. On distributions that use GRUB2, this is generally done through /etc/default/grub, which is then processed by a tool like update-grub or grub2-mkconfig.
On many Debian and Ubuntu based systems you will see lines like:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""
Values placed in GRUB_CMDLINE_LINUX_DEFAULT are added to standard boot entries, often for graphical or desktop use. Values in GRUB_CMDLINE_LINUX are added to all entries, including recovery modes.
To persistently enable an IOMMU feature and adjust mitigations, you might change the first line to:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_iommu=on mitigations=auto"After editing, you must regenerate the GRUB configuration:
sudo update-grubor on some RPM-based distributions:
sudo grub2-mkconfig -o /boot/grub2/grub.cfgor, for UEFI systems:
sudo grub2-mkconfig -o /boot/efi/EFI/<distro>/grub.cfg
The exact paths vary between distributions. Once the configuration is rebuilt, you reboot. Then you can verify that the new parameters are active by checking /proc/cmdline.
When editing bootloader configuration, a syntax error or incorrect root parameter can render your system unbootable. Always keep a known-good entry or recovery option in the GRUB menu and avoid removing existing, working parameters until you have tested the new configuration.
UEFI-specific parameter handling
On some modern systems that use UEFI and a distribution that boots via tools like systemd-boot, kernel parameters may be stored differently. Rather than a single GRUB script, you may have several small configuration files for each kernel entry under directories like /boot/loader/entries/.
A typical entry could contain a line:
options root=UUID=... rw quiet splash
To add a kernel parameter persistently, you edit the options line in the specific entry file, add the parameter, save the file, and reboot. Because these configuration files are often on the EFI system partition, you may need elevated permissions and the filesystem must be mounted read-write.
The principle is the same as with GRUB. You locate where the bootloader defines its kernel command line, edit that configuration file, and then verify the changed parameters using /proc/cmdline after reboot.
Sysfs and module-specific parameters
Not all tunable kernel behavior is exposed via /proc/sys. Much of the hardware-specific configuration lives under /sys. These tunables are often associated with particular kernel modules and drivers.
For example, network interface settings and power management options are visible under paths like /sys/class/net/ or driver-specific directories under /sys/module/. When a module is loaded, it may take parameters that influence how it drives the hardware.
Some module parameters can be set on the kernel command line as module_name.parameter=value. For example, to change a parameter of the i915 graphics driver you might add:
i915.enable_psr=0
This instructs the kernel to pass enable_psr=0 to the i915 module at load time. Alternatively, on a system where the module is loaded after boot, you might place a configuration file in /etc/modprobe.d/ to set the module parameter there. Although module parameter configuration is a broader topic, from the kernel's perspective these are still parameters interpreted during the boot process or module initialization.
Security-related parameters
Many modern Linux kernels support parameters that adjust security features and mitigations. These are typically global kernel boot parameters, not values you toggle casually during runtime.
Examples include mitigations=off or mitigations=auto, which control mitigations for speculative execution vulnerabilities, or parameters that influence kernel address space layout randomization and other hardening techniques.
These parameters often trade off between performance and security. For instance, disabling certain mitigations might increase performance on CPU intensive workloads but expose the system to known hardware side channel attacks.
Security-related kernel parameters should be changed only after you understand the risk model of your system. Disabling mitigations or relaxing hardening options can violate compliance requirements and make exploitation of vulnerabilities easier. Always consult your distribution’s security guidance before changing these values.
Debugging and special boot modes
Kernel parameters are also central to debugging difficult boot and runtime problems. A few examples illustrate the kinds of effects you can achieve solely through the command line.
To obtain more verbose kernel messages during boot you might add parameters that increase logging or disable the graphical splash screen. To force the system into a minimal environment you might set:
systemd.unit=rescue.targetor even replace the normal init process with something else by specifying:
init=/bin/bash
In this last case, the kernel executes /bin/bash as process 1, giving you a powerful but fragile environment in which you can repair broken configuration. In such a mode, you must manually mount filesystems and eventually reboot, since there is no full init system or service management.
Other debugging parameters control low-level behavior such as early printk output, crash kernel reservation, or special handling for panic conditions. These parameters are vital tools when diagnosing hardware incompatibilities or failures that occur very early in the boot process.
Testing and rollback strategy
When experimenting with kernel parameters, especially on systems that are important to you, it is wise to use a staged approach. First, test parameters interactively via one-time boot edits in the bootloader menu. This lets you confirm that the system still boots and that the behavior is as expected. Only after you have validated the effect should you commit the parameter to a persistent configuration file.
It is also important to introduce one change at a time. If you adjust several parameters in a single boot and something breaks, it becomes difficult to know which parameter caused the issue. Adding a parameter, rebooting, testing, and then repeating with the next parameter gives you a clear record of which change produced which result.
If a parameter causes the system to fail to boot, you usually recover by selecting an alternative entry in the bootloader menu, such as an older kernel or a recovery entry. From there you can revert the changes in your configuration files and regenerate the bootloader configuration.
Summary
Kernel parameters are a powerful interface between the bootloader and the Linux kernel. They control early system initialization, hardware configuration, security policies, and many runtime tunables. You inspect them through /proc/cmdline, change them at runtime through interfaces like /proc/sys and sysctl when possible, and adjust them persistently by modifying your bootloader configuration.
Used carefully, kernel parameters let you tune and debug Linux systems without recompiling the kernel. Used carelessly, they can destabilize or weaken a system. Understanding where they are defined, how to apply them temporarily, and how to revert them is essential for advanced Linux system administration.