Boot Process: Bootloader - Boot the System

A boot loader bridges firmware discovery and kernel execution. GRUB is common on Linux PCs, but systemd-boot, U-Boot, firmware loading of an EFI-stub kernel, and other designs implement different parts of this role.

Selecting Boot Artifacts

A loader entry can identify:

a Linux kernel image
an optional initramfs or legacy initrd image
a kernel command line
platform-specific metadata or another operating system's loader

GRUB can present multiple kernels and recovery entries. A fallback kernel is useful only when its matching modules and initramfs remain available and tested. The loader reads files through its supported storage and filesystem modules; it does not rely on the not-yet-running Linux VFS.

CheckWhat does a Linux boot loader normally transfer control to?

Kernel Command-Line Parameters

The loader passes a text command line that the kernel and early user space parse. Common examples include:

root=... to identify the intended root filesystem or early-user-space source specification
ro or rw to request an initial root mount mode
quiet to reduce kernel console messages
init=... to request a different first user-space program for specialized recovery
distribution-specific rd.* parameters interpreted by initramfs tooling

initrd is normally a loader directive naming an image, not a generic kernel parameter. BOOT_IMAGE= can appear in a command line produced by some GRUB configurations, but it is not the mechanism that loads the kernel.

Inspect the command line used for the current boot with:

$ cat /proc/cmdline

CheckWhat is the purpose of the root= kernel command-line parameter?

CheckWhat does the quiet parameter normally request?

Temporary Editing and Recovery

GRUB commonly lets an authorized console user edit an entry for one boot, often through an edit key shown by the menu. This is useful for removing quiet, selecting recovery parameters, or correcting a bad root identifier. Interface and authorization vary, especially with Secure Boot and password-protected GRUB configurations.

Command-line parameters can expose sensitive text through /proc/cmdline, boot logs, and crash reports. They can also weaken security or make the system unbootable. Never place secrets there, and preserve a known-good entry and console recovery path.

CheckWhat is a typical property of editing a GRUB menu entry interactively for one boot?

Persistent GRUB Configuration

Distributions commonly generate the final GRUB configuration from templates, defaults, scripts, and discovered kernels. Do not edit the generated grub.cfg directly unless the distribution explicitly documents that workflow; regeneration can overwrite it.

Make a scoped source change, run the distribution's documented regeneration command, inspect its output, and test while retaining an older known-good entry and bootable recovery media. The command and output path differ between Debian, Fedora, UEFI, and BIOS installations.

CheckWhy is directly editing a generated grub.cfg usually unreliable?

Use Customize the GRUB2 Boot Menu only in its recovery-capable lab environment.

Summary

You can now separate loader directives from kernel command-line parameters.

Identify kernel, initramfs, command line, and alternate entries.
Use root=, ro, and quiet according to their actual roles.
Inspect the running boot's parameters through /proc/cmdline.
Treat interactive edits as temporary and security-sensitive.
Change persistent generated configuration through the distribution workflow.

Practice

In the practice terminal, run: cat /proc/cmdline It prints the kernel command line with parameters such as root=, ro, and quiet that the bootloader passed to the kernel.

The loader selects the kernel and initramfs and builds this command line.