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.
Boot the System · Lesson 3
Boot Process: Bootloader
Learn how a boot loader selects Linux artifacts, constructs the kernel command line, and transfers control.
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.
What 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 specificationroorrwto request an initial root mount modequietto reduce kernel console messagesinit=...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
What is the purpose of the root= kernel command-line parameter?
What 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.
What 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.
Why is directly editing a generated grub.cfg usually unreliable?
Use Customize the GRUB2 Boot Menu only in its recovery-capable lab environment.
Lesson complete
You finished Boot Process: Bootloader
You can now separate loader directives from kernel command-line parameters.
Identify kernel, initramfs, command line, and alternate entries.
Use
root=,ro, andquietaccording 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.
Keep your learning progress
Create a free account to save this lesson and continue learning on any device.
Create a free account