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:

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

And restore it with:
dd if=mbr.bkp of=/dev/sda bs=512 count=1

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).
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
- Config file:
- GRUB2 (Modern standard)
- Main config file:
/etc/default/grub
- Compatible with both BIOS and UEFI systems
- Main config file:
/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.
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).

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