BIOS, UEFI and the Boot process Explained along with MBR and GPT

What are UEFI and BIOS

These are specifications that describe and define how the system firmware should work to initialize the hardware and load the OS.

In old systems we had the IBM PC "derived" BIOS implementations. Its the blue screen interface that you enter by pressing the Del/F2 keys just AFTER system power has been turned on and BEFORE the os has started booting.

Newer systems have UEFI which is intended to supersede the older BIOS standard. UEFI also provides a configuration interface that can be loaded the same way by pressing Del/F2 keys on most systems. The UEFI interface have fancy background, fonts and mouse pointer. So if you see one of those, its a UEFI system.

It is important to understand what a firmware is. Its a special software running on a special hardware and serving a special purpose. So the UEFI firmware contains a special software that runs on some chip on the motherboard (ROM) and does the special task of launching the OS from some bootable drive.

Over the past decade as the transition from BIOS to UEFI was taking place lots of users faced troubles when doing things like installing Windows or Linux, or booting from live usb drives etc. Most of the time they did not understand the UEFI settings properly and messed up things here or there.

However in recent years ( since 2020 ) most modern hardware and software have become very stable and provide the user with a much more smoother experience when it comes to dealing with UEFI hardware.

For example:

1. Most bootable disk creation application now create a installation medium that can boot on any kind of system: UEFI, UEFI+CSM and older BIOS machines. This prevents a lot of boot errors and creates a better booting experience for the user.

2. Most laptops or motherboards have a very simple setting that sets the system in one of the 2 modes, UEFI-strict or UEFI+CSM and then boots any medium accordingly.

3. Most modern Windows 10 based laptops disable hybrid modes like UEFI+CSM which forces the user to stick to UEFI. This makes things difficult for beginners who do not know what UEFI is, but makes things more predictable and errors easier to handle.

In this article we shall going through all the technical details of what technologies are involved in the boot process (or booting process) and how they work.

BIOS vs UEFI

BIOS looks for boot-loader in the MBR whereas UEFI looks for boot-loader (.efi file based) in the EFI directory which resides in the EFI System Partition (aka ESP).

Conventionally BIOS worked with MBR based drives whereas UEFI needed its own specified GPT format partition drives.
However cross-compatibility has been developed and now there UEFI can be made to boot from MBR based drives and BIOS can boot from GPT based drives.

In principle BIOS only supports a single boot-loader "program" which is the mbr boot-strap code. Any dual boot setups on BIOS systems were facilitated by other Stage 2 boot-loaders (like GRUB) that could manage and launch multiple different oses.

BIOS however could recognise multiple separate bootable drives, provided they had a valid MBR.

UEFI on the other hand has a more flexible design supporting multiple OSes boot-loaders right from the ground-level. Each OS needs to install its boot-loader in the form of a executable .efi code file in the "EFI" directory of the EFI system partition.

UEFI - Some Basics

It is very important to understand that the term UEFI does not indicate a single program or technology. It is rather a bunch of different things that are designed to work together.

Fundamentally UEFI is just a set of specifications that describes an interface (software structure) to work between the operating system (Ubuntu or Windows for example) and the platform firmware (motherboard for example).

UEFI is the successor of Extensible Firmware Interface Specification 1.10 (EFI). So it can be thought of as EFI v2.

Note: There is not such thing as "UEFI bios". Its just UEFI. However words like "UEFI BIOS" and "Legacy Bios" seem to have become very popular for historic reasons.

UEFI components and setup

1. The configuration interface
2. EFI System Partition and EFI based boot
3. GPT File system
4. Secure Boot

In very simply terms here are a couple of things that come under the umbrella term UEFI:

1. Fancy Configuration Interface

1. A fancy GUI "bios" screen with nice colors, fonts, animations and mouse pointer. This is the new UEFI configuration interface which looks different from the older BIOS (a.k.a Legacy BIOS). Think of UEFI as a tiny operating system that runs the moment you turn on your machine and before Windows or Linux has started loading.

2. EFI System partition

EFI System Partition (a.k.a ESP) - This is a special partition found on systems that use UEFI based booting.

All modern Windows 10 laptops use UEFI based booting and you can see the EFI partition on the primary drive using any partition tool. When setting up dual boot on UEFI based boot systems, the additional oses install their respective boot-loaders inside the EFI directory on the ESP.

