What is the absolute minimum size a UEFI system partition can be?

Question

Suppose I have a flash drive, and I want it to be bootable. Suppose I also have a basic EFI file which will accomplish something. So, what is the minimum size the ESP can be? I've read that it's 100MB, but that seems to be specifically in regards to Windows. Must an EFI partition be a certain size for the system to recognize it? Or is 100 just recommended because modern operating systems use that much?

Answer 1

Is 100 just recommended because modern operating systems use that much?

Note that the 100 MB partition size is the minimum. Though there is no specification set by UEFI for a minimum size, but Microsoft recommends this 100 MB size for it's Operating Systems.

Let's think we need the EFI partition to be formatted using the FAT32 file system. The minimum partition size of FAT32 drive is calculated as sector_size x 65527.

In Advanced Format 4K Native drives, there is 4 KB per sector. In that case, the minimum partition size for FAT32 drive is calculated as 4 KB x 65527 = 256 MB. That's why recommended minimum size for 4K drives is 260 MB.

But in Advanced Format 512e drives, the emulated sector size is 512 bytes. In that case, the minimum partition size for FAT32 drive is calculated as 512 bytes x 65527 = 32 MB, which is less than the 100 MB minimum size for this partition.

Must a EFI partition be a certain size for the system to recognize it?

Though Microsoft recommends 100 MB for its operating systems, the Linux forums suggest more for Linux based operating systems or for any dual boot or multi booting situations.

The author of gdisk suggests 550 MiB.

As per the Arch Linux forum, to avoid potential problems with some EFIs, ESP size should be at least 512 MiB. 550 MiB is recommended to avoid MiB/MB confusion and accidentally creating FAT16.

So, most common size guideline for EFI System Partition is between 100 MB to 550 MB. One of the reason behind this is it is difficult to resize later as it is the first partition on the drive. EFI partition may contain languages, fonts, BIOS firmware, other firmware related stuffs. There are some firmware/software that are installed into the the EFI partition instead of the data drive. And there are some that want the capability in the future to add things into ESP.

As it may be difficult to enlarge the size in case it is needed later and the Hard Disk size now a days is larger, a big number of size like 100 MB or 550 MB is recommended for ESP. But in general case, it uses only some Kilo Bytes of space.

Suppose I have a flash drive, and I want it to be bootable.

Though it is not clear from your statement, if you try to make your pen drive bootable as UEFI compatible drive for windows installation, then there is no need of creating extra ESP in the pen drive. Use rufus or similar tools which will take care of converting it into UEFI enabled drive. But ESP is needed in your hard drive when installing windows into that drive.

Answer 2

The absolute minimum size you can get away with, involves using a fat12 filesystem (so 32 KB), and in practice requires using some minimal boot manager that incorporates filesystem drivers for reading your primary partition -- and the kernel contained there -- which implies grub or rEFInd. A typical grub-install image will be around 200KB, which is still not bad at all.

I've been booting just fine with a 2MB fat12 ESP for quite some time now, so clearly it can be done!

I'm not entirely sure where the common advice to use 512MB comes from, but the Arch Wiki was recently amended by... me... to reference the possibility of fat12.

http://www.rodsbooks.com/linux-uefi/ seems to indicate at least fat16 should work fine except for confusing the Windows installer, which is not really relevant IMHO. The Arch Wiki seems to have based itself on that advice, but I'm not brave enough to totally rewrite it.

As I referenced in the Wiki, the UEFI spec mandates fat12 drivers. I've heard arguments that "only removable drives are mandated", leaving open the possibility that someone, somewhere, has or will write a UEFI implementation that includes those fat12 filesystem drivers but somehow forbids their use for mounting the UEFI system partition, but I personally consider this unlikely.

Answer 3

For Linux, in terminal, run sudo fdisk -l to find out the sector size of your storage drive.

Since the EFI partition is formatted as FAT32, the minimum partition size of FAT32 drive is calculated as sector_size x 65527. For modern storage that is 512 bytes x 65527 = 32 MiB. The EFI boot manager executable is around 125 KiB, so the 32 MiB minimum is more than necessary for the EFI partition size. There are other arguments for larger sizes, but unless you run in those particular situations, larger is not necessary.

Answer 4

@Original poster: You want to know the minimum required size of an EFI partition, but you failed to state, what OS you have in mind. There's no single requirement. Reading information on the internet, some people say "2 mb" (above), while others suggest terrabytes of space. I suggest everybody writes the minimum requirement for their own system, then we'd have a nice list of all OS requirements. So let me answer your question concerning the Debian OS:

