boot overview

The booting process in Linux consists of 4 different phases:

1- BIOS / UEFI phase

2- MBR / GPT -> GRUB2 phase

3- Kernel phase

4- systemd initialisation phase

The BIOS/UEFI firmware kicks-in as soon as the motherboard gets power and it performs a POST (power-on-self-test) to detect, test and initialise the hardware components (CPU, memory, storage, PCI, USB, etc). In this stage we can configure the preferred booting order of storage devices (CD/DVD, disk1, disk2, USB, network, etc) among other settings in the BIOS menu.

Once the POST is completed, the BIOS/UEFI will scan the first sector (512 bytes) of each storage device (in the order of preference specified in the BIOS) looking for the boot loader program called GRUB2. This first sector uses 446 bytes for the boot loader program (GRUB2) plus 64 bytes for the partition table (MBR/GPT) plus a 2 byte signature at the end.

 

For a more in-depth study on boot loaders and MBRs are good starting point is:

https://en.wikipedia.org/wiki/Master_boot_record

Sectors 1 up to 2047 are usually reserved for the 2nd stage boot loader (a.k.a. “grub 1.5”) and the GUID partition tables used in EFI systems. Therefore, the first disk partition (/boot or /boot/efi) should always start at sector 2048.

GRUB2 tracks all the bootable kernels with their options and locations (we shall look at GRUB2 in detail a bit further down). When the kernel to boot is chosen (manually or automatically), GRUB2 loads it and gives it control.

The first thing the kernel does is to decompress, extract and load the initial RAM disk image (initrd) from the boot filesystem. This image is mounted read-only as a temporary root filesystem to allow a fully functional kernel in case the actual root filesystem “/” could not be mounted or encountered any problems. As soon as all the required kernel modules and drivers are loaded, the real root filesystem is mounted read-write, the initrd pseudo-filesystem is unmounted and the initialisation phase starts.

The initialisation was performed by the traditional System V init process in RHEL5 and previous versions. In RHEL6 it was replaced by Upstart. And RHEL7 has adopted the widely used systemd.

The system daemon or systemd offers substantial improvements over previous initialisation processes such as:

– Faster initialisation through parallelisation on independent services.

– Management of dependencies between services.

– On-demand activation of service daemons using sockets and D-bus.

– Snapshooting of system states.

<< Boot process             grub2 >>