Skip to main content

LFCS Certification Course

Chapter #7: Understanding Linux Boot and Startup Services

In this chapter, we take you on a deep dive into the Linux startup process, covering POST, bootloaders, kernel initialization, runlevels, targets, and logging with journalctl

The boot process of a Linux system consists of several phases, each represented by a different component.

In this chapter, we will share an overall description of each one of them.

The Boot Process

The following diagram briefly summarizes the boot process and shows all the main components involved:

Linux Boot Process

Step 1: Power-On and POST

When you press the Power button on your machine, the firmware that is stored in an EEPROM chip in the motherboard initializes the POST (Power-On Self Test) to check the state of the system’s hardware resources to ensure everything is functioning properly.

Step 2: Locate and Load Bootloader

After POST completes, the firmware looks for the 1st stage bootloader, located in the MBR (Master Boot Record) or the EFI partition of the first available disk. Once found, it hands over control to this bootloader.

Understanding the MBR (Master Boot Record)

The MBR is located in the first sector of the bootable disk (as set in BIOS). It is exactly 512 bytes in size and is divided into three main parts:

  • First 446 bytes: The bootloader code contains executable instructions and error messages.
  • Next 64 bytes: The partition table holds records for up to four partitions (primary or extended), including details like:
    • Partition status (active/inactive)
    • Size and start/end sectors
  • Last 2 bytes: The magic number used to verify the validity of the MBR.

Backing Up the MBR

The following command performs a backup of the MBR (in this example, /dev/sda is the first hard disk). The resulting file, mbr.bkp can come in handy when the partition table becomes corrupt.

For example, rendering the system unbootable. Of course, in order to use it later if the need arises, we will need to save it and store it somewhere else (like a USB drive, for example).

That file will help us restore the MBR and will get us going once again if and only if we do not change the hard drive layout in the meantime.

sudo dd if=/dev/sda of=mbr.bkp bs=512 count=1
Backing Up the MBR

And restore it with:

dd if=mbr.bkp of=/dev/sda bs=512 count=1
Restoring the MBR

Step 3: EFI/UEFI-Based Boot Process

For systems using the EFI/UEFI method, the UEFI firmware reads its configuration to determine which UEFI application to launch and from where, specifically, which disk and partition contains the EFI System Partition (ESP).

πŸ’‘
Modern UEFI systems support Secure Boot and can directly launch a Linux kernel with EFI stub support (CONFIG_EFI_STUB=y), bypassing GRUB entirely if the kernel resides in the EFI System Partition. This reduces boot time and complexity in minimal setups.

Once the appropriate UEFI application is located, the second-stage bootloader, also known as the boot manager, is launched.

In most Linux systems, this is typically GRUB (GRand Unified Bootloader). There are two main versions:

  • GRUB Legacy
    • Config file: /boot/grub/menu.lst
    • Found on older distributions
    • Not compatible with EFI/UEFI systems
  • GRUB2 (Modern standard)
    • Main config file: /etc/default/grub
    • Compatible with both BIOS and UEFI systems
πŸ’‘
On UEFI-based systems, GRUB2 typically stores additional config files in /boot/efi/EFI/<distro> and /boot/grub/grub.cfg.

Although the objectives of the LFCS exam do not explicitly request knowledge about GRUB internals, if you’re brave and can afford to mess up your system (you may want to try it first on a virtual machine, just in case), you need to run.

sudo update-grub

as root after modifying GRUB’s configuration in order to apply the changes.

Basically, GRUB loads the default kernel and the initrd or initramfs image. In a few words, initrd or initramfs help to perform the hardware detection, the kernel module loading, and the device discovery necessary to get the real root filesystem mounted.

πŸ’‘
Most modern Linux distributions use dracut, mkinitcpio, or initramfs-tools to generate the initramfs image. These tools only include essential drivers and files, reducing init time and improving modularity.

Once the real root filesystem is up, the kernel executes the system and service manager (init or systemd, whose process identification or PID is always 1) to begin the normal user-space boot process in order to present a user interface.

Both init and systemd are daemons (background processes) that manage other daemons, as the first service to start (during boot) and the last service to terminate (during shutdown).

PID 1: The First and Last Daemon

Starting Services in Linux

The concept of runlevels in Linux specifies different ways to use a system by controlling which services are running.