When computers started shipping with UEFI instead of the more traditional BIOS firmware, it made it much more difficult for booting Linux distributions with default motherboard firmware settings. Throw Secure Boot into the mix and it becomes more frustrating. While modern OSes deal with these settings, it’s good to have an idea of the working.
UEFI stands for Unified Extensible Firmware Interface. It is the logical successor to the EFI, which is the Extensible Firmware Interface. During the mid-90s, Intel realized that the IBM BIOS (Basic Input/Output System) style firmware interface had inherent limitations. These limitations didn’t affect the average user, but they made it difficult to produce high-performance servers, namely the Itanium-based products. As a result, Intel started developing the EFI specification in 1998. In 2005, Intel ceased development of the EFI specification and contributed it to the Unified EFI Forum while maintaining ownership. Intel continues to license the EFIspecification to vendors today, but the UEFI specification is owned by the Forum. The advantages of UEFI over BIOS are numerous, to say the least, but some of the more notable ones are:
- A powerful pre-boot environment capable of running applications
- Modular design
- CPU-independent architecture (Itanium, x86, x86-64, ARM Arch32, Arm Arch64)
- BIOS interface compatibility and legacy booting
- The ability to boot from disks larger than 2TiB (note the difference between 2TB and 2TiB)
In order to organize and keep track of partitions on a disk, whether spinning HDD or an SSD, you need what’s known as a partition table, such as MBR (Master Boot Record)and GPT (GUID Partition Table). The legacy BIOS systems are only able to boot from MBR partition tables (there are exceptions, but this is generally a rule) and the MBR specification can only address up to 2TiB of disk space, which results in a BIOSsystem only being able to boot from disks of 2TiB or smaller.
Other disadvantages of MBR formatted disks include a limited number of bootable partitions and a single pointer to a bootloader/boot manager. Many of these limitations are rooted in the fact that the MBR specification only uses a single sector of the disk for its data, referred to as the boot sector. While many disks now have 4KiB sectors, the “modern” MBR specification was designed when disk sectors were commonly 512B, so there really wasn’t much room to work with. This single sector had to include bootstrap code, disk signature, records of all partition locations on disk and sizes, and a boot signature.
Again, dissatisfied with the BIOS and MBR booting paradigm, Intel developed the GPTspecification to remedy the shortcomings of the then available options. The GPTspecification allowed the disks of significantly larger size (several orders of magnitude, up to Zettabytes in size) due to its larger bit allotment for partition addressing, 64B instead of the 16B used by MBR. GPT can partition disks of varying sizes depending on the sector size. This is due GPT addressing sectors as opposed to individual bits or bytes.
As a result, GPT can address a whopping 8ZiB in 512B sectors and 64ZiB using 4KiB sectors. To give you an idea of how futureproof the addressing of GPT is, the maximum addressable 8ZiB in 512B sectors is 8,589,934,592TiB, we will have to first make Petabyte and Exabyte disks before we can dream of reaching the GPT partition addressing limitation. Additionally, what has to be one of the cleverer innovations of the GPT specification is the separation of the boot code and the partition table. Unlike the MBR where a portion of the bootstrap code is actually placed into the boot sector, GPT does things very differently.
While not required for the use of GPT disks, there is a special partition called the ESP(EFI System Partition). This partition is formatted using FAT32 but has a specific partition type code of EF00 as opposed to the 0x0C that would normally be used for FAT32 drive. This difference is insignificant in the operation of the partition as a storage volume apart from the fact that many operating systems will hide it because it’s deemed a system volume. Within this partition, though, you’ll find bootloaders and boot managers as regular files, albeit with an extension of .efi that indicates that it is an EFIexecutable file. At boot time the UEFI compliant firmware on the motherboard scans all disks for ESPs and looks within for these executable files. In doing this, the hardcoded boot paradigm of MBR no longer applies and a much more flexible system is achieved.
Furthermore, if you’ve ever wondered what exactly Secure Boot is, it’s the signing of the executable files. If the signature matches a signature that has been registered with the UEFI firmware, then the motherboard will allow it to boot. The scandal that was Secure Boot on consumer grade computers, fell to the fact that there was only one signature that was authorized for booting and there was no mechanism for adding signatures. This resulted in only operating systems from Microsoft to be booted with Secure Boot enabled, but unfortunately, some hardware vendors had removed the functionality to disable Secure Boot. This problem was resurrected, yet again, with the Microsoft Signature Series, but thankfully, some vendors have acknowledged their mistakes and backpedaled for the sake of the consumer.
Quite often, your operating system will handle the differences between GPT and MBR partitioning for you, especially in newer operating systems. But it’s always good to have at least a rudimentary understanding of the technologies you’re working with, especially when trying to troubleshoot them.
What are your favorite features or most despised gripes of motherboard firmwares and partition tables? Let us know in the comments below.
