---
title: Linux Boot Process
tags: Unlocking-Linux, SystemD
disqus: hackmd
---

# Linux Boot Process
The process of booting up a Linux kernel can be view as 6 separate stages
- BIOS selects the boot device.
- GRUB loader
- Kernel decompression
- Low-level initialization by init

### Lets look at each of the stages, and see what they do

1. **Bios Selects Boot Device**
On startup, power is sent to the CPU and it starts executing instructions. The first instruction it runs passes control to the BIOS (Basic Input/Output System). The BIOS then does two things:
* Run POST (Power On Self Test) operation.
* Selecting first Boot device.

<br>

POST operation
- The POST operation checks for hardware availability by sending electrical pulses to the devices. If no electrical pulses are sent back, it means the device is faulty or does not exists. These activities are outside the scope of Linux, as the Kernel is not even loaded in yet until later

<br>

Selecting the First Boot Device
- After running POST is completed, the BIOS will have a list of available devices. It will select the first boot device and returns control to the CPU. If the first boot device cannot be found, it will continue to look for the next available boot device. If BIOS do not find any available boot devices it will alert user stating "No boot device found"

<br>

2. **Bios Loads Boot Sector from the Boot Device**
One the boot device has been identified, the BIOS passes control back to the CPU. The CPU will then read the first 512 bytes of the boot device to obtain the Master Boot Recorder (MBR). The MBR consists of the following information
- Primary boot loader code / Stage 1 Boot loader (446 Bytes)
- Partition table information (64 Bytes)
- Magic Number (2 Bytes)

<br>

Primary Boot Loader Code
- This code provides information regarding the actual boot loader on the hard disk. It is used to load the actual boot loader

<br>

Partition Table Information
- This information here stores the details of all the partitions in the hard disk. It includes information such as the start and end of the partition, and what type of partition it is. Each partition needs 16 Bytes to be represented.
Since the Partition Table Information section is only 64 Bytes long, we can store at most 64/16=4 partitions on a hard disk

<br>

Magic Number
- This number is use for validating the MBR. It is used to recover the MBR when it gets corrupted.

<br>

3. **GRUB Loader / Stage 2 boot Loader**
If the CPU has a valid boot device, which has a valid MBR that contains the Primary boot loader code / Stage 1 Boot loader, we proceed to load the Stage 2 Boot loader, or the GRUB (Grand Unified Bootloader) into memory. The GRUB is located 30 KB away from the MBR and before the first partition.

The GRUB displays the available Kernels to the user. Once the user selects a kernel, the kernel image is then loaded into memory and control is passed to the kernel.

Nowadays GRUB2 is being used in place of GRUB. GRUB2 is the default boot loader for RHEL 7, Fedora, and Ubuntu. To read more about GRUB2

<br>

4. **Kernel Decompression**
The kernel is a compressed image, and it is store in /boot along with an initial RAM disk image, and device maps of the hard drives.

Once the kernel is loaded into the main memory, it begins decompression. After decompression, the expanded image overwrite the initial uncompressed image. Once the kernel has extracted itself, it loads systemd, which is the replacement for the old SysV init program, and turns control over to it.

At this point, the Linux kernel and systemd (or in some systems, init) are running

<br>

5. **Low-level initialization (init, Upstart and Systemd)**
Once the kernel has been decompressed, it begins the init function, which is the low level initialization of the kernel. The kernel looks at the /etc/inittab file and decides the run level. It also looks into the folder /etc/rc* and runs the startup scripts there. The files for init are stored in /etc/init

init is a daemon process which starts as soon as the computer starts and continues running till it is shutdown. init has a pid of 1. If somehow the init daemon could not start, no process will be started and the system will enter Kernel Panic.

init is going to be replaced by systemd in the future, as systemd offers a cleaner way of booting. Ubuntu used to adopt upstart as their initialization, but switched to systemd as of 9 March 2015.

### More on Grub2
The main changes of GRUB2 from GRUB are as follows:

1. GRUB2 directly shows a login prompt and no menu is displayed.
2. If you want to see the menu during boot, hold down SHIFT key or press ESC
3. The configuration file is /boot/grub/grub.cfg. This main configuration file contains different types of scripts we cannot edit this file directly. grub.cfg is generated from the contents of the /etc/default/grub and /etc/grub.d . You should modify or add to those files to configure GRUB 2
4. There is no file called /boot/grub/menu.lst
5. Users can create custom files to place their own menu entries via 40_custom in /etc/grub.d folder.
6. Users can change the menu display settings through a file called grub in /etc/default folder.
7. The numbering of partitioning has changed. The first partition is now 1 instead of 0. The first device is still identified with hd0

There are 3 stages to the GRUB2 process:
* boot.img is stored in the master boot record (MBR) or in the Volume Boot Records (VBR). At installation time it is configured to load the first sector of core.img:
* Also known as stage 1.5.core.img is by default written to the sectors between the MBR and the first partition, when these sectors are free and available. Once executed, core.img will load its configuration file and any other modules and file systems needed, at installation time, it is generated from diskboot.img and configured to load stage 2 by its file path
* Also known as stage 2. Files belonging to the stage 2 are all being held in the /boot/grub

Once GRUB2 stage 2 has loaded, it presents a kernel selection menu for the user to select which operating system to boot. GRUB2 can be configured to automatically load a specified kernel after a user-defined timeout

Once boot options have been selected, GRUB2 loads the selected kernel into memory and passes control to the kernel. Alternatively, GRUB2 can pass control of the boot process to another boot loader, using chain loading.