EFI SYSTEM PARTITION should be atleast 100 MiB size and formatted as FAT32, not FAT16

[Keshav Amburay]

Create a EFI SYSTEM PARTITION of minimum 100 MiB size (200 MiB recomended). Also partman-efi should use FAT32 instead of FAT16 for EFI SYSTEM PARTITION as mandated by the UEFI 2.3.1 Spec. FAT16 ESP partition is not recognised by Windows 7 UEFI bootloader because of this.

The below quote is copied form the UEFI Specification 2.3.1 - Chapter 12.3 File System Format.

[QUOTE]
EFI encompasses the use of FAT32 for a system partition, and FAT12 or FAT16 for removable media. The FAT32 system partition is identified by an OSType value other than that used to identify previous versions of FAT. This unique partition type distinguishes an EFI defined file system from a normal FAT file system. The file system supported by EFI includes support for long file names.

FAT defines that all files in a directory must have a unique name, and unique is defined as a case insensitive match.

UEFI does not impose a restriction on the number or location of System Partitions that can exist on a system. System Partitions are discovered when required by UEFI firmware by examining the partition GUID and verifying that the contents of the partition conform to the FAT file system as defined in Section 12.3.1.1. Further, UEFI implementations may allow the use of conforming FAT partitions which do not use the ESP GUID. Partition creators may prevent UEFI firmware from examining and using a specific partition by setting bit 1 of the Partition Attributes (see 5.3.3) which will exclude the partition as a potential ESP.
[/QUOTE]

[Keshav Amburay (keshava2015)]

Related bug : https://bugs.launchpad.net/ubuntu/+source/partman-efi/+bug/769669

[Rod Smith (rodsmith)]

