Linuc
2.01: System Boot and Linux Kernel
BIOS and UEFI Fundamentals
The BIOS (Basic Input/Output System) and UEFI (Unified Extensible Firmware Interface) are firmware interfaces responsible for initializing hardware during system startup and loading the operating system. BIOS, the older standard, relies on the Master Boot Record (MBR) partitioning scheme, which supports up to four primary partitions and boot drives up to 2.2 TB. In contrast, UEFI uses the GUID Partition Table (GPT), allowing up to 128 partitions and boot drives exceeding 9 zettabytes. UEFI also introduces the EFI System Partition (ESP), a FAT-formatted partition storing bootloaders, kernel images, and UEFI applications like efibootmgr. The ESP is critical for UEFI systems, as it hosts the grubx64.efi bootloader and enables Secure Boot to verify firmware integrity.
Boot Loader Configuration and Shell Usage
Modifying boot options varies by firmware type. In UEFI systems, efibootmgr manages boot entries, allowing users to adjust boot order, set active/inactive entries, and create new boot options via commands like efibootmgr -o 0001,0002. For Windows, bcdedit /default {GUID} changes the default OS entry. In BIOS-based systems, GRUB’s command-line interface provides direct control using commands such as kernel /vmlinuz root=/dev/sda1 to specify the kernel and initrd /initramfs.img to load the initial RAM disk. GRUB’s shell also supports disk exploration with ls (hd0,1)/ and boot troubleshooting via grub-install.
GRUB Boot Menu Generation
The GRUB boot menu is regenerated using grub2-mkconfig, which synthesizes configuration files from /etc/default/grub and scripts in /etc/grub.d/. Customizations like timeout adjustments or theme changes are added to /etc/default/grub, and executing grub2-mkconfig -o /boot/grub2/grub.cfg applies these changes. For UEFI systems, the configuration resides in /boot/efi/EFI/[distro]/grub.cfg, while BIOS systems use /boot/grub2/grub.cfg.
Kernel Module Loading with initrd/initramfs
The initrd (initial RAM disk) or initramfs (initial RAM filesystem) preloads essential kernel modules and drivers before the root filesystem is mounted. Modules like storage controllers or filesystem drivers are included by editing /etc/initramfs-tools/modules and rebuilding with update-initramfs -u. For example, adding netconsole to initrd involves creating a hook script in /etc/initramfs-tools/hooks/ to ensure the module is included during initramfs generation.
Hardware Initialization and Filesystem Mounting
During boot, the kernel initializes hardware via udev, which dynamically loads kernel modules based on detected devices. After module loading, the kernel mounts the root filesystem specified by the root= parameter in the bootloader. If the root filesystem is encrypted or on a RAID array, initrd handles decryption or assembly before passing control to the OS.
Service Initialization with systemd
Post-filesystem mount, systemd initializes services defined in systemd.unit files. The default target (e.g., multi-user.target or graphical.target) is set using systemctl set-default, while systemctl enable [service] configures services to start at boot. Systemd also manages dependencies, ensuring services like networking or logging start in the correct order.
Boot Loader Installation and Filesystem Structure
The grub-install or grub2-install command installs GRUB to the MBR (for BIOS) or ESP (for UEFI). Key directories include:
- /boot/: Contains the kernel (vmlinuz) and initramfs.
- /boot/grub2/: Stores GRUB configuration files (e.g., grub.cfg) on BIOS systems.
- /boot/efi/: Houses UEFI bootloaders and the ESP partition contents.
For UEFI installations, grub-install copies the grubx64.efi bootloader to /boot/efi/EFI/[distro]/, ensuring compatibility with firmware expectations.
What is Systemd?
Systemd is a modern system and service manager for Linux, designed to replace traditional init systems like SysV. As the first process started during boot (PID 1), it initializes hardware, mounts filesystems, and manages services through unit files-configuration files defining resources like services, sockets, and targets. Unlike SysV, systemd enables parallel service startup, reducing boot times, and integrates logging via journalctl for troubleshooting.
Key Paths and Their Roles
- /usr/lib/systemd/
- This directory stores default unit files provided by installed packages (e.g., nginx.service, sshd.socket). These files are managed by the system and should not be modified directly. For example, the sshd.service unit here defines how the SSH daemon starts, including dependencies and environment variables
- /etc/systemd/
- Administrators place custom unit files and overrides here. When you modify a service (e.g., adding Restart=always to ensure a service auto-recovery), create a subdirectory like /etc/systemd/system/nginx.service.d/override.conf. These configurations take precedence over /usr/lib/systemd/, allowing tailored behavior without altering package defaults.
- /run/systemd/
- Runtime configurations reside here, generated dynamically during system operation. For instance, temporary service states or transient units (e.g., systemd-tmpfiles-clean.service) are stored here and cleared on reboot. This directory reflects the current system state, unlike /etc/ or /usr/lib/, which persist across reboots.
