BIOS (Basic Input/Output System) is legacy firmware from the IBM PC era (1980s) that operates in 16-bit real mode with severe limitations: it can only boot from MBR-formatted disks up to 2TB, requires a compatibility layer for modern operating systems, and provides minimal configuration interfaces.

UEFI (Unified Extensible Firmware Interface) is the modern replacement. It runs in 32 or 64-bit mode, supports GPT disks larger than 2TB, includes Secure Boot for boot-time verification, and provides a full API for boot-time services. UEFI stores bootloaders as files in a dedicated EFI System Partition (ESP) rather than embedding code in the MBR.

Most modern systems ship with UEFI, with BIOS compatibility (CSM) available for legacy boot scenarios. Linux and Windows support both, but UEFI is preferred for modern installations.

The bootloader's job is to bridge the gap between the firmware (which knows how to read from storage) and the operating system kernel (which needs to be loaded into memory with proper parameters). It provides several critical functions:

• Locates the kernel on the storage device
• Loads the kernel and optional initial ramdisk (initramfs) into memory
• Understands filesystem structure to find files
• Presents boot options (multiple kernels, recovery modes)
• Passes configuration parameters to the kernel

On Linux, GRUB is the standard bootloader. It works with both BIOS and UEFI systems, understands ext4, XFS, Btrfs and other filesystems, and provides an interactive menu for boot selection.

initramfs (initial RAM filesystem) is a compressed cpio archive loaded into RAM by the bootloader before the kernel takes over. It contains a minimal Linux environment with utilities needed to prepare the real root filesystem.

The problem it solves: the kernel needs a root filesystem to mount, but if the root filesystem requires special drivers (LUKS encryption, LVM, RAID, specific SATA controllers), those drivers might be on the root filesystem itself—a chicken-and-egg problem.

initramfs breaks this cycle by containing the necessary drivers to unlock encrypted volumes, assemble RAID arrays, activate LVM logical volumes, and mount the real root filesystem. Once mounted, the system "pivots root" from initramfs to the real filesystem and continues booting.

When the kernel finishes early initialization, it looks for the first userspace process to run—the first program that isn't part of the kernel. On systemd systems, the kernel executes systemd as PID 1 (the first user-space process).

systemd then begins its job of starting the system: it reads its configuration files (unit files), analyzes dependencies between services, and starts services in the correct order. Unlike old SysV init with sequential startup, systemd starts many services in parallel where dependencies allow, significantly speeding up boot time.

systemd doesn't just start services—it owns the entire user-space environment: it manages mounting filesystems (including /proc, /sys, /dev), configures hostname and locale, sets up D-Bus for inter-process communication, and eventually starts the login prompt or graphical display manager.

Secure Boot is a UEFI feature that establishes a chain of trust from hardware to bootloader to kernel. During boot, each component's signature is verified before execution:

First, the UEFI firmware contains built-in trusted keys (DB). When the system boots, it verifies the bootloader's signature against these keys. If valid, the bootloader runs. The bootloader then verifies the kernel's signature, and optionally, the kernel verifies kernel module signatures. Only signed code from trusted vendors executes.

For Linux users, this means: pre-built kernels from major distributions work out of the box (they're signed). Custom kernels or third-party drivers need to be signed with a key enrolled in the system's trusted database. This prevents bootkits and rootkits from installing before the OS, significantly improving security—but requires additional steps for custom configurations.

Most production Linux kernels are compressed (gzip, LZMA, or zstd) to reduce size. After GRUB loads the kernel into memory, the kernel header specifies the decompression entry point. The decompressor runs in real mode initially, sets up a minimal page table, decompresses the kernel into its final location in memory, then jumps to the kernel's actual entry point.

During decompression, the kernel relocates itself (if needed), parses boot parameters from the command line, and prepares the early pagetable. If the kernel was built with CONFIG_RANDOMIZE_BASE, ASLR is applied even at this early stage. The decompression console output ("Loading Linux kernel...") is often visible during boot.

GRUB 2 locates initramfs via the initrd kernel parameter specified in GRUB config (/boot/grub/grub.cfg). GRUB reads the initramfs cpio archive into memory and passes the memory address and size to the kernel via the boot parameters. The kernel stores this address and uses it during the early userspace handoff.

Modern kernels also support initramfs as an embedded cpio archive compiled into the kernel image (via CONFIG_INITRAMFS_SOURCE). In this case, no external file is needed—the initramfs is part of the kernel image itself.

pivot_root() is the syscall that changes the root filesystem. During boot, the kernel initially mounts the initramfs as the root filesystem. Initramfs's /init script (or the kernel's internal initramfs code) performs the critical setup: locating the real root filesystem, mounting it, then calling pivot_root() to make it the new root. The old root (initramfs) is unmounted and its memory freed.

This "pivot root" technique solves the chicken-and-egg problem: the kernel needs the root filesystem mounted to use it, but the root filesystem might need kernel drivers (LUKS, LVM, RAID) that require an initramfs to load first.

UEFI Runtime Services are a set of services provided by the firmware that persist even after an OS boots—_GetVariable(), SetVariable(), QueryVariableInfo(), etc. They allow the OS to read/write UEFI variables stored in NVRAM (like boot order, Secure Boot keys, and platform diagnostics). The kernel maps these services into a known virtual address via SetVirtualAddressMap().

After the kernel takes over, these services are still callable from kernel context via the efivarfs filesystem (mounted at /sys/firmware/efi/efivars). This is how tools like efibootmgr and mokutil modify boot settings—via efivarfs which wraps the UEFI runtime service calls.