uname -r

5.10.0-6-amd64

uname -a

Linux localhost 5.10.0-6-amd64 #1 SMP Debian 5.10.28-1 (2021-04-09) x86_64 GNU/Linux

and Windows 10:

ver

Microsoft Windows [Version 10.0.19042.804]

Now, when installing Debian, I wanted to know the size needed for the EFI partition. That's how I found this page, except the info provided here is not helpful. So I am like, 5mb is enough? Turns out the Debian installer has a minimum requirement of 35mb.

Note that if you partition the EFI partition with fdisk first, then try to install Debian, it will refuse with a cryptic error message:

The attempt to mount a file system with type vfat in SCSII (0,0,0), partition #1 (sda) at /boot/efi failed.

If you compare the flags set by fdisk and the Debian installer (if you allow it to partition):

fdisk -> "B K"

Debian -> "B f"

Re-select the EFI partition inside the Debian installer to fix the flags. Stupid Debian.

Also, when using fdisk inside Hyper-V, you can't get the damn list of partition hex codes to show, because enhanced mode (VmConnect) is not working, SSH is not installed, so the hex codes list output by fdisk just flies by, and there's no way to scroll the VmConnect window up. In VMWare Workstation this works by SHIFT+PageUp, but I can't find out how to do this in Hyper-V, in fact, nobody even posed this question! So I finally found out, EFI partition is "1" in fdisk.

Anyhow, is the amount of space required by the Debian installer REALLY needed? After installing Debian, I checked the actually required space:

mount /dev/sda1 /mnt

cd /mnt

du -hs

/efi/debian
    -rwx------ 1 root root    1K 27. Apr 00:11 BOOTX64.CSV
    -rwx------ 1 root root 1180K 27. Apr 00:11 fbx64.efi
    -rwx------ 1 root root    1K 27. Apr 00:11 grub.cfg
    -rwx------ 1 root root 1634K 27. Apr 00:11 grubx64.efi
    -rwx------ 1 root root 1233K 27. Apr 00:11 mmx64.efi
    -rwx------ 1 root root 1292K 27. Apr 00:11 shimx64.efi

5,3M

5,3M! You have the nerve to suggest 550mb, a gigabyte, 10 terrabytes, any more bids?! Some people will say, the grub boot loader is situated on the EFI partition, others say "update-initramfs" will write to this partition, that's why so much space is required. Bullshit, all of it!

But, alas, damage done, and now I have to deal with it.

mount /dev/sda1 /mnt

cp -r /mnt/EFI /work

umount /dev/sda1

blkid

/dev/sda1: UUID="6995-68F6" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="a7196942-ec1b-e64a-9182-009a28d2cc44"

gdisk /dev/sda
d 1
n 1
+5466KB
EF00
w

umount /dev/sda1

mkfs.fat /dev/sda1

mount /dev/sda1 /mnt

mv /work/EFI /mnt

umount /dev/sda1

Fix the PARTUUID:

partprobe /dev/sda

blkid

gdisk /dev/sda

x
c (1) -> set the old PARTUUID (a7196942-ec1b-e64a-9182-009a28d2cc44 in my example)

fix the UUID in fstab:

nano /etc/fstab -> set the new UUID

Why "mkfs.fat" (above), and not "mkfs.fat -F32"? That's why:

https://github.com/dosfstools/dosfstools/blob/master/src/mkfs.fat.c

According to Microsoft FAT specification (fatgen103.doc) disk with 65525 clusters (or more) is FAT32

define MIN_CLUST_32 65525

diskpart will refuse to format as fat32 as well:

format fs=fat32 quick

Volume too small

So, 30mb of space saved, yet unallocated. How to allocate? Running fdisk, deleting the ext4 partition and recreating it including the unallocated space (d n, everything default) results in an unbootable system. On the net, they will tell you, extending a partition by the unallocated space BEFORE this partition is not possible, the raw space needs to be moved to the end of the harddisk, then extended. How to move the unallocated space to the end? No idea. Tried fdisk, gdisk, parted, MS diskpart. Can't find out. So I finally downloaded "gparted-live-1.2.0-1-amd64.iso". gParted was capable to extend the ext4 partition by the unallocated space, except it left 1mb space at the end of the hard disk. On the internet, they will tell you, this is done according to specifications. Really? Interesting then that fdisk does NOT leave this megabyte at the end, nor does Microsoft's diskpart when extending a partition. Somebody on the internet said, "it's just 1 megabyte and you don't want to violate the specifications to save it." I will save this poor megabyte, even if I have to trample on all specifications out there! Don't worry, poor neglected megabyte, I'll save you!