Note that if your desktop motherboard has UEFI, it does not necessarily imply that you are using or have to use UEFI based booting as well. For instance on my main desktop, I have a Gigabyte H110M-H motherboard which has UEFI but my main OS (Ubuntu) is installed on a MBR based ssd and using legacy bios boot method. UEFI supporta legacy bios boot through CSM. More on this later.

3. GPT Partition Table Format

This is the new partition management scheme which supersedes the older MBR scheme. If you are using UEFI+ESP setup for booting Windows then you must use GPT based drive as well.

However, functionally GPT is not a strict requirement for UEFI to work. You can setup an mbr drive for use with UEFI. But you would still need to place the EFI directory somewhere.

Another thing to note is that the EFI directory (which contains the .efi boot-loader files) does not need to be in a separate partition necessarily.With Linux, the EFI directory can be contained in the same partition where the OS is installed.

However this is not a very efficient approach and has drawbacks specially in dual boot setups. More the partition containing the EFI files must strictly be FAT 16/32 which can be constraining for the operating system to work with.

In case of Windows 10/11 the default setup involves a separate EFI partition as compulsary.

4. Secure Boot

This is yet another feature that comes under the UEFI set of technologies. It can be enabled/disabled from the UEFI interface. However some devices may not provide the option to switch off secure boot. For example my Acer Swift 3 laptop does not let me disable secure boot.

---

If your motherboard has UEFI you can tell it by looking at the specifications. For example the Gigabyte H110M-H uses "AMI UEFI BIOS". Its UEFI implementation from a company known as AMI.

Most modern desktop motherboards and laptops now ship with UEFI and quite often Windows 10/11 is pre-installed in UEFI mode.

UEFI Modes - Strict vs CSM

A UEFI firmware system can often work in 2 different modes:

• UEFI "only" (UEFI-strict mode / UEFI-native mode)
• UEFI + CSM (UEFI + Legacy BIOS mode)

They have quite a lot of technical differences but we shall cover only the basics here.

1. UEFI-only / UEFI-native

This is the UEFI "only" mode which will boot only those oses that have been installed in uefi mode. That is they must have EFI system partition with ".efi" file boot-loaders for each operating system installed on that particular drive.

For Windows 10/11 you also need GPT based drive because windows does not support mbr drive for booting in uefi mode.

However, modern implementations of uefi can also boot from mbr drives partitions. This means that you can use either mbr or gpt drives in uefi-strict mode. Just make sure that the EFI directory is in the right place with the ".efi" boot-loader files.

On my main ubuntu-only desktop machine, I have Ubuntu installed on mbr ssd in legacy bios mode (without EFI directory or ESP partition). My Gigabyte H110M-H motherboard is has uefi firmware and uses csm to boot ubuntu.

UEFI-strict supports new features like Secure Boot.

When UEFI-strict is active, any live usb drives (like ubuntu) will boot only if they are also uefi based. Non-uefi drives that do not have the EFI directory will not boot.

Consequently the live media OS will also be booted in UEFI mode only.

Subsequent installation of the OS from the usb drive will be done in UEFI mode only. If its a ubuntu live usb (uefi), installing from it, will install Ubuntu in UEFI mode as well.

UEFI-strict firmware mode ==> UEFI bootable live/installation usb ==> 
==> UEFI mode OS boot ==> UEFI mode installation of OS

Everything is UEFI .. UEFI .. UEFI .. UEFI .. WAOOOO!

If you want to know whether your live usb is uefi or non-uefi, simply check the partition scheme and partition layout using "gnome-disks".

Note that there is a EFI System Partition (ESP) in the layout above. This boot usb was created using gnome-disks only. The gnome-disks application automatically creates a efi partition based uefi boot usbs using either MBR or GPT.

Below is an example of a Fedora live usb made with gnome-disks and using mbr partition table.

The above is a Fedora live usb drive using MBR partition scheme with an EFI system partition. This usb DID boot on my Acer Swift 3 laptop which runs is UEFI-strict mode (CSM disabled permanently).

On Windows you can use the tool called Rufus to create ubuntu live usb. If the usb is created using "iso image mode" then both the EFI directory and the OS are on a single FAT32 partition which is bit awkward but it works good enough.

