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.

Paths and Their Roles

1. /usr/lib/systemd/
   1. 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
2. /etc/systemd/
   1. 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.
3. /run/systemd/
   1. 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.

systemctl Commands

• systemctl status [unit]: Displays the current state of a service, including active/inactive status, recent logs, and dependencies. For example, systemctl status apache2 reveals if the web server is running, its uptime, and error messages.

• systemctl list-units: Lists all loaded units (services, mounts, devices). Adding --type=service --state=failed filters to show only failed services, aiding quick diagnostics.

• systemctl start/stop [unit]: Directly controls service execution. For instance, systemctl stop mysql halts the database, while systemctl start nginx activates the web server.

• systemctl enable/disable [unit]: Configures autostart behavior. enable creates symlinks in /etc/systemd/system/[target].wants/, ensuring the service starts at boot. Conversely, disable removes these links.

• systemctl mask/unmask [unit]: Prevents accidental activation. Masking (e.g., systemctl mask bluetooth) links the service to /dev/null, blocking all start attempts. Unmasking restores the original configuration.

systemd-delta: Managing Configuration Overrides

This tool identifies conflicts between unit file layers (e.g., /usr/lib/ vs. /etc/). Running systemd-delta highlights modified files, showing where administrators have overridden defaults. For example, if you’ve customized nginx.service in /etc/, it flags this as an "overridden" unit, ensuring transparency in configuration management.

Workflow Example: Customizing a Service

To increase the file handle limit for Nginx:

1. Create an override:

sudo mkdir -p /etc/systemd/system/nginx.service.d/  
echo -e '[Service]\nLimitNOFILE=65536' | sudo tee /etc/systemd/system/nginx.service.d/override.conf  

1. Reload systemd:

   sudo systemctl daemon-reload

   to apply changes.
2. Restart Nginx:

   sudo systemctl restart nginx

This ensures Nginx can handle more concurrent connections without altering the original package file in /usr/lib/systemd/.