So I tricked gParted, hehe. I moved the unallocated space to the end of the disk, without allocating it. Then I closed gParted and used fdisk instead to extend the ext4 partition, and it assigned ALL space to it, including the poor megabyte:

fdisk /dev/sda

F
    Start   End     Sectors Size
    14336   73727   59392   29M

d 2
n 2 14336

fdisk -l

Device     Start      End  Sectors  Size Type
/dev/sda1   2048    12979    10932  5,3M EFI System
/dev/sda2  14336 20971486 20957151   10G Linux filesystem

About Windows. So MS says, 100 MB efi + 16 mb msr. And of course, the notorious copypasters, who always copy paste info without checking it spread this misinformation all over the internet. But is this amount of space really necessary? Let's take a look at what resides in the EFI partition:

 Verzeichnis von B:\efi\boot

    1.558.344 bootx64.efi

Verzeichnis von B:\efi\microsoft\boot

    28.672 bcd

Verzeichnis von B:\efi\microsoft\boot\fonts

    48.992 wgl4_boot.ttf

Anzahl der angezeigten Dateien:
           3 Datei(en), 1.636.008 Bytes

I print out the listing just for you, I know what's there, since I put the files there myself, when dism-restoring a Windows image to an EFI machine (the image was created by dism on an MBR machine). It's nearly impossible to find out, which files are actually needed. By trial and error, I found out, you just need the 3 (above)

diskpart

select disk 0

select partition 1

assign letter b

mkdir b:\efi
mkdir b:\efi\boot
mkdir b:\efi\microsoft
mkdir b:\efi\microsoft\boot
mkdir b:\efi\microsoft\boot\fonts

copy c:\windows\boot\efi\bootmgfw.efi b:\efi\boot\bootx64.efi

copy c:\windows\boot\fonts\wgl4_boot.ttf b:\efi\microsoft\boot\fonts

The bcd store you have to create yourself, I won't go into details here, then:

copy X:\bcd b:\efi\microsoft\boot

So 1.636.008! Microsoft said, 116mb? And this information got copypasted all over the internet. I followed those instructions first, the idiot that I am, but now I wanted to see if the sizes required by MS are ACTUALLY required (as in making Windows unbootable):

dism /Capture-Image /ImageFile:c:\copy\efi.wim /CaptureDir:b:\ /Name:efi /Compress:fast

diskpart

select disk 0

select partition 0

delete partition override
    efi killed

select partition 1

delete partition override
    msr killed

create partition efi size=2

format fs=fat quick

assign letter b

dism /Apply-Image /ImageFile:c:\copy\efi.wim /Index:1 /ApplyDir:b:\

Cross your fingers, I am going for a reboot! Houston, reporting successful takeoff of the Windows rocket!... Houston, reporting successful Windows boot and account login! Houston, Microsoft are a bunch of damn liars!

So we saved 114 mb, but this space is unallocated.

diskpart?

Hahaha!

diskmgmt.msc

Hahaha Hahaha!

Then what? gParted again, I guess. Not exactly a good idea to use a linux programme to mess with an NTFS partition, but let's try it. So I moved the unallocated space to the end of the harddisk. Works. Rebooted Windows from the dvd again (virtual dvd with a mounted ISO in my case, since I was doing this in Hyper-V), then:

diskpart

select disk 0

select partition 1

extend

Done.

list partition

Partition ###  Typ               Größe    Offset
-------------  ----------------  -------  -------
Partition 1    System            2048 KB  1024 KB
Partition 2    Primär              39 GB  3072 KB

select partition 1

detail partition

Volume ###  Bst  Bezeichnung  DS     Typ         Größe    Status     Info
----------  ---  -----------  -----  ----------  -------  ---------  --------
* Volume 1                      FAT    Partition   2048 KB  Fehlerfre  System

But what if you wanted to delete the EFI and MSR partitions through linux tools? I don't know why, but doing this results in an unbootable Windows system. I passed exactly the same parameters to gdisk/fdisk/parted as I did to diskpart, yet all these tools break something! Deleting the MSR partition in diskpart:

select partition 1

delete partition override

Reboot, Windows boots.

Same damn thing in gdisk!:

gdisk /dev/sda

d (select msr partition)
w

Reboot, I get the damn Hyper-V logo in my face, sitting there for ever, system not booting. Reason?