Every time a Linux machine powers on, it walks through a predictable chain of hand-offs: firmware, boot loader, kernel, initial RAM filesystem, and finally the init system. Each stage has one job and then passes control to the next. Knowing the order lets you work out where a broken boot stopped and which tool fixes it, which is exactly how Linux+ questions are framed: they describe what you see on the screen and ask what to change.
The firmware comes first. Older machines use BIOS (Basic Input/Output System), which reads the first sector of the boot disk, the MBR (Master Boot Record), and runs the small piece of boot code stored there. Modern machines use UEFI (Unified Extensible Firmware Interface), which instead reads an ESP (EFI System Partition), a small FAT-formatted partition usually mounted at /boot/efi, and runs an EFI executable such as grubx64.efi or shimx64.efi. UEFI keeps its list of boot entries in firmware variables, which you can view with efibootmgr -v. UEFI also supports Secure Boot, where the firmware only runs boot loaders signed with trusted keys; the signed shim is what lets distributions boot under Secure Boot. You can check which mode you booted in by looking for the /sys/firmware/efi directory: if it exists, you booted with UEFI.
Next is the boot loader, almost always GRUB2 (GRand Unified Bootloader version 2). GRUB shows the menu of kernels, loads the chosen kernel image (for example /boot/vmlinuz-...) and the matching initramfs into memory, and passes the kernel its command line, such as root=UUID=... and quiet. You never edit the generated grub.cfg directly, because the next kernel update regenerates it. Instead, you change /etc/default/grub (for example GRUB_TIMEOUT or GRUB_CMDLINE_LINUX) and regenerate the file with grub2-mkconfig -o /boot/grub2/grub.cfg on Red Hat-family systems or update-grub (a wrapper for grub-mkconfig) on Debian-family systems. The grubby tool on RHEL-like systems edits kernel arguments per entry, for example grubby --update-kernel=ALL --args="console=ttyS0". If the boot loader itself is damaged, grub2-install (or grub-install) writes it back to the disk.
The kernel then initializes hardware it has built-in drivers for, but it often cannot yet read the real root filesystem, because the driver for the disk controller, LVM (Logical Volume Manager), RAID or LUKS encryption lives in a module on that very filesystem. The initramfs (initial RAM filesystem) solves this chicken-and-egg problem: it is a compressed archive unpacked into memory that contains just enough modules and scripts to find, unlock and mount the real root, then switch to it. It is rebuilt with dracut on Red Hat, Fedora and SUSE (dracut -f regenerates the image for the running kernel) and with mkinitramfs or, more commonly, update-initramfs -u on Debian and Ubuntu. Rebuild it after adding a storage driver, changing encryption or changing root-device settings. lsinitrd (dracut) and lsinitramfs (Debian) list what an image contains.
Once root is mounted, the kernel starts PID 1 (process ID 1), which on current distributions is systemd. systemd brings the system to a target, a named group of units that replaces the old SysV runlevels. Common ones are multi-user.target (text-mode server, like runlevel 3), graphical.target (desktop, like runlevel 5), rescue.target (single-user with basic services and local filesystems mounted) and emergency.target (almost nothing, root mounted read-only). See the default with systemctl get-default, change it with systemctl set-default multi-user.target, and switch the running system with systemctl isolate rescue.target. For a one-time change at boot, press e at the GRUB menu, add systemd.unit=rescue.target (or emergency.target) to the line starting with linux, then press Ctrl+X. That edit is not saved, which makes it a safe way to recover a system. After booting, systemd-analyze blame shows which units slowed startup.
Consider a worked example. A server fails to boot after its root filesystem is moved onto a new RAID controller, and it drops to a dracut emergency shell saying it cannot find the root device. The firmware and GRUB clearly worked, because the kernel ran, so the problem is at the initramfs stage. You reboot, pick an older kernel entry from the GRUB menu, confirm the controller's module with lsmod, and run dracut -f to rebuild the initramfs with the new driver. You check with lsinitrd | grep and the module name, reboot, and the root filesystem is found normally.
Common mistakes: editing grub.cfg by hand and losing the change at the next kernel update; changing /etc/default/grub and forgetting to regenerate; confusing rescue.target with emergency.target (rescue mounts local filesystems and starts a few services, emergency gives you only a shell on a read-only root); rebuilding the initramfs for the wrong kernel version; and assuming a UEFI system has an MBR boot sector to repair when its boot loader actually lives on the ESP.
Exam questions usually give a symptom and ask for the stage or the command. 'No boot menu, firmware cannot find a boot device' points to firmware settings, the ESP or reinstalling GRUB. 'Kernel panic: unable to mount root' or 'dracut emergency shell' points to the initramfs or the root= argument. 'Change kernel arguments permanently' points to /etc/default/grub plus grub2-mkconfig, or grubby. 'Boot to text mode from now on' is systemctl set-default multi-user.target, while 'once, to reset a password or fix fstab' points to editing the kernel line at the GRUB menu.
Key terms
- UEFI
- Unified Extensible Firmware Interface: modern firmware that boots EFI executables from an EFI System Partition and supports Secure Boot.
- ESP
- EFI System Partition: a small FAT partition, usually mounted at /boot/efi, that holds UEFI boot loaders.
- GRUB2
- The standard Linux boot loader; configured through /etc/default/grub and a generated grub.cfg.
- initramfs
- A compressed temporary root filesystem loaded into RAM that contains the drivers and scripts needed to mount the real root filesystem.
- dracut / mkinitramfs
- Tools that build the initramfs image: dracut on Red Hat-family and SUSE, mkinitramfs/update-initramfs on Debian-family.
- systemd target
- A unit that groups other units into a system state, such as multi-user.target or graphical.target, replacing SysV runlevels.
- Secure Boot
- A UEFI feature that only runs boot loaders and kernels signed with trusted keys.
After moving a server's root filesystem onto a new RAID controller, it fails to boot and drops to a dracut emergency shell saying it cannot find the root device. You boot an older kernel entry from the GRUB menu, confirm the controller's module name with lsmod, then run dracut -f to rebuild the initramfs so it includes the new driver. The next boot finds the root filesystem normally.
Check yourself
You edited GRUB_CMDLINE_LINUX in /etc/default/grub on a RHEL system, but the change has no effect after reboot. What step was missed?
Regenerating the GRUB configuration with grub2-mkconfig -o /boot/grub2/grub.cfg (or using grubby); /etc/default/grub is only read when the config is rebuilt.
Why does Linux need an initramfs at all?
Because the drivers needed to reach the root filesystem (storage controller, LVM, RAID, LUKS) may be modules stored on that filesystem; the initramfs carries them in RAM so the real root can be mounted.
Which command makes a server boot to a text console by default from now on?
systemctl set-default multi-user.target, which changes the default target persistently.
How can you tell whether a running system booted in UEFI or legacy BIOS mode?
Check whether /sys/firmware/efi exists; it is present only when the system booted through UEFI.