LINUX BOOT PROCESS

Linux booting process

Step 1: Power Supply & SMPS
==========================


* SMPS convert AC to DC . Convert High or Low voltage to perfect voltage
and inform this power good signal to Motherboard

* On receiveing this power good signal, Mother stops sending reset signal
to CPU, which means the power level is good and computer can boot


Step 2: Bootstrapping
=====================

* Something has to be programmed so that the CPU knows where to search for
instruction

* This is an address location in last region of ROM (FFFF:0000h) and it
contains JUMP instruction.

* JUMP command is to jump in to another memory address location where the
bios program is located.

Step 3: The Role of BIOS in booting process
===========================================

* The computer know how to bring itself up, when you press star button,because of the instruction that are fed to BIOS( basic input output system) it performs its most important function POST (Power on self test)

* POST conduct series of test to check the integrity and functioning of hardware

Timer IC's DMA controllers CPU Video ROM

A full POST check will confirm the integrity of the following devices as well.Motherboard Keyboard Printer port Hard Drive etc

* warm start (reset) may not conduct full POST.

* The errors of H/W failures informed by beep codes.

* CMOS & BIOS are two completely different things in the computermotherboard. CMOS is a small memory RAM chip that's present in themotherboard. This RAM is different from the computers main RAM chip (whichare replaceable memory chips.

Removing a CMOS battery will make the CMOS to forget all the configuration you have saved previously.    

* This is the reason you can unlock a computer that's protected with a CMOS password, by simply removing the CMOS battery.  

 * Also removing the CMOS battery will make the operating system to show you wrong time. Because system time consistency is maintained in CMOS   settings.

* CMOS settings are changed to select the boot priority

⁠F.2.1.1. BIOS-based x86 Systems

The Basic Input/Output System (BIOS) is a firmware interface that controls not only the first step of the boot process, but also provides the lowest level interface to peripheral devices. On x86 systems equipped with BIOS, the program is written into read-only, permanent memory and is always available for use. When the system boots, the processor looks at the end of system memory for the BIOS program, and runs it.

Once loaded, the BIOS tests the system, looks for and checks peripherals, and then locates a valid device with which to boot the system. Usually, it checks any optical drives or USB storage devices present for bootable media, then, failing that, looks to the system's hard drives. In most cases, the order of the drives searched while booting is controlled with a setting in the BIOS, and it looks on the master IDE on the primary IDE bus or for a SATA device with a boot flag set. The BIOS then loads into memory whatever program is residing in the first sector of this device, called the Master Boot Record (MBR). The MBR is only 512 bytes in size and contains machine code instructions for booting the machine, called a boot loader, along with the partition table. Once the BIOS finds and loads the boot loader program into memory, it yields control of the boot process to it.

This first-stage boot loader is a small machine code binary on the MBR. Its sole job is to locate the second stage boot loader (GRUB) and load the first part of it into memory.

⁠F.2.1.2. UEFI-based x86 Systems

The Unified Extensible Firmware Interface (UEFI) is designed, like BIOS, to control the boot process (through boot services) and to provide an interface between system firmware and an operating system (through runtime services). Unlike BIOS, it features its own architecture, independent of the CPU, and its own device drivers. UEFI can mount partitions and read certain file systems.

When an x86 computer equipped with UEFI boots, the interface searches the system storage for a partition labeled with a specific globally unique identifier (GUID) that marks it as the EFI System Partition (ESP). This partition contains applications compiled for the EFI architecture, which might include bootloaders for operating systems and utility software. UEFI systems include an EFI boot manager that can boot the system from a default configuration, or prompt a user to choose an operating system to boot. When a bootloader is selected, manually or automatically, UEFI reads it into memory and yields control of the boot process to it.

Step 4: MBR and GRUB
====================

* BIOS is programmed to look at a permanent location on the hard disk to
complete its task and it checks the first sector( MBR)

[root@vz015 ~]# dd if=/dev/sda of=mbr bs=512 count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.00740244 s, 69.2 kB/s
[root@vz015 ~]# file mbr
mbr: x86 boot sector; GRand Unified Bootloader, stage1 version 0x3, boot
drive 0x80, 1st sector stage2 0x86e2, GRUB version 0.94; partition 1:
ID=0x83, active, starthead 32, startsector 2048, 204800 sectors; partition
2: ID=0x83, starthead 223, startsector 206848, 201119744 sectors;
partition 3: ID=0x82, starthead 254, startsector 201326592, 4194304
sectors; partition 4: ID=0x5, starthead 254, startsector 205520896,
4194303 sectors, code offset 0x48

* Above, mbr is dumped in to a file. The flag active determines the active
partition which is partition 1 in tthis case

*  Only the first 440 bytes from the total of 512 bytes is used by the
first stage boot loader, the remaining part is used to store partition
table information.

* The fourth point is a Magic Number of 2 bytes. This magic number serves
as a method of verification for the MBR.

* The primary job of the stage 1 bootloader is to load the second stage
boot loader

⁠E.2.1. GRUB and the Boot Process on BIOS-based x86 Systems

This section describes the specific role GRUB plays when booting a BIOS-based x86 system. .

GRUB loads itself into memory in the following stages:

1. The Stage 1 or primary boot loader is read into memory by the BIOS from the MBR ⁠[16]. The primary boot loader exists on less than 512 bytes of disk space within the MBR and is capable of loading either the Stage 1.5 or Stage 2 boot loader.
   BIOS cannot read partition tables or file systems. It initializes the hardware, reads the MBR, then depends entirely on the stage 1 bootloader to continue the boot process.
