Boot Loaders are an important part of every Android system. They play a vital role in keeping the phone working. Any particular issues related to Boot Loader needs to be resolved on time as they often plague computer systems to a larger extent.

This post will ease out the booting process, both for BIOS as well as UEFI based systems. BIOS and UEFI are the two interfaces for computers which work as an interpreter between the computer firmware and the operating system.

The major difference between the two interfaces is their features and the versions. UEFI is an advanced and modified version of the BIOS system. BIOS has a limit of working in 16-bit processor and only 1 MB of addressable space. In contrast to UEFI, it stores all the information about initialization and allows booting from disks larger than 2TB. This is because BIOS uses the Master Boot Robot (MBR) to save the information about the hard drive data, while UEFI uses the GUID partition table (GPT).

It is believed that UEFI will replace BIOS in the future, bringing in many new features and enhancements that cannot be implemented through BIOS.

RESOLVING BOOT LOADER ISSUES ON BIOS SYSTEMS

BIOS (Basic Input Output System) powered system goes through a numbers of steps when it runs a RHEL (Red Hat Enterprise Linux) system.

GRUB2

Grub is installed by many distributions and is available as an option with others. It mechanically detects the other operating systems present on your computer and adds them as an entry to your system.

The boot loader used on RHEL is GRUB2, the second major version of the GR and Unified Boot Loader. GRUB2 stores its files on a BIOS system in a number of different locations, as mentioned below:-

/boot/

The kernel and initial RAM disks are stored here. Sub-directories contain other files.

/boot/grub2/

This contains the configuration files, extension modules and themes.

/boot/grub2/grub.cfg

This has the main GRUB2 configuration file. This file is auto generated, and should normally not be edited manually. As a convenience, /etc/grub2.cfg is a symbolic link to this file.

/etc/grub.d/

The directory contains a helper script to generate a main GRUB2 configuration file.

/etc/default/grub

This file contains variables used in the generation of the main GRUB2 configuration file.

/boot/grub2/grubenv

This contains a file of exactly 1 KB, which is used as storage for variables.

 

MBR (The Master Boot Record)

In order to boot GRUB2 from the disk on a BIOS system, there are 2 options- 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’.

MBR is good in terms of every aspect but the major problem holds is with the space available with the boot loader. A typical MBR is only 512 bytes in size, and part of that space is used for the partition table of that disk, leaving only 446 bytes for the boot loader.

To solve this issue, GRUB2 can use the ‘boot track’ , ‘MBR gap’, or ’embedding area’ on the disk to store the extra modules and file it needs. This is the space between the MBR and the first partition on the disk. In order to work reliably, there needs to be at least 31 KB of space  available this way (63 sectors on a 512-byte sector disk). If a disk has been partitioned by Anaconda, the first partition will usually start at sector 2048, leaving roughly 1MB of space for the embedding area, which is ample room for GRUB2.

 

CONFIGURING GRUB2

Under normal circumstances, an administrator should not have to manually configure the GRUB2 boot loader. When a new kernel is installed, it will be added to the configuration automatically and when a kernel is removed, the corresponding entry in the boot loader menu is removed automatically as well.

An administrator might want to tweak some parameters that are passed into the kernel at startup by GRUB2. The best way to do this is by editing /etc/defaults/grub and then forcing a recreation of the main GRUB2 configuration file.

The settings in /etc/defaults/grub that are of interest are listed here.

 

GRUB_TIMEOUT

This is the number of seconds the GRUB2 menu is displayed before the default entry is booted automatically.

 

GRUB_DEFAULT

 This is the number of the default entry that should be started whenever a user does not select another entry, which is when GRUB2 starts counting at 0. If this variable is set to the string saved, the entry will be taken from /boot/grub2/grubenv.

 

GRUB_CMDLINE_LINUX

 This variable contains a list of extra kernel command-line options that should be added to every single Linux kernel. Typical uses include ‘rh gb quiet’ for a graphical boot, ‘console =xxxx’ for selecting a kernel console device, and ‘crashkernel=xxxx’ for configuring automatic kernel crash dumping.

After updating the file /etc/default/grub, changes can be applied by running the command grub2-mkconfig-o/boot/grub2/grub.cfg. This will generate a fresh configuration file using the scripts in /etc/grub.d and the settings in /etc/defaults/grub. If no output file is specified with the -o option, a configuration file will be written to the standard output.

RESOLVING BOOT LOADER ISSUES ON UEFI SYSTEMS

Unified Extensible Firmware Interface (UEFI) replaces the older Extensible Firmware Interface (EFI) and the system BIOS. A replacement for the older BIOS imposed, such as 16-bit processor mode and only 1 MB of addressable space.

UEFI also allows booting from disks larger than 2 TB, as long as they are partitioned using a GUID Partition Table (GPT).

One of the big differences between UEFI systems and BIOS systems is the way they boot. While in the case of the latter, the BIOS has to search for bootable devices, operating systems can ‘register’ themselves with the UEFI firmware. This makes it easier for end users to select which operating system they want to boot in a multi-boot environment-GRUB2 or UEFI.

The main GRUB2 difference between BIOS and UEFI

linux16/initrd16 vs linuxefi/initrdefi

The configuration commands to load a kernel and initial RAM disk switch from linux16 and initrd16 to linuxefi and initrdefi, respectively.

The change is necessary since kernels need to be loaded differently on a UEFI system than on a BIOS system.

 

/boot/grub2 vs /boot/efi/EFI/redhat

On UEFI systems the directory holding all grub2 configuration files and extras is moved to /boot/efi/EFI/redhat. This is a location on the ESP, making it accessible to the UEFI firmware.

 

grub2-install

While a grub2-install command is more capable of installing a boot loader onto a UEFI system, it should never be used directly. Calling grub2-install on a UEFI system will generate a new /boot/efi/EFI/redhat/grubx64.efi application, instead of the shim.efi application.

 

Boot loaders are important. They’re an integral part of keeping your phone working. They’re also a critical piece of the puzzle that is custom ROMs. Hopefully carriers and manufacturers will respect users’ wishes in the future and leave the boot loader alone.

Not all the IT programmers are satisfied with the fact of UEFI superior to BIOS as they still believe the existence of ancient version to be the best in comparison to the modified one.