Brief explanation of booting/GPT

This document serves as a quick reference to how UEFI and GPT work in regards to booting a modern system.

I will not cover BIOS/MBR in this document. I will acknowledge their existence and will compare them to their modern counterparts, but I feel that it is a waste of time to dig deeper into their inner workings. I will also not cover or mention the compatibility possibilites/issues of using UEFI/MBR or BIOS/GPT. Know that it is, in certain cases, possible, but that it is always a better idea to use either UEFI/GPT or BIOS/MBR. The ArchWiki and its numerous articles listed below cover the compatibility issues in more detail.

UEFI and a brief overview of its booting process

UEFI stands for Unified Extensible Firmware Interface. It represents a specification of a software layer, or rather an interface between the motherboard’s firmware and the user/OS. It is responsible for most of the booting process, including starting the bootloader.

It’s also the successor of the old BIOS (Basic Input/Output System). Compared to it, UEFI has many advantages (a modular design, ability to use large disks, CPU independent drivers, a flexible pre-OS environment - including networking, better standardization, network booting…)

When started, UEFI utilizes its boot manager to decide which UEFI Application it should load. UEFI Applications are binary executables (most commonly bootloaders, or kernel stubs) in a specific binary format defined by the UEFI Spec, usually utilizing the .EFI extension.

These binary UEFI Applications are usually stored on the EFI System Partition (ESP). It represents a VFAT filesystem partiton on a GPT formatted disk. As most UEFI implementations only include VFAT drivers, having the ESP contain a filesystem other than VFAT is not possible.

Example: On a typical x86_64 architecture the GRUB2 bootloader (which is an UEFI application) is stored in its own folder on the ESP: esp/entry_name/grubx64.efi – where esp is the mountpoint of the EFI System Partition and entry_name is the folder name you chose during the grub installation process that it stores itself on.

The UEFI Boot Manager is the component that helps the UEFI choose which binary application (e.g. bootloader) it should load. It stores its information (that consists of the boot entires and a boot order) in NVRAM (non-volatile RAM).

The boot entries describe where the UEFI can find a specific loadable EFI Application (e.g. the grub bootloader). They consist of a disk ID, a GPT PARTUUID of the ESP that the EFI Application resides on, along with a full path to it, and a text label that helps identify the entry to the user. There may be multiple boot entires present a time.

e.g. on my current configuration, the boot entry that loads the GRUB2 bootloader looks like this:

`Boot0000* MyArchInstall    HD(1,GPT,71aca8cd-005e-444e-8c64-2153d3a35d1c,0x800,0x113000)/File(\EFI\StarchGrub\grubx64.efi)`

MyArchInstall here represents the textual label that is displayed in the UEFI GUI upon booting, \EFI\StarchGrub\grubx64.efi represents the full path to the grub2 efi application. Between them is the GPT PARTUUID number that identifies the ESP on HD1 (NOTE: EFI is an actual folder residing in the ESP, not a mountpoint of the ESP)

The boot order represents an order in which the boot entries should be tested for loading (should multiple of them exist). Typically, the first one that is validated is loaded. Most UEFI implementations allow the user to choose which boot entry is loaded manually, and the boot order is only used if the user decides not to do so (which is most often the case).

In the case that no boot entries exist, or in the case that the user explicitly decides to do so, most UEFI implementations allow using bare disks as boot entries. In the boot manager they are simply listed as their respective models. Should the user choose one of them instead of a regular boot entry, the UEFI will scan the selected disk for GPT partitions, try to locate an ESP on it (by utilizing the standardized PARTTTYPE UUID which identifies partitions based on their use-case), and load a default EFI application that usually resides in esp/EFI/BOOT/BOOTX64.EFI, at least on an x86_64 system. In the case that an ESP or a default EFI application doesn’t exist on the chosen disk, the booting will likely fail. The most common example for this process is removable bootable media (e.g. a USB containing a windows intallation).

Both the boot entries and the boot order, along with the rest of UEFI’s settings can be configured from its interface directly, or from many different operating systems. On linux for example, the efibootmgr CLI userspace utility is most commonly used to modify boot entries and the boot order.

The latest UEFI Specifications can be found here.

Also check out this amazing post on UEFI booting, which also covers some side topics.

Partitioning schemes (GPT, MBR)

GPT stands for GUID Partition Table. It is a specification and a standard defined in the UEFI Spec (and is therefore designed to be used and to work alongside it) that describes the layout of the partition tables used on block devices, such as hard drives. It is also the successor to the ancient MBR partitioning scheme which was commonly used in conjunction with the BIOS.

GUID stands for globally unique identifer. In the linux world, the term UUID (universally unique identifier) is more commonly used, but they both refer to a unique 128bit number used to identify a certain object. They are not specific to the topic of partitioning tables, and are very often used in the computing world. Going forward, I will use the term UUID.

The GUID Partition Table is named so because of its widespread use of UUIDs.

In the GPT:

  • Each partition is given a unique UUID when the partition is created. Most linux userspace utilities (e.g. lsblk, blkid) refer to this as the PARTUUID. This is important for persistent block device naming.

  • Each partition is also given a Partition type GUID (UUID) which describes its use case. These are standardized and universal. There can exist multiple partitions on a single disk with the same Partition type GUID. Most linux userspace utilities refer to this as the PARTTYPE. Their list can be found here.

  • Each partition can also be given a textual, Unicode UTF16 encoded label. It is optional. Most linux userspace tools refer to this as the PARTLABEL. Using it for persistent block device naming is not preffered as duplicates can exist.

  • Each filesystem on a GPT partition also has a unique UUID. These exist for legacy and compatibility reasons. They are not part of the partition, or the partition table (GPT), but of the filesystem that resides on the partition. Thus, they are generated by whichever utility generates a filesystem (e.g. mkfs on linux), and not by that which generates partitions. Despite that, I decided to list them here to avoid confusion. Most linux userspace tools refer to these as simply UUID (which can be confusing). Their length may not be 128bits, and it may differ between filesystems (e.g. on vfat it is significantly shorter than on ext4). Using actual GPT partition PARTUUIDs is almost always preffered.

  • Each filesystem on a GPT partition can also be given a textual label. The story is similar to that of the previous point. Kept for legacy and compatibility reasons, not part of the partition or the partition table, but that of the filesystem. Most linux userpsace tools refer to it as simply LABEL (which can, again, be confusing). As with the actual GPT Partition PARTLABEL, its use is also discouraged as duplicates of it can also exist, but if you are to, for some reason, use a label, prefferably go with the PARTLABEL.

Linux userspace partitioning tools

Some of the most common tools in the linux userspace that posses the ability of creating GPT schemes on block devices are:

  • fdisk
  • gdisk
  • parted

I will not cover these tools here. For guidance, consult their respective manpages or the ArchWiki.