2. The Stage 1.5 boot loader is read into memory by the Stage 1 boot loader, if necessary. Some hardware requires an intermediate step to get to the Stage 2 boot loader. This is sometimes true when the /boot/ partition is above the 1024 cylinder head of the hard drive or when using LBA mode. The Stage 1.5 boot loader is found either on the /boot/ partition or on a small part of the MBR and the /boot/ partition.
3. The Stage 2 or secondary boot loader is read into memory. The secondary boot loader displays the GRUB menu and command environment. This interface allows the user to select which kernel or operating system to boot, pass arguments to the kernel, or look at system parameters.
4. The secondary boot loader reads the operating system or kernel as well as the contents of /boot/sysroot/ into memory. Once GRUB determines which operating system or kernel to start, it loads it into memory and transfers control of the machine to that operating system.

The method used to boot Linux is called direct loading because the boot loader loads the operating system directly. There is no intermediary between the boot loader and the kernel.

The boot process used by other operating systems may differ. For example, the Microsoft Windows operating system, as well as other operating systems, are loaded using chain loading. Under this method, the MBR points to the first sector of the partition holding the operating system, where it finds the files necessary to actually boot that operating system.

GRUB supports both direct and chain loading boot methods, allowing it to boot almost any operating system.

⁠E.2.2. GRUB and the Boot Process on UEFI-based x86 Systems

This section describes the specific role GRUB plays when booting a UEFI-based x86 system. 

GRUB loads itself into memory in the following stages:

1. The UEFI-based platform reads the partition table on the system storage and mounts the EFI System Partition (ESP), a VFAT partition labeled with a particular globally unique identifier (GUID). The ESP contains EFI applications such as bootloaders and utility software, stored in directories specific to software vendors. Viewed from within the Red Hat Enterprise Linux 6.9 file system, the ESP is /boot/efi/, and EFI software provided by Red Hat is stored in /boot/efi/EFI/redhat/.
2. The /boot/efi/EFI/redhat/ directory contains grub.efi, a version of GRUB compiled for the EFI firmware architecture as an EFI application. In the simplest case, the EFI boot manager selects grub.efias the default bootloader and reads it into memory.
   If the ESP contains other EFI applications, the EFI boot manager might prompt you to select an application to run, rather than load grub.efi automatically.
3. GRUB determines which operating system or kernel to start, loads it into memory, and transfers control of the machine to that operating system.

Because each vendor maintains its own directory of applications in the ESP, chain loading is not normally necessary on UEFI-based systems. The EFI boot manager can load any of the operating system bootloaders that are present in the ESP.

GRUB stages

==========

1.GRUB Stage 1
2.GRUB Stage 1.5
3.Grub Stage 2
Grub Stage 1.5 located in the MBR GAP (sector 1 to 63 before the beginning
of the first partition) basically contains the drivers for reading file
systems. So grub stage 1 will load grub stage 1.5 to the RAM, and will
pass the control to it.
Now grub stage 1.5 will load the file system drivers and once the file
system drivers are loaded, it can now access /boot/grub/grub.conf file
which contains other details about kernel path and initrd path etc.
Now you need to have a lot of drivers and modules to access underlying
hardware and other stuff. For example, if you have RAID configured on your
/ partition how will you mount it without knowing the programs, or think
how will you include a kernal module or how to remove a kernel module. All
these things required different set of programs and code. Including all
these codes inside the kernel will make it a larger file image

– GRUB2 searches the compressed kernel image file also called as vmlinuz in the /boot directory.
– GRUB2 loads the vmlinuz kernel image file into memory and extracts the contents of the initramfs image file into a temporary, memory-based file system (tmpfs).
– The initial RAM disk (initrd) is an initial root file system that is mounted before the real root file system.

initramfs
– The job of the initial RAM file system is to preload the block device modules, such as for IDE, SCSI, or RAID, so that the root file system, on which those modules normally reside, can then be accessed and mounted.
– The initramfs is bound to the kernel and the kernel mounts this initramfs as part of a two-stage boot process.
– The dracut utility creates initramfs whenever a new kernel is installed.
– Use the lsinitrd command to view the contents of the image created by dracut:

# lsinitrd | less

5. Kernel

The kernel conducts a lot of hard ware specific operations and the first
user space program it executes is /sbin/init.


Run-Level       Usage
0       System Halt/Shut Down
1       Single User Mode
2       Multiuser Mode Without Networking
3       Full Multiuser Mode
4       Unused
5       GUI/X11
6       Reboot



[root@vz015 ~]# cat /etc/inittab | grep initdefault
#   0 - halt (Do NOT set initdefault to this)
#   6 - reboot (Do NOT set initdefault to this)
id:3:initdefault:

In RHEL 7

– The kernel starts the systemd process with a process ID of 1 (PID 1).

6. systemd

– systemd is the ancestor of all processes on a system.
– systemd reads the file linked by /etc/systemd/system/default.target (for example, /usr/lib/systemd/system/multi-user.target) to determine the default system target (equivalent to run level). The system target file defines the services that systemd starts.
systemd brings the system to the state defined by the system target, performing system initialization tasks such as:
1. Setting the host name
2. Initializing the network
3. Initializing SELinux based on its configuration
4. Printing a welcome banner
5. Initializing the system hardware based on kernel boot arguments
6. Mounting the file systems, including virtual file systems such as the /proc file system
7. Cleaning up directories in /var
8. Starting swapping