1. Introduction
The boot parameters for the kernel are an essential part of system configuration. Despite that, they aren’t changed very often. Still, some parameters appear even in fresh installations.
In this tutorial, we’ll talk about two common options on the kernel boot command line and what their function is. First, we briefly refresh our knowledge about kernel parameters and the boot command line. After that, we focus on two particular arguments we might encounter and how they affect the visual experience during system loading.
We tested the code in this tutorial on Debian 12 (Bookworm) with GNU Bash 5.2.15. It should work in most POSIX-compliant environments unless otherwise specified.
2. Kernel Parameters and the Boot Command Line
The kernel can and often is a complex piece of software that comprises many moving parts. While building a custom kernel is almost always a viable option in the world of Linux, doing so isn’t always straightforward.
Despite this, we might need custom configuration depending on our operating system (OS) use case:
- embedded system
- server
- desktop
- specific hardware controller
In fact, there are many more reasons to modify the behavior of the OS core, such as settings for modules, drivers, network, peripherals, interfaces, memory management, power options, interrupts, and others.
To support such kernel features from the start of a Linux system, kernel parameters are usually employed as part of the boot command line. They provide ways to ensure we have a certain pre-configured environment at the very core of a system.
Usually, we configure the current boot command line through the bootloader configuration.
For example, GRUB offers two main file parts to manipulate the boot command line:
- /etc/default/grub, in GRUB_CMDLINE_LINUX
- /etc/grub.conf, on the kernel line
By tweaking them, we can add or remove any option, customizing our system start functions and experience.
3. System Loading Visuals Boot Parameters
Let’s check the kernel boot parameters of a fresh Debian installation by using the /proc/cmdline file in the /proc pseudo-filesystem:
$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.10.0-666-amd64 root=UUID=16660ed0-beef-dead-d0d0-1006660deaf1 ro quiet
In this case, we load the vmlinuz-5.10.0-666-amd64 kernel file as the current BOOT_IMAGE with ro read-only rights.
Notably, we can add any option that isn’t part of the official kernel parameters. In such instances, the kernel doesn’t interpret the option, but the latter still becomes part of the /proc/cmdline through the bootloader configuration.
Thus, any parameter on the boot command line can be interpreted by initialization scripts and initialization management in general.
3.1. quiet
At the end of our initial kernel parameter list above is the quiet option. Its official description is [KNL] Disable most log messages.
In practice, quiet ensures we don’t see too much debugging information from the boot log:
$ journalctl --boot
-- Journal begins at Thu 2022-12-22 22:00:12 EDT, ends at Mon 2023-10-10 10:10:00 EDT. --
Oct 10 10:00:01 xost kernel: Linux version 5.10.0-666-amd64 ([email protected]) gcc->
Oct 10 10:00:01 xost kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-666-amd64 root=UUID=16660e>
Oct 10 10:00:01 xost kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Oct 10 10:00:01 xost kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Oct 10 10:00:01 xost kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Oct 10 10:00:01 xost kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
Oct 10 10:00:01 xost kernel: x86/fpu: Enabled xstate features 0x7, context size is 666 bytes, using '>
Oct 10 10:00:01 xost kernel: BIOS-provided physical RAM map:
[...]
Above, we use journalctl to see the messages starting from the last –boot. If we have quiet in the kernel parameters, we’d usually only see a prompt with characteristics that depend on the system. Often, it just ends up being a blinking underscore.
Since waiting for a system to boot might take a while, seeing a mostly black screen during that time can be discouraging or even worrying, depending on the circumstances and the user. Because of this, we usually employ another option alongside quiet.
3.2. splash
The concept of a splash screen or bootsplash has been around for a long time. In fact, it was even part of many applications in the past. Basically, this is an image or animation that shows up while the actual interface for a given system loads:
.:~?YYY?7!7!7!^:
:!JPGBBBBBBBBBBBBBG5J?J!..
^J5GBBBBBGPYJJJ???JY5PBBBBBGPJ^
!5BBBBBP5Y7^ .:~JGBBBBB5~
:5BBBBG5!. .7PBBBBBY:
.. ^GBBGY!. .?BBBBBP^
.?GBBJ^ . ~GBB?!7
. JBBG^ :!???77!~:. !BBG!..
.7BBB7 .?Y!:. ... .PBB? .
:GBB! ^P! YBB5
:GBP. :G! .. YBBP.
^BBY 7B. 5BP:
^BB? !B7 : ~BB!
^BB? YB~ .:. . JB5!
:GBP. ::?P?: .. .!5P?.
YBB~ .::~J5Y7^:...:^~?5P5!.
^BB5. .:~JYYYYYYYYJ7~:
?BBG5~ ..::::
JBBBY
?BBB7
~PBB7
.JGB5^
:JGB?^
:7PBP7.
^?55J?^
:~7J?!^::.
In this case, we see the Debian logo in ASCII art form.
Importantly, the splash option isn’t an official kernel parameter. Instead, it undergoes interpretation after the kernel loads. In many major Linux distributions, splash ends up displaying a graphic while the main components of the system load and we reach the user login stage.
How that is done and the configuration behind it depends on the Linux distribution and userspace packages. For example, Plymouth handles splash screens in most major Debian-based systems.
4. Summary
In this article, we explored two kernel parameters that are often part of default installations and affect the boot process in a cosmetic way.
In conclusion, while debugging may sometimes necessitate following the boot log while it’s being populated, we might just need a general overview of the system start process.