The above approach does produce a usb drive that boots on uefi systems, but it is not the correct way of doing it. Its better to use the "DD Image mode"

When using the "DD Image mode" in Rufus the partition layout is very different and GPT is used:

2. UEFI+CSM (Legacy BIOS mode)

When CSM support is enabled, the UEFI firmware will work and behave both like a UEFI firmware as well as a "old" BIOS firmware. So it is a hybrid or mixed mode.

The system will be able to boot from non-efi based boot-loaders that were originally made to work with BIOS.

This is a hybrid mode, therefore the system will first try one boot method (UEFI or BIOS depending on vendor) and if it fails, it will try another.
For example it will first look for the EFI boot-loader (.efi) files in the EFI directory. If it can't find that, it will try the MBR style boot method, or the other way around.

---

The UEFI mode can be configured from the UEFI firmware settings interface that comes up by pressing the F2 (or some other key based on your system vendor) at machine power start.

Different vendors provide settings under different names to enable UEFI-strict mode.
For instance my Gigabyte H110M-H motherboard is set to UEFI-strict mode by disabling CSM (Compatibility Support Module).

There is some discussion about CSM over here and here

It is very important to understand that both UEFI-native and Legacy modes are just bootup mechanisms and do not affect the functioning of the operating system in anyways. Once booted your windows or ubuntu system will work and feel the same regardless of the booting mechanism used.

---

A lot of modern windows 10 laptops have CSM disabled by default and do not provide a discrete option in the firmware interface to change it. This in effect permanently disables CSM (unless a future bios update enables it back again).

My Acer Swift 3 and Asus TUF A17 gaming cannot boot live usbs in legacy bios mode. But my Gigabyte H110M-H motherboard can.

Check your boot mode - BIOS or UEFI

If you want to check which mode your linux system has booted with, use the following command:

$ sudo efibootmgr -v

Or look for the presence of this directory: /sys/firmware/efi

$ ls -la /sys/firmware/efi

Here are some results from my machines.

1. My Ubuntu Desktop:

My main Ubuntu desktop is running UEFI (Legacy BIOS mode) mode or basically Non-EFI mode. The setup is UEFI (Legacy/BIOS Compatibility Mode) + MBR SSD with single partition.

So the output is shown as:

$ sudo efibootmgr -v
EFI variables are not supported on this system.

Another command is:

$ [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
BIOS

Note that the motherboard has UEFI and not old BIOS. Still I am using regular mbr based bios style booting.

2. Acer Swift 3 - Windows 10 + Ubuntu dualboot (UEFI-only)

My Acer Swift 3 laptop has windows and ubuntu installed in dualboot, and both are using UEFI boot methods. Running the efibootmgr command from inside the Ubuntu installation shows up some useful information indicating the presence of UEFI.

$ efibootmgr -v
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0002,0001,2001,2002,2003
Boot0001* Windows Boot Manager  HD(1,GPT,68c5fb71-6a13-42c9-922e-a687df3250dd,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...C................
Boot0002* ubuntu        HD(1,GPT,68c5fb71-6a13-42c9-922e-a687df3250dd,0x800,0x32000)/File(\EFI\ubuntu\shimx64.efi)
Boot2001* EFI USB Device        RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network   RC
$

Note the name and path of the boot-loader files of the boot-loader files:

• \EFI\Microsoft\Boot\bootmgfw.efi - Windows 10
• \EFI\ubuntu\shimx64.efi - Ubuntu 22.10

Ubuntu is booted via the shimx64.efi file because "Secure Boot" is enabled.

When running in UEFI boot mode, the directory /sys/firmware/efi will exist.

$ [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
UEFI

The contents of the /sys/firmware/efi directory is visible.

$ ls -la /sys/firmware/efi/
total 0
drwxr-xr-x   7 root root    0 Nov 16 11:25 .
drwxr-xr-x   6 root root    0 Nov 16 11:25 ..
-r--r--r--   1 root root 4096 Nov 16 11:28 config_table
drwxr-xr-x   2 root root    0 Nov 16 11:26 efivars
drwxr-xr-x   3 root root    0 Nov 16 11:28 esrt
-r--r--r--   1 root root 4096 Nov 16 11:28 fw_platform_size
-r--r--r--   1 root root 4096 Nov 16 11:28 fw_vendor
drwxr-xr-x   2 root root    0 Nov 16 11:28 mok-variables
-r--r--r--   1 root root 4096 Nov 16 11:28 runtime
drwxr-xr-x   9 root root    0 Nov 16 11:28 runtime-map
-r--------   1 root root 4096 Nov 16 11:28 systab
drwxr-xr-x 143 root root    0 Nov 16 11:28 vars
acerlight@acerlight-laptop:~$

$ cat /sys/firmware/efi/fw_platform_size 
64

---

Contents of the EFI partition - How does it look ?

When ubuntu is installed in UEFI mode the contents of the EFI System Partition (ESP) are made available at the mount point /boot/efi/.

Here is a quick example from my Acer Swift 3 laptop that has windows 10 and ubuntu in dual boot setup.

root@acerlight-laptop:/# ls -la /boot/efi/EFI/
total 6
drwx------ 6 root root 1024 Mar 20  2021 .
drwx------ 4 root root 1024 Jan  1  1970 ..
drwx------ 2 root root 1024 Mar 20  2021 Boot
drwx------ 4 root root 1024 Nov 11  2020 Microsoft
drwx------ 4 root root 1024 Nov 11  2020 OEM
drwx------ 2 root root 1024 Mar 20  2021 ubuntu
root@acerlight-laptop:/#

So for each OS there is a directory. Each directory will in turn contain one or more .efi files that contain the boot loader executable code. Inside the ubuntu directory we can see grubx64.efi since GRUB2 is the boot-loader for ubuntu.

root@acerlight-laptop:/# ls -la /boot/efi/EFI/ubuntu/
total 3477
drwx------ 2 root root    1024 Mar 20  2021 .
drwx------ 6 root root    1024 Mar 20  2021 ..
-rwx------ 1 root root     108 Nov 16 14:19 BOOTX64.CSV
-rwx------ 1 root root     117 Nov 16 14:19 grub.cfg
-rwx------ 1 root root 1742728 Nov 16 14:19 grubx64.efi
-rwx------ 1 root root  856232 Nov 16 14:19 mmx64.efi
-rwx------ 1 root root  955656 Nov 16 14:19 shimx64.efi
root@acerlight-laptop:/#

Note the shimx64.efi file, which is used for Secure Boot if enabled.

Inside Microsoft directory we can see bootmgr.efi which is the boot-loader for Windows 10.

root@acerlight-laptop:/# ls -la /boot/efi/EFI/Microsoft/Boot/*.efi
-rwx------ 1 root root 1562456 Oct  3 00:02 /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
-rwx------ 1 root root 1545560 Oct  3 00:02 /boot/efi/EFI/Microsoft/Boot/bootmgr.efi
-rwx------ 1 root root 1351536 Oct  3 00:02 /boot/efi/EFI/Microsoft/Boot/memtest.efi
root@acerlight-laptop:/#

Now here comes the interesting part.

When this laptop is powered on, UEFI automatically "boots" the ubuntu "entry" which then shows up the GRUB2 menu and lets me select between Ubuntu and Windows 10.

If Windows 10 is selected GRUB2 launches bootmgr.efi and the system boots into Windows 10 finally.

The /boot/efi/EFI/Boot directory contains efi files for those os that are not installed permanently on the drive. For example live Ubuntu on a usb flash drive. Its the fallback boot-loader.

There is an excellent answer on unix stackexchange explaining this; you can read it here.

Switching between UEFI and Legacy BIOS mode

On most UEFI firmware based systems (the motherboards you know), its possible to switch to Legacy BIOS mode by changing configuration settings in the UEFI firmware interface.

On my desktop the Gigabyte H110M-H motherboard allows to do that.

1. UEFI-only mode - Set Windows 8/10 features to "Windows 8/10" and CSM Support to "Disabled"
2. Legacy BIOS mode - Set Windows 8/10 features to "other OS" OR Set Windows 8/10 features to "Windows 8/10" and CSM Support to "Enabled".

Here is screenshot:

*****

However switching between UEFI and UEFI+CSM mode is not possible on every system.

For instance on my Acer Swift 3 laptop, and Asus TUF A17 gaming laptop the UEFI interface does not provide any option to turn on CSM mode (Legacy BIOS).

When legacy bios is not available, you have to install all oses in UEFI mode.

The Boot Media and OS Installation

When you are launch the installation process for windows or linux via a usb flash drive for example, there are some simple things you need to keep in mind:

1. UEFI-only installation

If the installation medium is booted in UEFI mode, it will perform a UEFI install of the operating system.
It will try to write an EFI-format boot-loader to an EFI system partition, and attempt to add an entry to the UEFI boot manager 'boot menu' which loads that bootloader.

This has obvious implications. If you have booted the usb in UEFI-native mode, but the disk on the system already has some os installed in legacy mode (without the ESP partition), then then the installation process will complain about a missing EFI system partition.

This happens with ubuntu.

2. BIOS Compatibility mode

If the installation medium is booted in 'BIOS compatibility' mode, it will do a BIOS-compatible install of the operating system.
It will try to write an MBR-type bootloader to the mbr space of the boot drive.

---

If you are installing multiple OSes on the same drive, then it is important to use the same boot method for all the OSes. Either all should be UEFI, or all should be legacy bios. You cannot mix 2 different boot methods on the same drive.

However it is possible to use different boot mechanisms of the OSes are on separate drives of their own.

What is Secure Boot

Secure Boot is an optional feature of the UEFI specifications, that defines a mechanism for verifying the integrity of the boot-loaders to ensure they have not been tampered or infected by malware such as "root-kits".

There is an excellent article here that gives a super simplified explanation of how Secure Boot works or is intended to work.

Here is a brief of how Secure Boot works from that article:

Secure Boot, though, is designed to add a layer of protection to the pre-boot process. With Secure Boot active, the firmware checks for the presence of a cryptographic signature on any EFI program that it executes. If the cryptographic signature is absent, doesn't correspond to a key held in the computer's NVRAM, or is blacklisted in the NVRAM, the firmware refuses to execute the program. Of course, this is simply the start of the process; a trusted EFI boot loader must continue the boot process in a secure fashion, leading ultimately to an OS that is itself secure. A malware author would need to get the malware signed, which would be difficult if users control their own system keys (in a secure way!). Thus, pre-boot malware can be blocked. There are a lot of ways for things to go wrong higher up the chain, but Secure Boot at least provides a foundation from which to secure the computer as a whole—at least, in theory!

Secure boot being an optional feature can often be disabled from the UEFI firmware interface. However there are devices that do not allow the user to disable it in the firmware interface.

For example my Acer Swift 3 laptop does not let me disable Secure Boot.

If you want to check if your linux system has been booted using Secure Boot or not, use the following command:

$ mokutil --sb-state
SecureBoot enabled
$

To see the list of installed security keys use the mokutil command:

$ mokutil --list-enrolled

Secure Boot is slightly confusing because of the way it uses trusted keys.

Ideally the device owner (or user) should be able to install a cryptographically signed efi boot-loader and then register the corresponding key with UEFI NVRAM and the os should boot without any problem.

Now this in the first place requires to boot the "OS INSTALLER" in non-secure mode because its running for the first time on the current system. On desktop machines this is not a problem, as we can disable Secure Boot and do it easily.

However many modern laptops come with:

1. Microsoft keys already embedded in their firmware as trusted keys.
2. No option to disable Secure Boot.

In such a scenario how would you boot say a Ubuntu live USB unless it has a efi boot-loader that is signed by Microsoft ? The answer is SHIM

SHIM is a placeholder boot-loader which is signed with the microsoft keys so that UEFI can approve it and boot it. The shim loads the actual boot-loader for the non-windows OS.

This is how live linux usbs are able to boot a live session on Secure Boot devices as well as install the OS properly.

The process is weird but works.

UEFI Firmware Secure Boot ===> Microsoft signed SHIM (verified with firmware trusted keys) ==>
==> Canonical Inc. signed GRUB loader (verified by SHIM) ===> UBUNTU Kernel (Signed by Nobody!)

To learn more about Secure Boot check out these excellent resources:

Debian Wiki on SecureBoot
Ubuntu Wiki on Secure Boot
Linux control over Secure Boot - Linux magazine article explaining Secure Boot

Links and Resources

Hopefully that was a short discussion on UEFI and BIOS, and must have helped you take things to the next level so that you can now install OS on your UEFI device more confidently.

Linux on UEFI: A Quick Installation Guide

UEFI boot: how does that actually work, then?