About UEFI-Based Booting

On a UEFI-based system running the Oracle Linux release, the system boot process uses the following sequence:

  1. When the system is powered on, the system performs a power-on self-test (POST) to detect and check the system's core hardware components such as CPU and memory. The UEFI firmware is then initialized.

  2. The UEFI firmware detects any other hardware, such as peripheral components including network devices and storage. The UEFI firmware contains its own boot manager, which can directly interact with boot loaders on various storage devices. The boot manager stores a set of variables including the priority of different boot devices and any detected boot loaders.

    UEFI searches for a FAT32 formatted GPT partition with a specific globally unique identifier (GUID) that identifies it as the EFI System Partition (ESP). This partition contains EFI applications such as boot loaders and other configuration files.

    When more than one boot device is present, the UEFI boot manager uses the appropriate ESP based on the order that's defined in the boot manager. With the efibootmgr tool, you can define a different order, if you don't want to use the default definition.

  3. The UEFI boot manager loads the default boot loader. Oracle Linux uses a 2-stage boot process to handle the Secure Boot validation process. The 2-stage process includes a first stage boot loader called the shim boot loader on the ESP, and the second stage boot loader called GRUB 2. If Secure Boot is disabled, the shim boot loader directly loads the GRUB 2 boot loader on the ESP, to continue the boot process. Boot loader files are named according to the system architecture, for example the shim bootloader is named shimx64.efi on x86_64 systems, and shimaa64.efi on aarch64 systems.

    Otherwise, if Secure Boot is enabled, the shim boot loader is validated against keys stored in the UEFI Secure Boot key database, and in turn, verifies the GRUB 2 boot loader signature against certificates stored in the UEFI Secure Boot key database or the Machine Owner Key (MOK) database. If the GRUB 2 signature is valid, the GRUB 2 boot loader runs and, in turn, validates the kernel that it's configured to load.

    See Oracle Linux: Working With UEFI Secure Boot for more information on Secure Boot.

  4. The boot loader loads the vmlinuz kernel image file and the initramfs image file into memory. The kernel extracts the contents of the initramfs image into a temporary, memory-based file system (tmpfs). The initramfs contains essential drivers and utilities needed for booting.

  5. The boot loader passes control to the kernel and provides pointers to the initramfs and any other boot parameters. The kernel continues system initialization, detecting hardware, loading necessary drivers, and mounting the root file system.

  6. The kernel searches for the init process within initramfs and starts the defined process with a process ID of 1 (PID 1). On Oracle Linux, the default init process is configured as systemd. See Oracle Linux 8: Managing the System With systemd for more information.

  7. systemd runs any other processes defined for it.

    Note:

    Specify any other actions to be processed during the boot process by defining systemd units. This method is preferred to using the /etc/rc.local file.