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

By | November 27, 2022

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.

* BIOS UEFI
Interface Text Based GUI based
Partition Table Format MBR GPT
Stage 1 boot-loader (Initial Boot Code) MBR bootstrap code area .efi files in EFI directory
Input Device Support Keyboard Keyboard, Mouse
Bit-ness 16-bit only 32/64 bit
Multiple Boot-loader NO YES

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.

Gigabyte H110M-H UEFI Interface

Gigabyte H110M-H UEFI Interface

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".

Ubuntu Live USB with UEFI and GPT

Ubuntu Live USB with UEFI and GPT

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.

Fedora Live USB with MBR and EFI System Partition

Fedora Live USB with MBR and EFI System Partition

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.

Ubuntu live USB - Rufus Iso Image mode

Ubuntu live USB - Rufus Iso Image mode

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:

Ubuntu Live USB - Rufus DD Image Mode

Ubuntu Live USB - Rufus DD Image Mode

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.

Ubuntu MBR Install with UEFI CSM

Ubuntu MBR Install with UEFI CSM

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
[email protected]:~$
$ 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.

[email protected]:/# 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
[email protected]:/#

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.

[email protected]:/# 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
[email protected]:/#

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.

[email protected]:/# 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
[email protected]:/#

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

Partition Table Formats - MBR vs GPT

Now that we have discussed enough about UEFI and BIOS, its time to look at another important aspect of this story, which is the partition table format. MBR and GPT are the important partition schemes.

They basically define data structure formats that hold partition information on the drive. Without the partition information in place, the system would not know where a partition ends and where does the next one begin.

Check the partition table scheme (MBR/GPT)

On Linux there are couple of commands to check that, however to make it easier, just run Gparted and select the drive of interest and it will show the partition table type on the left side "Device Information" column. For MBR it will show "msdos" and for GPT it will show gpt.

On Windows you can use the Gparted tool or Disk Manager application:

To view the partition scheme of your storage devices on linux, you can the "parted -l" command or the "lsblk" command. Here is the output of lsblk command on my Ubuntu desktop which has couple of external ssds and usb drives connected:

$ lsblk -e7 -o "NAME,PTTYPE,FSTYPE,SIZE,LABEL,PARTLABEL,PATH,PHY-SEC,VENDOR"
NAME   PTTYPE FSTYPE    SIZE LABEL              PARTLABEL PATH      PHY-SEC VENDOR
sda    dos            111.8G                              /dev/sda      512 ATA
└─sda1 dos    ext4     95.4G                              /dev/sda1     512
sdb    dos            111.8G                              /dev/sdb      512 ATA
└─sdb1 dos    ext4     95.8G                              /dev/sdb1     512
sdc    gpt            447.1G                              /dev/sdc      512 ATA
└─sdc1 gpt    ext4      400G                              /dev/sdc1     512
sdd    dos            465.8G                              /dev/sdd      512 Samsung
└─sdd1 dos    ext4      420G                              /dev/sdd1     512
sdf    dos             14.6G                              /dev/sdf      512 SanDisk
└─sdf1 dos    vfat     14.6G UBUNTU 22_1                  /dev/sdf1     512
sdg    gpt    iso9660  28.9G Ubuntu 22.10 amd64           /dev/sdg      512 hp
├─sdg1 gpt    iso9660   3.8G Ubuntu 22.10 amd64 ISO9660   /dev/sdg1     512
├─sdg2 gpt    vfat      4.2M ESP                Appended2 /dev/sdg2     512
└─sdg3 gpt              300K                    Gap1      /dev/sdg3     512
$

The PTTYPE column value when "dos" indicates MBR partition style, and when "gpt" indicates the GPT style partiton table.

MBR - The legacy partition scheme

MBR is the old partitioning scheme that has been used traditionally on most pc and laptops whether windows or linux based. It is being succeeded by the newer GPT that comes as a part of the UEFI parcel.

The mbr partition table supports a max of 4 primary partitions. The "extended" partition that we used to create in old days was just a special primary partition containing further child partitions call logical partitions.

