The Basic Input/Output System (BIOS) is a firmware interface that controls the first step of the boot process and provides the lowest-level interface to external devices.

The BIOS checks the system and locates a bootable device with a Master Boot Record (MBR) partition to start the boot process. In Red Hat Enterprise Linux 8, the MBR boot loader use the GRand Unified Boot loader version 2 (GRUB2). The BIOS loads the boot loader that is stored in the MBR into memory. The boot loader then loads and passes control to the GRUB2 boot menu.

GRUB2 provides two options to boot from a disk on a BIOS system: Store the first part of the GRUB2 boot loader in the Master Boot Record (MBR) of a disk, or store it in the first sector of a partition that is marked as bootable.

The boot loader is the first program executed when the system starts. It finds, loads, and transfers control to an operating system. GRUB2 can boot any compatible operating system or transfer control to other boot loaders for unsupported operating systems.

For systems with an existing operating system, the anaconda installer attempts to automatically detect and configure the boot loader to start another operating system. If the boot loader is not detected, then you can manually configure additional operating systems after finishing the installation. Partition requirements vary, depending on whether a system is BIOS or UEFI. Modern systems may also require GPT partitioning, which handles larger disks and offers more flexible configuration than MBR partitioning while still supporting MBR boot loaders. If a user selects automatic partitioning in anaconda, then the installer creates the required partition type with sufficient MBR gap sizing.

GRUB 2 reads its configuration from the /boot/grub2/grub.cfg file on traditional BIOS-based machines and from the /boot/efi/EFI/redhat/grub.cfg file on UEFI-based machines.

The GRUB2 utilities stores files on a BIOS system in various locations:

Booting Red Hat Enterprise Linux 8 on a physical x86_64 system is a sequential set of tasks. For x86_64 virtual machines, the hypervisor handles some of the hardware-specific steps.

The Boot Loader Specification (BLS) manages boot loader configuration without manipulating boot loader configuration files, by defining a scheme and file format.

With BLS, each boot entry references a single configuration file in the drop-in directory. This drop-in architecture extends the configuration without needing to edit or regenerate the main boot loader configuration files.

BLS also uses this concept to configure boot menu entries. Manage the boot loader menu options by adding, removing, or editing individual boot entry files in the drop-in directory. BLS significantly simplifies the kernel installation process and is consistent across multiple architectures.

The grubby utility manipulates boot loader-specific configuration files. grubby works as a wrapper for the BLS operations. Use grubby for changing the default boot entry, and for adding or removing arguments in a GRUB2 menu entry.

If grubby is invoked manually without specifying a GRUB 2 configuration file, it defaults to locating grub2.cfg.

Obtain the file name of the default kernel with grubby:

[root@host ~]# grubby --default-kernel
/boot/vmlinuz-4.18.0-305.el8.x86_64

Find the index number of the default kernel:

[root@host ~]# grubby --default-index
0

Use the grubby command to persistently change the default kernel:

[root@host ~]# grubby --set-default /boot/vmlinuz-4.18.0-305.el8.x86_64
The default is /boot/loader/entries/ffffffffffffffffffffffffffffffff-4.18.0-305.el8.x86_64.conf with index 0 and kernel /boot/vmlinuz-4.18.0-305.el8.x86_64

List all the kernel menu entries:

[root@host ~]# grubby --info=ALL
index=0
kernel="/boot/vmlinuz-4.18.0-305.el8.x86_64"
args="ro no_timer_check net.ifnames=0 crashkernel=auto $tuned_params"
root="/dev/vda3"
initrd="/boot/initramfs-4.18.0-305.el8.x86_64.img $tuned_initrd"
title="Red Hat Enterprise Linux (4.18.0-305.el8.x86_64) 8.4 (Ootpa)"
id="ffffffffffffffffffffffffffffffff-4.18.0-305.el8.x86_64"

View the GRUB 2 menu entry for a specific kernel:

[root@host ~]# grubby --info /boot/vmlinuz-4.18.0-305.el8.x86_64
index=0
kernel="/boot/vmlinuz-4.18.0-305.el8.x86_64"
args="ro no_timer_check net.ifnames=0 crashkernel=auto $tuned_params"
root="/dev/vda3"
initrd="/boot/initramfs-4.18.0-305.el8.x86_64.img $tuned_initrd"
title="Red Hat Enterprise Linux (4.18.0-305.el8.x86_64) 8.4 (Ootpa)"
id="ffffffffffffffffffffffffffffffff-4.18.0-305.el8.x86_64"

If the MBR or the MBR gap is damaged, then reinstall GRUB2 into the MBR to overwrite it. If a system is not running when this issue occurs, the repair must be performed from within a Live CD or the rescue environment available from the anaconda installer. If a user with root permissions has access to a running system with this issue, the solution is to use the grub2-install command.

To handle any scenario, practice booting into a rescue environment to reinstall GRUB2 into the MBR:

Older RHEL versions were unable to capture kernel crashes at early stages in the boot process, because the kdump service's dependencies required it to start later in the process. Without a kernel dump, it is difficult to troubleshooting early boot process problems.

RHEL 8 introduces early kdump support to address this issue. Early kdump support can log kernel crashes during kernel booting, by storing a crash kernel vmlinuz and initramfs inside the initramfs of the normal, booting kernel. Early kdump loads directly into reserved memory (crashkernel) during the early boot stage. Two dracut modules are provided in the kexec-tools package to load the crash kernel and initramfs as early as possible during the boot sequence to be available to capture a crash dump of the normal, booting kernel.