Difference between Legacy BIOS and UEFI

Question

Why are the terms MBR and GPT associated with Legacy BIOS and UEFI respectively?

Answer 1

The older BIOS (Basic Input/Output System) and its modern replacement UEFI (Unified Extensible Firmware Interface) can both be seen as the "firmware" of your computer.

They are stored directly on the mainboard and are the first software that is run on your computer when it is powered on. Their main job is to initialize all connected hardware and load the actual operating system's (e.g. Ubuntu or Windows) boot loader (e.g. GRUB) from the hard disk, which then starts the OS.

Most UEFI systems also support CSM (Compatibility Support Module) booting, which emulates a Legacy BIOS interface.

While Legacy BIOS boot simply and stupidly reads and executes code from a fixed address off the disk (part of the Master Boot Record), UEFI boot searches for EFI boot files in an EFI system partition and executes one of those.

---

The older MBR (Master Boot Record) and newer GPT (GUID Partition Table; GUID = Global Unique Identifier) are partition table formats.

Your hard disk is partitioned in either of these two formats. The older MBR format allows only 4 primary partitions on the whole disk (although one of them may be used as extended partition and contain many logical volumes), whereas GPT doesn't have this restriction and also supports larger disks.

GPT partitioned disks may also contain a hybrid MBR with boot code able to load the EFI files in order to support both UEFI and Legacy BIOS boot modes.

---

So why are BIOS and MBR associated with each other, as well as UEFI with GPT?

Well, apart from BIOS/MBR being the ancestors of today's modern UEFI/GPT, they are also normally used together. Some operating systems (like Windows) even only support booting MBR disks in BIOS mode and GPT disks in UEFI mode. Linux systems with e.g. GRUB generally have no problems with mixing those either way.

Answer 2

Legacy (CSM) booting vs UEFI booting

SuperUser has a highly-upvoted post from 2012 on OP's question that many will find helpful.

CSM (Legacy) and UEFI (Universal Extensible Firmware Interface) are mutually exclusive boot options you choose within BIOS (Basic Input Output System). BIOS applies to much more than legacy (CSM) booting:

• Disk boot format: Legacy (CSM) vs. UEFI
• Disk boot order: hard disk, SSD, USB, NIC (Network Interface Card)
• Disk low level operations: RAID vs AHCI
• USB ports: wake up on input, powered when system off, etc.
• Multiple Graphic Cards: enable/disable Intel or nVidia
• System date and time stored on RTC (Real Time Clock)
• Optional hardware POST (Power On Self Test) checks
• Many other BIOS options that vary depending on computer

Great answers have already been posted by Byte and Ravery here, so I would just summarize:

• Legacy (CSM) and UEFI are different ways to boot from storage disks (which often take the form of SSD these days).
• CSM uses an MBR (Master Boot Record) in a specific format of 512 Bytes to boot the operating system.
• UEFI uses files within a large partition (typically 100 MB) to boot the operating system. Typically they still require the MBR to be present.
• MBR and GPT are different specifications for disk partition formatting. You can have UEFI boot on an MBR formatted disk. You can have MBR boot on a GPT formatted disk (in non-Windows environments).
• The MBR (first 512 bytes of a disk) is typically hidden from user view.
• The EFI partition can be easily viewed, as shown below

It is important to note ambiguities that MBR can refer to disk booting method or disk partition format.

It is also important to note that UEFI is often associated with GPT disk format but MBR booting can use GPT disk format.

Viewing the EFI partition

Using lsblk you can see EFI partition and files:

$ lsblk -o NAME,FSTYPE,LABEL,MOUNTPOINT,SIZE,MODEL
NAME        FSTYPE LABEL            MOUNTPOINT   SIZE MODEL
sda                                            931.5G HGST HTS721010A9
├─sda4      ntfs   WINRETOOLS                    450M 
├─sda2                                           128M 
├─sda5      ntfs   Image                        11.4G 
├─sda3      ntfs   HGST_Win10       /mnt/d       919G 
└─sda1      vfat   ESP                           500M 
nvme0n1                                          477G Samsung SSD 960 PRO 512GB           
├─nvme0n1p5 ext4   NVMe_Ubuntu_16.0 /           44.6G 
├─nvme0n1p3                                       16M 
├─nvme0n1p1 ntfs                                 450M 
├─nvme0n1p6 swap   Linux Swap       [SWAP]       7.9G 
├─nvme0n1p4 ntfs   NVMe_Win10       /mnt/c     414.9G 
├─nvme0n1p2 vfat                    /boot/efi     99M 
└─nvme0n1p7 ntfs   Shared_WSL+Linux /mnt/e         9G 

There are many files in /boot/efi you can see using ls command. To see the size of all files within the 99MB partition use:

$ du -hs /boot/efi
35M /boot/efi

gdisk Information

Whilst researching this answer I found a link to the gdisk command which I ran and may regret when I boot into Windows again. This is here so you don't repeat this if it turns out to be a mistake for Windows dual-boot:

sudo gdisk -l /dev/sda
[sudo] password for rick:          
GPT fdisk (gdisk) version 1.0.1

The protective MBR's 0xEE partition is oversized! Auto-repairing.

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 1953525168 sectors, 931.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 8BEC7AEB-4576-42B0-8A8A-D40779A80126
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 2048-sector boundaries
Total free space is 3437 sectors (1.7 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1026047   500.0 MiB   EF00  EFI system partition
   2         1026048         1288191   128.0 MiB   0C01  Microsoft reserved ...
   3         1288192      1928626175   919.0 GiB   0700  Basic data partition
   4      1928626176      1929547775   450.0 MiB   2700  
   5      1929547776      1953523711   11.4 GiB    2700  

I will reboot into Windows 10 and see if Linux gdisk had any ramifications of repairing the Windows hard drive D: which is /dev/sda in my Linux setup. I'm not concerned because it's the original Hard Drive I haven't used yet but you should be careful if it has data on it. I'll update this section after rebooting and testing.

Answer 3

MBR is a disk partitioning scheme used by the old firmware (BIOS). At the time of it's development, drives were very small. As drives got larger, the MBR standard was "patched" to accommodate; however, there are many limitations. Legacy Boot can not read GPT partitioning because it is not build into the BIOS. This limitation only applies to BIOS; see the note below about bootloaders.

As EFI was developed, they also developed a new partitioning scheme (GPT) that makes better use of large drives. EFI Firmware can read and use MBR partitioned disks, but usually a factory install will use the better GPT partitioning.

Note:

• Some OSs, such as Win10, will require GPT partitioning for an EFI install even though the EFI firmware does not require it.
• Although, the EFI standard doesn't require GPT, specific implementations may. Some computers will automatically drop to Legacy support mode if it encounters an MBR disk.
• Some boot loaders, like GRUB, can put a BIOS Partition (MBR) on a GPT disk. BIOS can read this partition and load the bootloader. Once the bootloader is loaded, the bootloader can read the GPT partitions.