The current state of GPT, EFI, and Linux

December 4, 2011

I'm in the process of migrating my office machine's Linux installation from an old, small pair of disks to a newer and somewhat larger pair of disks. As part of this I have been doing a bunch of reading about the current state of PC technology as far as partitioning and booting goes, because getting new machines recently has made me clearly aware that BIOSes have come a long way from the old days.

There are two parts of the new world, GPT and (U)EFI. GPT is a new scheme for disk partitioning, replacing the MBR partition table and primary and extended partitions; UEFI is a new scheme for booting machines, replacing the old BIOS MBR booting. Booting with UEFI requires a GPT partition table as well as a UEFI-aware BIOS but the reverse is not the case; using GPT does not require booting with UEFI or a GPT-aware BIOS. There are two reasons to use GPT, either if you have a disk over 2TB or so (dealing with this is what GPT was introduced for) or if you ever want to boot from the disk using UEFI.

(UEFI booting requires GPT because the EFI boot spec says 'you find the boot files on a FAT-32 filesystem in the GPT partition with GUID <X>'. See also.)

As far as I can tell, at the moment your best option for booting Linux (if you have a choice) is still old fashioned BIOS MBR booting, not UEFI boot. Many Linux distributions are in the process of switching to Grub 2, but Grub 2's UEFI support is still apparently unreliable which leaves you using various other options which are likely to be less well-supported, and in general EFI booting in Linux is still relatively young. If you're a future-looking person you can start experimenting with UEFI booting on a UEFI-capable machine, but MBR booting is going to be the easier and better way to go for now because it's still the majority choice.

My new disks are nowhere near large enough to require GPT, but I'm going to use GPT partitioning anyways for future-proofing. My new office machine supports but doesn't require UEFI booting (and I'm happy with BIOS MBR booting). However, I seem to keep disks for quite some time so it's quite possible that I'll still be using these disks when I want (or need) to switch to UEFI booting (either due to a new machine or new versions of Linux). And if I want to boot these disks with UEFI someday, I need to partition them with GPT now and set up appropriate UEFI boot partitions.

(My current disks are now slightly more than five years old and have been transplanted between three machines. Barring disk failure I suspect that the new disks will have a similar lifespan, especially since I hate reinstalling machines from scratch.)

From what I can tell (eg from the gdisk documentation), a future-proof GPT disk partitioning scheme needs two special partitions: a BIOS boot partition (gdisk code EF02) and an EFI System Partition (gdisk code EF00), probably with the ESP as the first partition on the disk. The BIOS boot partition is used to give the MBR bootloader somewhere that's guaranteed safe to store its second stage code; the EFI System Partition is where EFI bootloaders go (and where the BIOS will find them). I'm currently planning to make these 4 Mbytes and 256 MBytes respectively. This is probably overkill for both, especially since I don't plan to multiboot several OSes on my machine.

(The gdisk documentation seems to be an excellent reference for all of this; it's been my primary source.)


Comments on this page:

From 208.54.39.156 at 2011-12-04 02:52:10:

I've noticed that most BIOSes since 2007 boot GPT disks without issue, not just MBR disks. I've yet to encounter a machine where UEFI worked well.

I'm using GPT on my ThinkPad X61t w/ SSD (partitions are aligned to 4K sectors and all that), booting w/ GRUB2. Works great. 4 MB is overkill for the BIOS boot partition; I use a little under 1 MB left over from aligning partitions. Here's my table:

$ sudo gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.1

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

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 78165360 sectors, 37.3 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): D6482B5A-574E-04BF-D56F-6825009EB825
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 78165326
Partitions will be aligned on 8-sector boundaries
Total free space is 6 sectors (3.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40            2047   1004.0 KiB  EF02  EFI System
   2            2048        16779263   8.0 GiB     EF00  EFI System
   3        16779264        57192447   19.3 GiB    0700  Linux/Windows data
   4        57192448        78165326   10.0 GiB    0700  Linux/Windows data

Yeah, I need to get around to writing this up in a series of blog posts…

Samat

From 208.54.39.156 at 2011-12-04 02:56:25:

Actually, I take that back—you do need some tricks for older BIOSes. One of them is a "hybrid" MBR. You can create one with gdisk; by default, it creates a "protective" one (as indicated in my listing above).

Samat

From 12.94.77.210 at 2011-12-05 21:07:01:

If you want some real pain, try UEFI booting across a network!

On the very expensive blade servers I work on the network cards will do the DHCP dance and download a program. However the environment that they drop you into no longer seems to know which card did the dance, and so you have no way to get any more information, like say a configuration file from your server.

https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=670266

has some more information.

Written on 04 December 2011.
« Why I have comments here
Debuggers and two sorts of bugs »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Dec 4 01:16:37 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.