Here, we will be discussing the UEFI mode workflow in detail, since it is what the majority of people uses. And, as we know, the Legacy boot process is quite similar to the BIOS booting, what we have already discussed earlier.

The main difference of UEFI with BIOS is that UEFI can recognize boot loaders, disk partitions, and OSs. Also, UEFI can boot from different targets other than disks, such as a remote server. Whereas, BIOS booting is not possible except disks.

EFI System Partition

• The UEFI spec defines a common format of code executable by all the UEFI firmware.
• The firmware is able to read some file systems of the FAT(File Allocation Table) format variant.
• EFI is a special version of FAT. A newly defined file system type separates it from the pure FAT version.
• The EFI system partition is formatted with an UEFI-spec defined FAT variant, and remains in the GPT partition for the firmware to find it there.
• In this way, the firmware is capable of reading data from a normal disk partition.
• Therefore, we don’t need to write the bootloader code inside a specific space at the front of the disk, as it was before in case of the MBR.
• It is now possible to create or format or mount partitions from the OS layer in a widely understandable format, where we can put the bootloader code or else for the firmware to read.
• If we can put an EFI executable code inside a UEFI FAT implemented partition format with the right type of GPT partition, the firmware will be capable of reading it.
• Also, UEFI supports C/C++ language for coding. Therefore, coding in UEFI is simpler than BIOS.

UEFI Boot Manager

• UEFI boot manager is a boot menu, where we can add or delete entries.
• Linux uses the efibootmgr tool to modify UEFI boot manager configuration.
• The firmware is capable of generating entries in this menu, based on the attached disks in the system.
• Also, it can be examined and make some firmware settings.
• The system boot behaviour can be configured also by a booted operating system.
• In case of a normal UEFI booting, the system tries to boot from all the entries in the boot menu, maintaining the BootOrder list. The list shows a wide range of possibilities for valid non-disk boot targets (not all of the entries are valid targets, e.g., video adapter or so).
• The UEFI firmware itself can generate some BIOS-compatible boot entries in this list for a given device.
• This behavior depends on the configuration of that specific firmware.
• These type of entries provide a name like Hard Drive, CD/DVD Drive etc., saying “if this entry is selected, boot this disk in BIOS compatibility mode”.
• The entries which don’t specify the boot target, the ‘fallback’ path is the way of booting from them.
• This path searches for a standard location to find some boot loader code.
• Then the firmware looks through all the EFI system partition in the ordered manner inside the disk.
• The file path syntax it searches for is “\EFI\BOOT\BOOT{machine type short-name}.EFI”. For example, in an x86-64 PC, the “machine type short-name” is x64. Then it executes the first valid file it finds in an executable format defined before.
• Live images or OS installed media can be booted in this way, but not the permanently installed OSs.

UEFI Boot Entries for OS installation

• The entries showing the boot target along with the other specifications of the UEFI boot mechanism are the ones for the permanent OS installation.
• They direct us by showing messages like “boot from this disk”, or “boot this specific bootloader in this specific location on this specific disk” etc.
• The remaining mechanism is almost the same as before. Sometimes, they direct us to a specific partition, which in most of the cases are the EFI system partitions, as it is the valid one.
• The OS implements an EFI bootloader for loading the OS kernel or similar to an EFI system partition, and also generates an entry to the UEFI boot manager based on the name of the OS.
• In case the required partition does not exist, it can be created there. As we have seen before, EFI partition number can be unlimited until the total size of them remains in 9.4 ZB limit.

The boot process in the UI firmware

• A well-defined firmware shows the boot order, and provides an option to change the order as per our requirement.
• Some are a bit different, as they simplify it or makes more complicated than before.
• When we disable the UEFI native booting, the boot order list deletes all the UEFI native entries.
• If we want to boot from removable devices in the fallback process before the permanent booting, we can make it as the default setting, or can instruct the firmware to do that.
• Sometimes, all the connected removable device contains a ‘menu entry’ with them.
• This way, we can manage the boot order to keep them at the top or as per our necessity.
• Also, in some cases, it is possible to request directly for a UEFI fallback boot from the particular disk.

Boot process configuration from an OS

