The UEFI-based booting sequence – Exploring the Various Boot Options and Kernels in Oracle Linux

The UEFI-based booting sequence

The following sequence order is used by UEFI-based booting hardware:

1. The system first performs a power-on self-test (POST), which identifies the system’s configuration and all possible boot identifiers.
2. UEFI searches for a GUID Partition Table (GPT) partition with a specific Globally Unique Identifier (GUID) that identifies it as the EFI System Partition (ESP), containing Extensible Firmware Interface (EFI) applications such as booters. If there are multiple boot devices, the UEFI boot manager determines the appropriate ESP based on the order defined in the boot manager. With the efibootmgr tool, you can specify a different order if you do not use the default definition.
3. The UEFI boot manager checks whether Secure Boot is enabled. If Secure Boot is not enabled, the boot manager runs the GRUB 2 boot loader on the ESP. Otherwise, the boot manager requests a certificate from the boot loader and validates this against keys stored in the UEFI Secure Boot key database. The environment is configured to perform a two-stage boot process, and the shim to handle the certificate validation process.efi application that is responsible for the certification is loaded first before loading the GRUB 2 boot loader. If the certificate is valid, the boot loader runs and, in turn, validates the kernel that it is configured to load.
   The boot loader first loads the vmlinuz kernel image into memory and then creates a temporary RAM-based filesystem called tmpfs. This is then used to extract the contents of the initramfs image file. vmlinuz is the name of the bootable compressed Linux kernel executable. The root filesystem embedded into the Linux kernel and loaded early in the boot process is called initramfs.
4. Driver modules are then loaded from the initramfs filesystem. These are needed to allow the kernel to access the root filesystem.
5. The system then starts with the first process, systemd. All future processes spawn from this process. The systemd process will always have a process ID of 1.
6. The systemd process will run any additional processes defined for it. You can specify any other actions to be processed during the boot process by defining your systemd unit. This method is advised to be used instead of the /etc/rc. local file approach.

The legacy BIOS sequence
Legacy BIOS booting hardware uses the following sequence order:

1. The system first performs a POST, which identifies the configuration of the system, tests memory, and identifies all possible boot devices.
2. Once the BIOS has identified the boot device, it reads the first sector of the device, which is the Master Boot Record (MBR). The MBR contains the boot loader, which is a small program that is responsible for loading the operating system. The MBR reads the partition table, to determine the boot partition. Additionally, the MBR includes the pointer to the boot loader program called GRUB 2. GRUB can then run a boot on the same device that GRUB is installed on or a separate device. This is helpful when multi-booting the same system with both Linux and Windows.
3. The boot loader first loads the vmlinuz kernel image into memory and then creates a temporary RAM-based filesystem called tmpfs. This is then used to extract the contents of the initramfs image file. vmlinuz is the name of the bootable compressed Linux kernel executable. The root filesystem embedded in the Linux kernel and loaded early in the boot process is called initramfs.
4. Driver modules are then loaded from the initramfs filesystem. These modules are needed to allow the kernel to access the root filesystem.
5. The kernel then starts the systemd process.
6. The systemd process runs any other processes defined for it. You can specify any additional actions to be processed during the boot process by defining your systemd unit. This method is recommended instead of the /etc/rc. local file approach.