This bug still exists in 11.10 beta 2 -- or at least, it still creates a FAT16 ESP. (I pre-partitioned the disk on my test install, so I don't know if the partition size issue still exists.)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Rod Smith (rodsmith)]

I recommend that the ESP's size exceed 200 MiB. The reason is that some boot loaders, such as ELILO, effectively require kernels to reside on the ESP. There's also a patch to effectively make the Linux kernel its own EFI boot loader, which would also require the kernel to reside on the ESP. If kernels go on the ESP, then the ESP's size requirements become similar to those for a separate /boot partition. An Ubuntu kernel and initial RAM disk together consume about 20 MiB, and I've seen them much bigger than this, so even a 100 MiB might not hold many kernels. (Fedora creates 500 MiB /boot partitions, as a point of comparison.)

I realize that Ubuntu uses GRUB 2 and so does not need to place kernels on the ESP; however, individual users might decide to ditch GRUB 2 in favor of ELILO or even the experimental kernel patches, and users might dual-boot with a distribution that does use ELILO, such as OpenSUSE. Note that Ubuntu includes an ELILO package in its repositories, so it's a logical boot loader for an Ubuntu user to try if GRUB 2 gives problems.

[cfr (reescf)]

I'm far from confident about this but running Ubuntu's installer on my machine finally allowed me to boot from a GPT partitioned disk. Not immediately because the installer crashed and although it wiped my EFI system partition, it didn't get around to putting anything else in it afterwards. And even when I copied my backup back, the UUIDs didn't match thus causing trouble for my intact install of linux. But at least I could get to a grub prompt after copying my backed up ESP back. That was a huge improvement. And after fixing the UUID, I have a working installation of linux. (Not of Ubuntu, obviously.)

As far as I can tell, the only thing Ubuntu's installer did which I didn't do was to use fat16 rather than fat32 to format the partition. I am almost certain that my machine would have remained unbootable if it had used fat32.

I found a reference in bug #769669 to a minimum size for the fat32 partition of 256M. That might explain why my machine was not booting. My EFI partition is only 202M. But if that is why, the installer should also insist on a partition which meets that requirement if it switches to fat32 for the EFI partition.

My machine has Phoenix SecureCore Tiano firmware. Version 1.14.

Reference: https://bbs.archlinux.org/viewtopic.php?pid=1024473#p1024473

[Allen.McIntosh (mcintosh)]

I was bitten by this issue today when I tried to install Ubuntu 11.04. There were some additional wrinkles that are worth mentioning in the context of this bug report. The machine in question is an HP Elite 8200. It comes with Windows 7 64 bit installed, and uses EFI to boot. The system disk has an MSDOS partition table. The EFI partition contains an NTFS filesystem and has an OS type consistent with that (type 7)!

If this setup is typical of HP's desktop machines, the Ubuntu install process is going to need to cope with it whether or not it is standard conforming. I don't know how many HP models are affected by this, or whose firmware is installed on the machine (it's 30 miles away at the moment). I could find out if that is useful information.

(If it makes anybody feel any better, Fedora couldn't cope either - but it refused to continue past the partitioning stage.)

[Allen.McIntosh (mcintosh)]

Regarding the EFI partition size, I forgot to mention that the factory installed EFI partition on the 8200 is 102400 blocks..

[Rod Smith (rodsmith)]

Allen, Windows ties its boot support to the partition table type, so if you have an MBR partition table, then Windows is booting in BIOS mode, not in EFI mode. It's entirely possible that the Ubuntu installer started up in EFI mode despite this, though, which could cause problems. The best (or at least simplest, if possible) solution is to find a way to boot the Ubuntu installer in BIOS mode. This might be possible by using firmware options to force a BIOS boot from the optical disc or by using UNetBootin or some similar tool to create a BIOS-bootable (but NOT EFI-bootable) medium.

An alternative solution is to convert the MBR setup to GPT, convert Windows to boot in EFI mode (in-place or by re-installing), and then install Ubuntu in EFI mode. This is likely to be a pain to do, though, particularly if you're not an expert on EFI-mode booting and installation, so I don't recommend it unless you're desperate.

As far as Ubuntu development goes, this does raise an issue: Even though the installer boots in a given mode (BIOS or EFI) does NOT necessarily mean that existing OSes are installed in that same mode. It could be very tricky for the installer to detect this and install the correct boot loader, even if that means installing the boot loader for the mode that's NOT being used.

[Adam Thompson (athompso)]

The EFI/BIOS distinction does apply to the Windows boot process, but it applies ever earlier to the computer's IPL ("initial program load" - what the CPU automatically starts executing after poweron). The presence or absence of an MBR structure has no effect on whether a computer loads a legacy BIOS or EFI-style firmware at IPL - it is purely and entirely controlled by what code is present in ROM at (real-mode) address F000:FFF0 at the instant the CPU is powered on.
During a typical Ubuntu installation, what Windows thinks is happening during the boot process becomes completely irrelevant, although if Ubuntu and Windows arrive at different conclusions then yes, major brain-damage can occur.

As to the Allen's hardware, multiple independent sources confirm that HP is, indeed, shipping UEFI-capable systems with a valid MBR *with* an EFI boot partition. Yes, that's stupid, but given that I haven't seen a single vendor (neither software nor hardware) ship a UEFI-based system that's actually 100% UEFI-compliant, I'm not surprised. I've heard anectodal reports of other OEMs shipping similar stupidity, HP's sadly not alone. This seems to go hand-in-hand with "legacy-enabled UEFI" firmware, which - I think, I don't have any examples on hand to check right now - boots off an EFI-ish boot partition if one is present, even on a non-GPT disk.

I would refactor Allen's request to be simpler: Ubuntu needs to be *MUCH* more flexible when dealing with UEFI (and partial-UEFI, and hybrid) systems, because the real world doesn't seem to actually conform the UEFI spec. Not to mention that Ubuntu doesn't currently conform the UEFI spec, either, which is a problem unto itself.

The GPT specification *requires* a Protective MBR, and in all implementations found "in the wild" today, any GPT disk will/must/should have a valid MBR structure at LBA sector #0. The assertion that the presence of an MBR causes Windows to "boot in BIOS mode" is both untrue in my experience and impossible according to the GPT specification. That decision point comes much later, and as of at least Win7 x64 (possibly earlier, not sure), the MBR boot process is very, very similar to the EFI boot process: even MBR systems get a small boot partition.

Thanks to HP, it's entirely possible that Allen's system does not have a GPT disk yet still uses UEFI firmware to boot; that situation is no longer impossible.

Regardless, we all agree that Ubuntu's handling of UEFI+GPT systems leaves a lot to be desired. I can't imagine that it's handling of some of the newer hybrid-UEFI or UEFI+MBR systems out there will be any better!

[Rod Smith (rodsmith)]

Adam, you've misread my comment about Windows and MBR. Allow me to rephrase: When booted in BIOS mode, Windows will only install to or boot from an MBR partition table (normally without a GPT, although Windows treats hybrid MBR disks as MBR disks); and when booted in EFI mode, Windows will only install to or boot from a GPT disk (WITHOUT any MBR entries except for the type-0xEE protective entry). Thus, if a disk has an MBR with non-0xEE partitions defined, as Allen reported, and if it's successfully booting Windows, then it follows logically that Windows is booting in BIOS mode on that computer, not in EFI mode, since Windows will not boot in EFI mode from an MBR disk (AFAIK).

You are correct that the GPT spec requires a protective MBR; however, when I refer to an "MBR partition table," I mean a real MBR partition table with actual defined partitions, NOT merely a protective MBR, which is just a dummy data structure intended to keep GPT-unaware utilities and OSes from messing with the disk.

[Adam Thompson (athompso)]

Ah, I see what you mean.
HP appears to be breaking that paradigm, however, in that they have UEFI firmware that supports "legacy mode" booting, and that they seem to be shipping systems with normal MBR-style partition tables that nonetheless have EFI boot partitions.
My understanding of how Windows boots is, I think, the same as yours - although its legacy boot mode is very similar to EFI boot now, it's still different. So WTF is/are HP and Lenovo and Acer [I think], and... etc. doing?
The existence of this hybrid non-GPT-but-still-EFI firmware and accompanying boot process, unless I'm missing some important detail, will require that Ubuntu and others abandon their very limited notions of UEFI-compliance and allow much greater flexibility.
Meanwhile, I'm thankful that the Ubuntu systems I manage still have the ability to boot in 'normal' legacy mode. (As does the HP 8200 - if you're willing to wipe the existing disk, everything works just fine.)

[Launchpad Janitor (janitor)]

This bug was fixed in the package partman-auto - 93ubuntu21

---------------
partman-auto (93ubuntu21) precise; urgency=low

  * Increase minimum size of EFI System Partitions to 100MB (LP: #811485).
 -- Colin Watson <email address hidden> Wed, 14 Mar 2012 12:38:13 +0000

[Launchpad Janitor (janitor)]

This bug was fixed in the package partman-efi - 24ubuntu3

---------------
partman-efi (24ubuntu3) precise; urgency=low

  * On x86 architectures, create EFI system partitions using FAT32 rather
    than FAT16, and require newly-created ones to have a minimum size of
    34091008 bytes, experimentally verified as the minimum libparted will
    accept (LP: #811485).
  * Never format EFI system partitions that already contain a filesystem
    (LP: #769669).
 -- Colin Watson <email address hidden> Wed, 14 Mar 2012 14:31:13 +0000