Installer should not format an existing EFI System Partition

Reported by Charles Comstock on 2011-04-23
This bug affects 17 people
Affects Status Importance Assigned to Milestone
partman-efi (Ubuntu)
Colin Watson

Bug Description

Binary package hint: partman-efi

When selecting an EFI partition under parted during ubiquity install on 11.04, there is no option to select mount point. As windows 7 had installed an EFI partition at /dev/sda1 formatted to NTFS, I selected that. I did not select that it should format the mount point, but it did anyway to FAT16 and deleted the windows bootloader. Update-grub does not find windows, and I had to go to great lengths to reinstall the bootloader to the same partition as windows, it is still missing from /dev/sda.

I had expected that even if /dev/sda1 was formatted, it would at least preserve the existing bootloader instead of putting me in a position where I had to use a windows recovery disk for several hours until I can now at least boot to windows using the bios, but grub is still unaware of the windows install. I expected windows to overwrite grub, but I didn't expect installing linux to break my windows install.

I encountered this bug after having the problems in this bug: https://bugs.launchpad.net/bugs/765270.

Charles Comstock (dgtized) wrote :

partman log

Charles Comstock (dgtized) wrote :
Charles Comstock (dgtized) wrote :

Sorry for using a single tar.gz for the logs, but launchpad wasn't reporting errors when uploading files owned by root, and it doesn't appear to allow you to upload more then one file with a comment?

Also the installer should use FAT32 instead of FAT16 for EFI SYSTEM PARTITION as mandated by the UEFI Spec. FAT16 ESP partition is not recognised by Windows UEFI bootloader because of this.

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

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

The installer should also reuse the existing filesystem if a valid FAT32 EFISYS partition is selected during installation instead simply formatting the partition to FAT16.

summary: - selecting efi partition overwrites windows bootloader
+ Installer should not format an existing EFI SYSTEM PARTITION and should
+ use FAT32 instead of FAT16 as the FS

This bug is extremely serious. If you don't happen to have your ESP backed up, you'll have a hard time recovering when it bites. Beyond the obvious problem of trashing other OSs' files, even after restoring the trashed boot loaders, if another Linux distribution referenced the ESP via a "UUID=" entry, it will have problems because the "UUID" (really just a FAT serial number) will have changed. Fedora 15, for instance, fails to boot until its /etc/fstab is updated. If you restore the computer by creating a fresh FAT32 filesystem, Ubuntu will have the same problem.

Overall, this is an unforgivable bug.

Roderick Smith (rodsmith) wrote :

Oh, one more thing: Windows is fussy about the ESP; if it's FAT16, Windows won't accept it as a valid ESP (although it displays as one in the partitioning screen), and will insist on creating a new FAT32 ESP. It will then get confused and be unable to complete its own installation. Thus, if you install Ubuntu first and then Windows to work around this bug, Windows won't install properly unless you first back up the ESP, create a new FAT32 filesystem on it, restore it, and fix your /etc/fstab entries.

It seems like Windows Vista x64 is ok with FAT16 in EFISYS but Windows 7 x64 setup uses FAT32 alone. I don't know whether this FAT32 requirement for non-removable disk EFISYS is in UEFI 2.3 spec only or whether it was the case in previous spec versions as well.

Roderick Smith (rodsmith) wrote :

The FAT32 language exists in the EFI 1.10 spec (section 11.2, p. 11-4). The critical first sentence you quoted is identical.

Avidan Borisov (avidanborisov) wrote :

Windows 7 Enterprise boots fine to me with FAT16 ESP.

Colin Watson (cjwatson) wrote :

Keshav, please do not overload bug reports. Bug reports should be about a single problem, not multiple problems. Please file your complaint about FAT16 vs. FAT32 separately.