1. 4 Primary
2. 3 Primary + 1 Extended Partition (with multiple Logical partitions)

MBR is limited in many ways, and the most important drawbacks are:

1. The address length is only 32 bits. So MBR can access only upto 2^32 x 512 bytes = 2 TiB (2.2 TB ) of drive space.
2. The boot-loader area can hold only about 446 bytes of data which makes it difficult to install feature-rich boot-loaders like grub in the mbr.
3. Not possible to have more than 4 primary partitions. The workaround is to have 3 primary + 1 extended and then use the extended one to house multiple logical partitions.
4. Lack of safety and security mechanisms.

MBR is the default compliant partition table that works with BIOS (or legacy BIOS) based systems.

OS installations

On MBR based drive, the first 446 bytes contain the executable bootstrap code (also called the Stage 1 boot-loader).

This boot-loader executes and loads the Stage 2 boot-loader which resides in /boot/grub for example.

On GRUB based linux installations MBR boot-loader contains the executable code from the file "boot.img".

It is important to note that MBR based os installation drives will work with both legacy BIOS as well as UEFI "bios". However there is a catch.

Linux can work with UEFI + MBR drive.
Windows 10 cannot work with UEFI "bios" + MBR drive, but Windows 10 can work with Legacy Bios + MBR drive.

Reading the MBR

If you are curious enough and want to see how the MBR looks on your os boot drive here are some ways to do it on linux. You can simply dump the raw contents of the boot drive taking only 512 bytes (that is 1 sector and the total size of MBR)

Here is how it looks on my system.

$ sudo hd -n 512 /dev/sda
00000000  eb 63 90 10 8e d0 bc 00  b0 b8 00 00 8e d8 8e c0  |.c..............|
00000010  fb be 00 7c bf 00 06 b9  00 02 f3 a4 ea 21 06 00  |...|.........!..|
00000020  00 be be 07 38 04 75 0b  83 c6 10 81 fe fe 07 75  |....8.u........u|
00000030  f3 eb 16 b4 02 b0 01 bb  00 7c b2 80 8a 74 01 8b  |.........|...t..|
00000040  4c 02 cd 13 ea 00 7c 00  00 eb fe 00 00 00 00 00  |L.....|.........|
00000050  00 00 00 00 00 00 00 00  00 00 00 80 01 00 00 00  |................|
00000060  00 00 00 00 ff fa 90 90  f6 c2 80 74 05 f6 c2 70  |...........t...p|
00000070  74 02 b2 80 ea 79 7c 00  00 31 c0 8e d8 8e d0 bc  |t....y|..1......|
00000080  00 20 fb a0 64 7c 3c ff  74 02 88 c2 52 bb 17 04  |. ..d|<.t...R...|
00000090  f6 07 03 74 06 be 88 7d  e8 17 01 be 05 7c b4 41  |...t...}.....|.A|
000000a0  bb aa 55 cd 13 5a 52 72  3d 81 fb 55 aa 75 37 83  |..U..ZRr=..U.u7.|
000000b0  e1 01 74 32 31 c0 89 44  04 40 88 44 ff 89 44 02  |[email protected]|
000000c0  c7 04 10 00 66 8b 1e 5c  7c 66 89 5c 08 66 8b 1e  |....f..\|f.\.f..|
000000d0  60 7c 66 89 5c 0c c7 44  06 00 70 b4 42 cd 13 72  |`|f.\..D..p.B..r|
000000e0  05 bb 00 70 eb 76 b4 08  cd 13 73 0d 5a 84 d2 0f  |...p.v....s.Z...|
000000f0  83 d0 00 be 93 7d e9 82  00 66 0f b6 c6 88 64 ff  |.....}...f....d.|
00000100  40 66 89 44 04 0f b6 d1  c1 e2 02 88 e8 88 f4 40  |@[email protected]|
00000110  89 44 08 0f b6 c2 c0 e8  02 66 89 04 66 a1 60 7c  |.D.......f..f.`||
00000120  66 09 c0 75 4e 66 a1 5c  7c 66 31 d2 66 f7 34 88  |f..uNf.\|f1.f.4.|
00000130  d1 31 d2 66 f7 74 04 3b  44 08 7d 37 fe c1 88 c5  |.1.f.t.;D.}7....|
00000140  30 c0 c1 e8 02 08 c1 88  d0 5a 88 c6 bb 00 70 8e  |0........Z....p.|
00000150  c3 31 db b8 01 02 cd 13  72 1e 8c c3 60 1e b9 00  |.1......r...`...|
00000160  01 8e db 31 f6 bf 00 80  8e c6 fc f3 a5 1f 61 ff  |...1..........a.|
00000170  26 5a 7c be 8e 7d eb 03  be 9d 7d e8 34 00 be a2  |&Z|..}....}.4...|
00000180  7d e8 2e 00 cd 18 eb fe  47 52 55 42 20 00 47 65  |}.......GRUB .Ge|
00000190  6f 6d 00 48 61 72 64 20  44 69 73 6b 00 52 65 61  |om.Hard Disk.Rea|
000001a0  64 00 20 45 72 72 6f 72  0d 0a 00 bb 01 00 b4 0e  |d. Error........|
000001b0  cd 10 ac 3c 00 75 f4 c3  03 46 01 00 00 00 80 20  |...<.u...F..... |
000001c0  21 00 83 fe ff ff 00 08  00 00 00 b8 eb 0b 00 00  |!...............|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200

Or use the command

dd if=/dev/sda bs=512 count=1 | hexdump -C

The boot-loader code present in the mbr actually comes from the boot.img file inside grub. You might want to take a look at that as well:
On my system the file is located at /boot/grub/i386-pc/boot.img

Read the boot.img

[email protected]:/boot/grub/i386-pc$ sudo hd -n 512 boot.img
00000000  eb 63 90 00 00 00 00 00  00 00 00 00 00 00 00 00  |.c..............|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000050  00 00 00 00 00 00 00 00  00 00 00 80 01 00 00 00  |................|
00000060  00 00 00 00 ff fa eb 05  f6 c2 80 74 05 f6 c2 70  |...........t...p|
00000070  74 02 b2 80 ea 79 7c 00  00 31 c0 8e d8 8e d0 bc  |t....y|..1......|
00000080  00 20 fb a0 64 7c 3c ff  74 02 88 c2 52 bb 17 04  |. ..d|<.t...R...|
00000090  f6 07 03 74 06 be 88 7d  e8 17 01 be 05 7c b4 41  |...t...}.....|.A|
000000a0  bb aa 55 cd 13 5a 52 72  3d 81 fb 55 aa 75 37 83  |..U..ZRr=..U.u7.|
000000b0  e1 01 74 32 31 c0 89 44  04 40 88 44 ff 89 44 02  |[email protected]|
000000c0  c7 04 10 00 66 8b 1e 5c  7c 66 89 5c 08 66 8b 1e  |....f..\|f.\.f..|
000000d0  60 7c 66 89 5c 0c c7 44  06 00 70 b4 42 cd 13 72  |`|f.\..D..p.B..r|
000000e0  05 bb 00 70 eb 76 b4 08  cd 13 73 0d 5a 84 d2 0f  |...p.v....s.Z...|
000000f0  83 d0 00 be 93 7d e9 82  00 66 0f b6 c6 88 64 ff  |.....}...f....d.|
00000100  40 66 89 44 04 0f b6 d1  c1 e2 02 88 e8 88 f4 40  |@[email protected]|
00000110  89 44 08 0f b6 c2 c0 e8  02 66 89 04 66 a1 60 7c  |.D.......f..f.`||
00000120  66 09 c0 75 4e 66 a1 5c  7c 66 31 d2 66 f7 34 88  |f..uNf.\|f1.f.4.|
00000130  d1 31 d2 66 f7 74 04 3b  44 08 7d 37 fe c1 88 c5  |.1.f.t.;D.}7....|
00000140  30 c0 c1 e8 02 08 c1 88  d0 5a 88 c6 bb 00 70 8e  |0........Z....p.|
00000150  c3 31 db b8 01 02 cd 13  72 1e 8c c3 60 1e b9 00  |.1......r...`...|
00000160  01 8e db 31 f6 bf 00 80  8e c6 fc f3 a5 1f 61 ff  |...1..........a.|
00000170  26 5a 7c be 8e 7d eb 03  be 9d 7d e8 34 00 be a2  |&Z|..}....}.4...|
00000180  7d e8 2e 00 cd 18 eb fe  47 52 55 42 20 00 47 65  |}.......GRUB .Ge|
00000190  6f 6d 00 48 61 72 64 20  44 69 73 6b 00 52 65 61  |om.Hard Disk.Rea|
000001a0  64 00 20 45 72 72 6f 72  0d 0a 00 bb 01 00 b4 0e  |d. Error........|
000001b0  cd 10 ac 3c 00 75 f4 c3  00 00 00 00 00 00 24 12  |...<.u........$.|
000001c0  0f 09 00 52 be bd 7d 31  c0 cd 13 46 8a 0c 84 c9  |...R..}1...F....|
000001d0  75 0f be da 7d e8 da ff  eb a4 46 6c 6f 70 70 79  |u...}.....Floppy|
000001e0  00 bb 00 70 8e c3 31 db  b8 01 02 b5 00 b6 00 cd  |...p..1.........|
000001f0  13 72 d4 b6 01 b5 4f e9  ff fe 00 00 00 00 55 aa  |.r....O.......U.|
00000200
[email protected]:/boot/grub/i386-pc$

Note how similar they look.

GPT drive based OS installations

GPT is the new-age partition table scheme that overcomes the limitations of mbr. GPT is also a part of the "UEFI technology" package and is recommended for most modern system, but it is NOT a strict requirement.

You can have UEFI (Legacy BIOS mode/CSM) + MBR drive for os installation. Linux supports this, but not Windows 10.
You can have UEFI (Legacy BIOS mode/CSM) + GPT drive for os installation.

You can have UEFI + GPT drive for os installation. This is the modern recommended approach.

Can Legacy BIOS systems boot OS on a GPT drive ?

Yes, Legacy BIOS can use GPT drive to boot the OS, but it would need a dedicated BIOS Boot partition.

Old BIOS recognises only MBR and not GPT. However since GPT drives also have a "protected MBR" for backward compatibility, the mbr boot record is made to point to a dedicated BIOS-Boot partition which contains the next stage of boot loader.

On linux systems, GRUB2 stores the core.img code in BIOS-Boot partition which can be thought of as Stage 1.5 Boot-loader whose job is to prepare the system and load Stage 2 boot-loader which is at "/boot/grub".

Dual Boot Considerations

If you want to setup dual boot on your desktop or laptop using Windows 10 and Ubuntu for instance, there are certain important factors that come into play with regards to booting technologies discussed above.

Firstly all the oses on a system must be installed/configured to use the same boot methods. Either all should be BIOS+MBR or all should be UEFI/ESP based. This is because the boot process "control flow" of each technology is very different.

Take a look at this simple diagram.

Consider the following scenarios:

1. You got a Windows 10 laptop which is already pre-installed with UEFI boot, ESP and gpt partition. Now if you install Ubuntu on it, Ubuntu must also use ESP and install the GRUB boot loader in the ESP partition. You cannot use Legacy BIOS methods for booting Ubuntu.

2. If you have a desktop with Windows 10 booting with BIOS+MBR then you must install the next OS to use BIOS only. When Ubuntu uses legacy MBR based booting the GRUB boot-loader is placed in a special path "/boot" which can be on the root partition or on a separate partition.

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?

About Silver Moon

A Tech Enthusiast, Blogger, Linux Fan and a Software Developer. Writes about Computer hardware, Linux and Open Source software and coding in Python, Php and Javascript. He can be reached at [email protected].

Leave a Reply

Your email address will not be published. Required fields are marked *