RH342 - ch03s03

Bookmark this page

Resolving Boot Loader Issues on UEFI Systems

Objectives

Repair boot issues on UEFI systems.

Describing the UEFI Firmware Interface

Introduced in 2005, the Unified Extensible Firmware Interface (UEFI) replaces the original Extensible Firmware Interface (EFI) and the legacy BIOS. UEFI overcomes the limits of BIOS, such as 16-bit processor mode and 1 MiB of addressable space. UEFI supports booting from larger disks than 2 TiB, if the disk and its partitions use a GUID Partition Table (GPT) format.

UEFI systems and BIOS systems boot differently. A BIOS system must search for bootable operating systems on devices, while UEFI systems register bootable operating systems in the UEFI firmware. Users of UEFI systems can more easily select an operating system in a multiboot environment.

Using GRUB2 to Boot UEFI Systems

To boot a UEFI system with GRUB2, an EFI System Partition (ESP) must be present on the installed disk. It is recommended to use GPT partitioning for UEFI systems, although you can still use MBR partitioning. The ESP partition must be formatted with a FAT file system and be large enough to store the boot loader and all of the bootable kernels for operating systems that are installed on this system. The recommended size is 512 MiB, but a smaller size might be sufficient. The ESP partition is mounted at /boot/efi and is typically created by the anaconda installer.

The UEFI Boot Chain

A Secure Boot-capable system uses signatures on boot loaders, kernels, and other boot objects. The system firmware verifies the signatures as authentication that only unmodified code is being loaded, with a component that is known as the shim UEFI boot loader.

The shim.efi application is signed with a key that is trusted by common UEFI firmware. When executed, the shim.efi application attempts to load grubx64.efi with standard UEFI firmware calls. If the UEFI firmware cannot load the code because the signature does not authenticate, then the shim attempts to verify the application with other keys.

These alternative keys are either compiled into the shim, or read from a user-generated key that is stored in the UEFI NVRAM as the Machine Owner Key (MOK). When attempting to start a signed application for which no keys are registered, the MokManager.efi application starts automatically so that an end-user can register a personal key.

The shim.efi application registers an additional UEFI system call that uses GRUB2 to verify kernel signatures. If shim.efi is not registered with the UEFI firmware, then booting from the ESP partition executes the /boot/efi/EFI/BOOT/BOOTX64.efi application. This application loads the fallback.efi application, which automatically registers the shim.efi application and boots the system, based on the settings in /boot/efi/EFI/redhat/BOOT.CSV.

Main GRUB2 Difference Between BIOS and UEFI

Figure 3.1: Boot process for BIOS-based and UEFI-based systems

While most configuration syntax and tools remain the same for both BIOS and UEFI boot processes, some differences exist.

linux16 and /initrd16 changed to linuxefi and initrdefi

The configuration commands to load a kernel and initial ramdisk switch from linux16 and initrd16 for BIOS to linuxefi and initrdefi for UEFI.

This change is necessary because kernels must load differently on a UEFI system from on a BIOS system. The grub2-mkconfig command automatically recognizes a UEFI system and uses the correct commands.

/boot/grub2 changed to /boot/efi/EFI/redhat

The directory for holding the UEFI GRUB2 configuration files and objects is /boot/efi/EFI/redhat. This directory is on the ESP partition for UEFI firmware access.

grub2-install

Do not use the grub2-install command directly to install the UEFI boot loader. RHEL 8 provides a prebuilt /boot/efi/EFI/redhat/grubx64.efi file, which contains the required authentication signatures for a Secure Boot system. Executing grub2-install directly on a UEFI system generates a new grubx64.efi file without those required signatures. The correct grubx64.efi file can be restored from the grub2-efi package.

Use of grub2-install directly registers a bootable target in the UEFI firmware with this new grubx64.efi application, instead of the required shim.efi application.

Warning

Use of the grub2-install command generates and configures a generic grubx64.efi file. If the system is configured for Secure Boot, then the system fails to boot.

/boot/grub2/grub.cfg changed to /boot/efi/EFI/redhat/grub.cfg

The GRUB2 configuration file is moved from the /boot/grub2 directory for BIOS to the /boot/efi/EFI/redhat/ directory on the ESP partition for UEFI. The symbolic link /etc/grub.cfg is moved to /etc/grub2-efi.cfg.

Managing UEFI Boot Targets

RHEL 8 provides the efibootmgr utility to manage and edit the available boot targets and logical boot order. The tool is in the efibootmgr package, which is installed by default on UEFI systems.

Viewing Current Targets

View the current targets with the efibootmgr command.

[root@host ~]# efibootmgr
BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0003,0002,0000
Boot0000* UiApp
Boot0002* UEFI Misc Device
Boot0003* Red Hat Enterprise Linux

	The list defines the order of the boot entries to try, from left to right. The numbers refer to the listed `Boot0000` entries.
	This number is an individual boot entry; in this case, hexadecimal number `0x0003`. An asterisk (`*`) on an entry marks it as `active` and available to select and boot.

View more information about boot entries by using the -v option.

[root@host ~]# efibootmgr -v
BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0003,0002,0000
Boot0000* UiApp	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0002* UEFI Misc Device	PciRoot(0x0)/Pci(0x2,0x3)/Pci(0x0,0x0)N.....YM....R,Y.
Boot0003* Red Hat Enterprise Linux	HD(1,GPT,e7e64bf7-6799-4791-bdc0-28147761e11d,0x800,0x12c000)/File(\EFI\redhat\shimx64.efi)

The Boot0003 entry now displays the hard disk, partition, and file for booting.

Removing an Entry

To remove a boot entry from the list, use the efibootmgr command with the -B option. In this example, the 0x0004 entry is deleted.

[root@host ~]# efibootmgr -b 4 -B

Selecting a Temporary Boot Target

Use the -n option to override the regular boot order for the current boot. For example, the following command forces the system to boot with entry 0x0002.

[root@host ~]# efibootmgr -n 2

Adding an Entry

Use the -c option for creating new entries and boot numbers. Unless overridden on the command line, the option defaults to an ESP location on /dev/sda1, an intended label of Linux, and the boot loader application is elilo.efi.

The following example adds an Example entry, with /dev/sda2 as the ESP location, and with the /EFI/example.efi application on the ESP. In the application file name, you must replace forward slashes (/) with backslashes (\).

[root@host ~]# efibootmgr -c -d /dev/sda -p 2 -L "Example" -l "\EFI\example.efi"

Generating BLS Configuration Files in UEFI

To generate BLS configuration files, enable the feature in the /etc/default/grub file.
```
GRUB_ENABLE_BLSCFG=true
```

For a UEFI system, regenerate the /boot/efi/EFI/redhat/grub.cfg file.

[root@host ~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
Generating grub configuration file ...
done

Generate a kernel boot configuration in the /boot/loader/entries directory.

[root@host ~]# kernel-install add $(uname -r) /lib/modules/$(uname -r)/vmlinuz

Using the grubby Tool for UEFI Firmware

On UEFI systems, using grubby requires root privileges.

Use grubby to obtain the file name of the default kernel.

[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/e1a2445950a34804857a9407715ed7ab-4.18.0-305.el8.x86_64.conf with index 0 and kernel /boot/vmlinuz-4.18.0-305.el8.x86_64

List the kernel menu entries with details.

[root@host ~]# grubby --info=ALL
index=0
kernel="/boot/vmlinuz-4.18.0-305.el8.x86_64"
args="ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet $tuned_params"
root="/dev/mapper/rhel-root"
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="e1a2445950a34804857a9407715ed7ab-4.18.0-305.el8.x86_64"
index=1
kernel="/boot/vmlinuz-0-rescue-e1a2445950a34804857a9407715ed7ab"
args="ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet"
root="/dev/mapper/rhel-root"
initrd="/boot/initramfs-0-rescue-e1a2445950a34804857a9407715ed7ab.img"
title="Red Hat Enterprise Linux (0-rescue-e1a2445950a34804857a9407715ed7ab) 8.4 (Ootpa)"
id="e1a2445950a34804857a9407715ed7ab-0-rescue"

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 crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet $tuned_params"
root="/dev/mapper/rhel-root"
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="e1a2445950a34804857a9407715ed7ab-4.18.0-305.el8.x86_64"

Reinstalling GRUB2 on UEFI-based Machines

To recover damaged or missing /boot/efi files, reinstall the grub2-efi and shim packages.

[root@host ~]# yum reinstall grub2-efi shim
---output omitted---
Complete!

If the /boot/efi/EFI/redhat/grub.cfg file was removed, then you can regenerate it with grub2-mkconfig.

[root@host ~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
Generating grub configuration file ...
done

If the Red Hat Enterprise Linux 8 entry is missing from the UEFI boot menu, it is automatically restored when you next boot from the UEFI-configured system disk.

References

efibootmgr(1), grub2-mkconfig(1), kernel-install(8) and grubby(8) man page

For further information, refer to Chapter 5. Configuring Kernel Command-Line Parameters at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/managing_monitoring_and_updating_the_kernel/configuring-kernel-command-line-parameters_managing-monitoring-and-updating-the-kernel

For further information, refer to How to reinstall GRUB and GRUB2 on UEFI-based machines? at https://access.redhat.com/solutions/3486741

Discuss Red Hat Enterprise Linux Diagnostics and Troubleshooting

Go to community

Welcome to the Red Hat Enterprise Linux Diagnostics and Troubleshooting (RH342) group!

cschunke

26 wrz 2023

We are excited to launch a space dedicated to the Red Hat Training course Red Hat Enterprise Linux Diagnostics and Troubleshooting! To gain the most value from this group - click the "Join Group" button in the upper right hand corner of the group home page.We encourage group members to collaborate in this group to discuss topics, ask questions, share best practices and tips, provide course feedback, and share their accomplishments as it relates to RH342.Read more about Red Hat Enterprise Linux Diagnostics and Troubleshooting here.

445

Revision: rh342-8.4-6dd89bd

Click Create to build all of the virtual machines needed for the classroom lab environment. This may take several minutes to complete. Once created the environment can then be stopped and restarted to pause your experience.
When a lab is created, click Start to run all of the virtual machines in the classroom.
Click Stop to stop all the virtual machines from running. This will not delete your lab.
If you Delete your lab, you will remove all of the virtual machines in your classroom and lose all of your progress.

Virtual machine actions

Click Start to power on the virtual machine.
Click Shutdown to gracefully shut down the virtual machine, preserving disk contents.
Click Power off to forcefully shut down the virtual machine, while still preserving disk contents.
Click Open console to connect to the system console of the virtual machine in a new browser.

Auto-stop timer

The Red Hat Learning Subscription entitles you to set allotment of lab time.
To help conserving your allotted time, the lab environment uses automatic timers to stop or destroy your lab environment when the timer expires.

Click the Auto-stop button [+] to extend the time you would like to spend with the labs.
Click the Auto-destroy button [+] to add day(s) to the auto-destroy timer.

Auto-stop has a maximum of 11 hours, and auto-destroy has a maximum of 14 days.
Be careful to keep the timers set while you are working, so that your environment doesn't shut down unexpectedly.
We also suggest not to set the auto-timers unnecessarily high, which could waste your lab time allotment