• Windows tool for boot manager configuration is able to control the boot order in a way that, we can command it to boot some specific entries in the list, without bothering the BootOrder list for the next booting.
• So, when we can boot a UEFI native OS, we can configure the booting process from that operating system layer instead of using the firmware user interface, if it feels more complex.
• Therefore, all the OSs can install their personal bootloader into an EFI system partition, and can create entries to the boot menu, so that they can gain control to the boot process.

UEFI mode and Legacy mode booting

• In UEFI mode installation of the OS, an EFI-format bootloader will be written into an EFI system partition, and will generate the specific bootloader entry to the UEFI boot manager boot menu.
• In Legacy mode booting, an MBR style bootloader will be written in a specific location at the front of the disk.
• Practically, when we boot the installation medium in Legacy mode, we can’t install the OS in UEFI mode successfully. Because, in this case, the installer can’t configure the UEFI boot manager as it is only allowed in the native UEFI mode.
• Therefore, we can see the UEFI boot manager configuration based on a specific installation, if it is booted in the native mode. Otherwise, the “Couldn’t open” message will be shown, whenever we try to find the similar configuration in a Legacy mode installation. Also, ‘efi’ or ‘uefi’ file paths will be shown in system logs, in case of native booting.

UEFI mode enabling

For UEFI mode OS installation the medium needs to contain a GPT partition table, along with an EFI system partition, and a bootloader with a correct fallback path like “\EFI\BOOT\BOOTx64.EFI” or similar. If you can’t enable the UEFI mode in your system, check if all the requirements are available or not.

BIOS Compatibility or Legacy mode

If you need to use a removable medium to boot in Legacy mode, you can manage the medium not to boot only in UEFI mode. For that, you need to remove all the EFI system partitions. See if it works. Otherwise, if the firmware can’t be booted in BIOS compatible mode after this, try to consult your firmware vendor.

MBR vs. GPT

• Some firmwares are able to boot BIOS mode from a GPT disk format.
• UEFI firmware are said (in UEFI spec) to be eligible for booting UEFI mode from an MBR disk format.
• But, booting an OS in UEFI mode and then trying to install it in an MBR-type disk without reformatting can’t be possible. Because, in that case, modern OS installers will reformat it automatically to the correct disk type, when it is permitted to remove it completely. And, you will lose important data in the process. That’s why Fedora and Windows don’t allow it explicitly.

Disk Format Checking

The mention of the msdos partition table indicates to an MBR/MS-DOS formatted disk, while you can see gpt for GPT disk format. The disk can be formatted using mklabel msdos or mklabel gpt, but it will eradicate the contents inside the disk.

Controlling EFI System Partition for Manual Partitioning

• For custom partitioning, you need to give an EFI system partition to be used by the installer. Otherwise, the installer will show an error message and will deny the installation to start. In this case, make sure to mount the EFI system partition in /boot/efi.
• For an existing EFI partition, the mount point should be set to /boot/efi. If needed, build a partition and adjust its type as EFI System Partition. Keep its size in 200 – 500 MB, and mount the point to /boot/efi.
• In Windows 10 systems, the default setting is mostly the UEFI mode into a GPT disk type. So, if we need to install another OS here, we should do it in UEFI mode. Otherwise, we need to destroy the whole UEFI mode Windows installation to reformat the disk type into MBR.

Pros and Cons

• The spec says a lot of things, but there is no practical promises or limitations on that. Take the case of Apple, who has a long history to break rules. They created firmwares capable of reading and installing code from HFS+ partitions. Hence, others just have to deal with that.
• Also, if we want to see our alternative OS to be enlisted in the graphical boot menu with a satisfying image or icon, the UEFI spec suggestion is not enough for that.
• But in the end, this is what we have got for now. Because, BIOS setup can’t make it any good for a conventional way of multi-booting. And, I don’t want to mention about the pre-UEFI experiments on multi-booting, as it is nothing but a horrible nightmare.
• Lastly, for a bit of advice, it is better to have a single OS in a single machine. If it’s not possible, at least keep one single OS per disk.

Don’t go already. Our next topic is dedicated to the popular feature of the UEFI. Yeah, you guessed right, it’s Secure Boot.

Go to the next topic Secure Boot in UEFI.