Measured boot uses the TPM (Trusted Platform Module) to record cryptographic measurements of each boot component. Before executing each component (UEFI firmware → bootloader → kernel → initramfs), its measurement is extended into a TPM Platform Configuration Register (PCR). PCR extension is additive: new_PCR = SHA(old_PCR || new_measurement).

The resulting PCR values cannot be altered without detection—if any component is tampered with, its measurement differs, producing a different PCR value. Remote attestation protocols can query these PCRs and prove to a remote party what code was booted. This enables "measured boot" attestation: proving your system booted an approved chain of software.

emergency.target starts a minimal shell on the main console as soon as possible—it mounts the root filesystem read-only and starts minimal debugging. No other services run. It's the most minimal rescue mode.

rescue.target is more complete: it mounts the root filesystem read-write, starts system logger, configures the hostname and locale, and brings up the network. It then runs a shell on tty1. rescue.target is appropriate when you need the filesystem mounted and some services running to troubleshoot—but without the normal multi-user service stack.

dracut is the tool that builds the initramfs image on Red Hat-based systems (Fedora, RHEL, CentOS). It analyzes the kernel modules and dependencies needed to boot the system, includes those modules in a cpio archive, and adds the shell scripts for the boot process. Unlike older mkinitrd, dracut is hardware-agnostic and generates a minimal-but-complete initramfs.

The relationship: dracut produces the initramfs; the initramfs uses dracut-generated scripts to locate the real root, load necessary drivers (LUKS, LVM, network), and hand off to the real root filesystem. Regenerating initramfs (dracut -f) is necessary after kernel updates or driver changes.

Secure Boot establishes a chain of trust via cryptographic signature verification. Each component measured before execution: UEFI verifies the bootloader's signature against keys in the UEFI database (db). If the bootloader is signed by a trusted key, it loads. The bootloader then verifies the kernel's signature before transfer. The kernel optionally verifies kernel modules.

A rootkit that replaces the bootloader would have an invalid signature—UEFI refuses to execute it. This prevents pre-OS rootkits that modified the bootloader to hide themselves. However, Secure Boot only verifies signers; a compromised key enrolled in the trusted database bypasses the protection.

The EFI System Partition is a dedicated FAT32 partition (type GUID: C12A7328-F81F-11D2-BA4B-00A0C93EC93B) on a GPT disk. UEFI firmware reads bootloaders from this partition—bootloaders live as files under /EFI/vendor/. UEFI boot managers also store boot entries (pointers to these files) in NVRAM.

The ESP can also store EFI variables (when efivarfs isn't mounted), firmware update capsules, and diagnostic tools. It uses FAT32 for maximum compatibility across UEFI implementations. Some systems use a separate "MDT" partition for tool extensions, but the standard ESP is a single FAT32 partition.

PID 1 is the first user-space process the kernel starts after initialization. In traditional SysV init, this is the init binary. In systemd, it's the systemd binary. PID 1 is special because it inherits orphaned processes (if a parent dies, its children are reparented to PID 1) and receives signals that would otherwise kill the system (e.g., SIGTERM for graceful shutdown).

The kernel waits for PID 1 to exec the specified userspace program before considered "booted." If PID 1 dies, the kernel panics (cannot proceed without an init process). PID 1 also manages service lifecycle, mount propagation (shared mounts become slave), and is the ancestor of all subsequent processes.

systemd-analyze blame prints a list of units sorted by how long they took to activate during the most recent boot. This reveals which services are the slowest to start. For example, if network-online.target takes 8 seconds, you know the network configuration or DHCP is slow. The output shows the accumulated time spent in each unit's activation.

Use it with systemd-analyze critical-chain to see the critical path (the longest chain of dependent units)—optimizing units on the critical path has the most impact on total boot time.

Loading at boot time (via /etc/modules or module configuration in initramfs): modules load during the initramfs phase or early boot, before the filesystem is fully available. This is necessary for modules required to mount the root filesystem (storage controllers, filesystem drivers, encryption). The order is critical.

Loading after boot (via modprobe or insmod): the system is fully operational, so module dependencies can be resolved from /lib/modules/$(uname -r)/modules.dep, and user-space is available for error handling. modprobe also handles module arguments via /etc/modprobe.d/ configuration files.

/run is a tmpfs filesystem mounted early in boot (by systemd or init scripts) to hold runtime data that does not need to persist across boots—PID files, socket files, transient application state. It replaces the older /var/run symlink and /var/lock symlink patterns.

The key difference: /var may reside on the persistent root filesystem, which may not be mounted yet during early boot. /run is a RAM-based tmpfs, so it is available immediately after the early boot mount manager starts. Services needing runtime files during early boot use /run, not /var.

This error occurs when the kernel's early userspace (/init or the shell from initramfs) cannot open /dev/console for standard input. The kernel passes console= boot parameters to set the console device, but if that device node doesn't exist in initramfs, the open fails.

Resolution: rebuild initramfs with the correct device nodes (udev or mdev populates /dev), or pass a console= device that exists in the initramfs. In dracut-based systems, dracut --force --add udev ensures udev runs early enough to create /dev/console.

In PXE boot, the firmware broadcasts a DHCP request with PXE options. The DHCP server returns boot server address and filename (the bootloader). The firmware downloads the bootloader via TFTP and executes it. GRUB (compiled as a PXE GRUB binary) then uses its own config or a network path to locate the kernel and initramfs via TFTP/HTTP, passes kernel parameters (including ip=dhcp), and boots.

The initramfs must include network drivers to bring up the network after boot. The PXE boot flow bypasses local storage entirely—the entire boot chain (bootloader, kernel, initramfs) comes from the network. This is standard in diskless workstations, cloud instances (where metadata comes via DHCP/PXE), and enterprise provisioning systems.