That said, I deliberately used FAT16 where possible because it seemed to me that the minimum size of 256MB for a FAT32 partition was likely to be somewhat inconvenient. At the time, I read the UEFI specification and determined that it in fact did meet its requirements (I read the section you mention, but there's another section somewhere else that I believed to be relevant). I'm not going to dig it up as part of this bug report, but I could look into it if you file a separate one.

summary: - Installer should not format an existing EFI SYSTEM PARTITION and should
- use FAT32 instead of FAT16 as the FS
+ Installer should not format an existing EFI System Partition
Changed in partman-efi (Ubuntu):
status: New → Triaged
importance: Undecided → High
Colin Watson (cjwatson) wrote :

And indeed the FAT16/FAT32 question is definitely distinct from this bug, because the partman log posted by Charles, as well as his original bug description, show that the EFI System Partition was initially formatted as NTFS. That's really quite perplexing. Is that even allowed (my reading of the UEFI specification strongly suggests not), or are we somehow misdetecting a FAT filesystem as NTFS?

I will file a bug report for FAT32 vs FAt16. But I do not use Ubuntu directly and modified this bug report only becuase few users reported problems in dual-bot scenario when using FAT16 EFISYS which were solved if FAT32 EFISYS was used.

BTW NTFS is not supposed to be the FS for EFISYS partition. As per my understanding of the Spec, EFISYS part should be FAT32 for non-removable media, and FAT32 or FAT16 for removable media (with FAT12 being used for floppy discs/images). I think it might me am case of misdetection of the FS.

Also where is the 250 MB (or is it MiB) minimum size for FAT32. I have used FAT32 in 100-200 MiB partitions (both EFISYS and normal data ones) and have not faced any problems (no warnings/errors reported by fsck or windows chkdsk utils regarding minimum size limit).

While the spec does not specify a minimum size for EFISYS partition, it is generally accepted by many OS vendors to be at least 100 MiB size (200 MiB recomended).

Opened Bug report https://bugs.launchpad.net/ubuntu/+source/partman-efi/+bug/811485 for EFISYS 100 MiB size and FAT32 issue.

FlyingMG (flyingmg) wrote :

I just installed Win 7 EN 64bit and then tried to install ubuntu 11.04 as a second system.
After rebooting the system, I only get a blinking dash.
I could arrange to access Grub2 and boot either the installed win7 or ubuntu by inserting te win7 installation CD and at the prompt if I want to boot/load from it, removing the CD again... Then Grub2 is loading and I am able either to loaf win 7 or ubuntu 11.04.
I assume this bug is the one, that killed my dual installation.

(Is there meanwhile any solution for that problem ?
Would it be a solution to first install ubuntu 10.04 or 10.10 and then upgrade to 11.04 from there ?)

Is there any forum topic open to that question ?

Roderick Smith (rodsmith) wrote :

I'm appalled that this bug is still present in the Ubuntu 11.10 beta 2. ERASING EXISTING OSes' BOOT LOADERS IS NOT ACCEPTABLE!!!!! Since many (perhaps most) new computers shipping today are UEFI-based, this bug is rapidly increasing in importance. PLEASE fix it before 11.10 goes final!

Roderick Smith (rodsmith) wrote :

I've just checked Ubuntu 11.10 final release, and this bug is STILL present! I cannot recommend Ubuntu for EFI users; working around this bug is just too awkward.

Andreas Klöckner (inform) wrote :

I have to agree with Rod--it's pretty appalling that Ubuntu manages to sit on a bug for two releases that renders people's systems unbootable.

Bob Kerns (rwk) wrote :

1) This should be regarded as a showstopper bug. No fix -- no release. This is right up there with "corrupts the filesystem". Well, no, it IS "corrupts the filesystem".
2) You really need to release a patch -- a 11.11 or however you number such things. An install that actually works.

Yannick Warnier (ywarnier) wrote :

This is at least partially related to this forum post: http://ubuntuforums.org/showthread.php?t=1867367

Przemysław Kulczycki (azrael) wrote :

The problem is still present in Ubuntu 12.04 alpha. When I installed it on my Macbook, it erased my EFI partition.

Roderick Smith (rodsmith) wrote :

I've verified Przemyslaw Kulczycki's report that this problem is still present in 12.04 alpha 2. Do the developers REALLY want this bug to be present in a long-term support release? It's only going to become more of an issue with time. Since UEFI-based computers are now shipping in droves, more and more people will be encountering this bug, which will render them unable to boot Windows (or whatever other OS may be installed already), and getting really ticked off about it. The average user won't know how to fix a trashed ESP, and a user who spends an afternoon trying to fix the problem will blame Ubuntu -- and rightly so!

PLEASE fix this bug! As Bob Kerns wrote in post #18, it should be considered a "showstopper!"

Colin Watson (cjwatson) wrote :

I must say that I am thoroughly confused by Charles' logs at the head of this bug report. Yes, perhaps it may be a misdetection problem, but the logs say that he is booting an EFI system on an MBR-formatted disk with an NTFS filesystem on the first partition. Frankly, I'm wondering whether that was actually meant to be an EFI System Partition at all!

That said, and in the absence of any other logs, I'll arrange to not format ESPs with existing filesystems for 12.04; it seems the least of the menu of available evils.

Changed in partman-auto (Ubuntu):
status: New → Triaged
importance: Undecided → High
assignee: nobody → Colin Watson (cjwatson)
Changed in partman-efi (Ubuntu):
assignee: nobody → Colin Watson (cjwatson)
no longer affects: partman-auto (Ubuntu)
Colin Watson (cjwatson) on 2012-03-14
Changed in partman-efi (Ubuntu):
status: Triaged → Fix Committed
Launchpad Janitor (janitor) wrote :

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

Changed in partman-efi (Ubuntu):
status: Fix Committed → Fix Released
Daniel van Vugt (vanvugt) wrote :

Nice. Precise beta-2, here we come.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers