Bug 746895 - setting boot flag on GPT disks assigns incorrect partition type GUID
Summary: setting boot flag on GPT disks assigns incorrect partition type GUID
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 17
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Brian Lane
QA Contact: Fedora Extras Quality Assurance
Whiteboard: https://fedoraproject.org/wiki/Common...
Depends On:
TreeView+ depends on / blocked
Reported: 2011-10-18 06:53 UTC by Chris Murphy
Modified: 2012-06-05 00:00 UTC (History)
13 users (show)

Fixed In Version: anaconda-17.12-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-06-05 00:00:40 UTC
Type: ---

Attachments (Terms of Use)
storage.log (257.69 KB, text/plain)
2011-10-18 17:45 UTC, Chris Murphy
no flags Details
anaconda.log (16.47 KB, text/plain)
2011-10-18 17:46 UTC, Chris Murphy
no flags Details

Description Chris Murphy 2011-10-18 06:53:15 UTC
Description of problem:

Installer enables the boot flag state for linux boot partitions, specified to mount on /boot. On GPT disks, the consequence is it changes the partition type GUID to "EFI System" C12A7328-F81F-11D2-BA4B-00A0C93EC93B.

Version-Release number of selected component (if applicable):
Fedora-16-Beta-x86_64-Live-Desktop.iso  28-Sep-2011
Fedora-16-Beta-x86_64-DVD.iso  28-Sep-2011

How reproducible:

Steps to Reproduce:
1. LiveCD boot
2. Installation type "Use All Space"
3. Accepting all defaults.

[Other combinations are also possible. If the disk is GPT, and the boot flag is enabled in the GPT, that partition's partition type GUID will be "EFI System".]
Actual results:

On GPT disks, the boot flag in parted causes the partition type GUID for "EFI System" Partition to be set.

On BIOS systems, this means they inadvertently get a linux boot partition marked as an "EFI System" partition.

On EFI systems, this means they inadvertently get two "EFI System" partitions. (One is a valid EFI System partition, the other is actually a linux boot partition.)

Expected results:

On GPT, only the "EFI System" partition should have the boot flag state enabled.
To fix this bug, when creating the GPT, the partition to be mounted on /boot should NOT have the boot flag enabled.

Additional info:

Comment 1 David Lehman 2011-10-18 14:03:28 UTC
Please attach /tmp/storage.log and /tmp/anaconda.log as plain text. Thanks.

Comment 2 Brian Lane 2011-10-18 14:33:02 UTC
parted makes the decision about what GUID to set. The logs might still be useful though.

Comment 3 Chris Murphy 2011-10-18 17:45:37 UTC
Created attachment 528852 [details]

Comment 4 Chris Murphy 2011-10-18 17:46:07 UTC
Created attachment 528853 [details]

Comment 5 Brian Lane 2011-10-19 00:34:18 UTC
I think Chris is probably correct, anaconda should not be setting the boot flag for /boot partitions on BIOS installs. I did a quick (and admittedly limited) test by clearing the boot flag after a live install on a KVM and it boots fine. I don't know of any reason why the BIOS would care one way or the other about the flags set by a partitioning scheme.

Comment 6 Chris Murphy 2011-10-19 00:56:32 UTC
MBR specifically supports a boot flag. GPT doesn't support flags, that's merely parted's terminology. Parted flags get translated into either partition type GUIDs, or a partition attribute on GPT disks.

I think what's going on is anaconda historically asks parted to set a 'boot' flag for MBR disks, and this is happening for GPT disks also. The problem is that the parted 'boot' flag for GPT doesn't really enable any 'boot' flag in GPT since such a flag doesn't exist. Instead, parted sets the partition type GUID to "EFI System".

End result is that right now, any /boot disk is set to "EFI System" on BIOS computers. And EFI computers get two EFI System partitions. Not good.

Comment 7 Brian Lane 2011-10-21 00:50:43 UTC
Give this a try:


It changes things so that on GPT boot is only used for EFI system partitions.

Comment 8 Chris Murphy 2011-10-21 14:37:27 UTC
I think I'll have to take your word for it as I'm not at all sure what to do with this file.

Comment 9 Brian Lane 2011-10-21 15:47:11 UTC
Add updates=http://bcl.fedorapeople.org/updates/746895.img to your kernel cmdline when booting the installer.

It should result in /boot not having the boot flag or EFI System GUID set on it on BIOS systems and on EFI it should only have boot (and the GUID) set on the EFI System partition, not on /boot.

Comment 10 Chris Murphy 2011-10-21 18:50:37 UTC
OK I have already removed the 'boot' flag on /boot but if you're asking me to test this as instructed I can reset /boot to enable 'boot' flag twice to test both CSM and EFI modes on this Macbook Pro.

Comment 11 Chris Murphy 2011-10-24 19:55:05 UTC
(In reply to comment #9)
> Add updates=http://bcl.fedorapeople.org/updates/746895.img to your kernel
> cmdline when booting the installer.

Using this results in /boot not having 'boot' flag (or EFI System GUID) set on GPT disks. It is still set for MBR disks, which is expected. Behavior is the same for both LiveCD and Install DVD installers.

Comment 12 Chris Murphy 2011-11-04 20:02:26 UTC
This fix does not appear to be incorporated into RC5. Should it be?

I have downloaded:

Created a new virtual disk for a VM in VirtualBox (BIOS, not EFI).

Installation type "Use All Space"

Actual results:
I end up with a /boot partition, /dev/sda2, with the GUID for EFI System partition. Parted repots that this partition has the boot flag set. And gdisk reports code EF00.

Expected results:
GPT boot flag should not be set for the linux /boot partition.

Comment 13 Brian Lane 2011-11-04 20:10:42 UTC
This did not make it into F16.

Comment 14 Chris Murphy 2011-11-04 22:50:43 UTC
I think the salient data of this bug needs to go in the release notes for sure. And a step by step using either parted or gdisk for correcting the GUID.

I don't know how BIOS systems will treat an EFI System partition (which is actually linux boot), but conceivably an installer will think, "OH I don't need an EFI System partition" and invite the user to blow it away.

And I also don't know how EFI systems will behave with two EFI System partitions present. My best guess is that Apple (EFI) hardware with Mac OS X on them, a firmware update may fail due to confusion as a result of an extra EFI System partition being present, since the EFI System partition is used as a staging ground for these updates.

Comment 15 Brian Lane 2011-11-05 00:06:06 UTC
As far as I can tell this is a cosmetic problem. But yes, it should be documented and fixed in F17.

Comment 16 Rod Smith 2011-11-05 05:20:37 UTC
Actually, it's not entirely cosmetic. In brief, this bug can cause Windows to become uninstallable until the partition type code error is corrected.

The long explanation: I've just finished running some tests, and Windows 7 becomes quite confused when installed in UEFI mode on a disk with more than one ESP, the first of which uses FAT-32 and the second of which uses ext2fs. (Probably other filesystems or partition layouts would give it fits, too; it's just tedious to run the tests.) In this configuration, Windows claims that the disk is unbootable and suggests checking BIOS options. The only way I've found to get around the problem is to change the type code of the second (ext2fs) ESP. Windows is then happy to install and everything proceeds normally.

The good news is that if you've installed Fedora in UEFI mode and then attempt to install Windows, this problem won't occur, since this Fedora installer bug seems to be specific to BIOS-mode installs. Another problem can crop up in this case, though: Windows flakes out in a similar way with FAT-16 ESPs, which the Fedora installer creates, IIRC. (I've got to double-check this, and will create a new bug report if I confirm it.)

This bug can create problems if you install Fedora in BIOS mode using GPT and then attempt to install Windows in UEFI mode. Given the poor options for selecting boot modes on many UEFI systems, and users' lack of knowledge of the issues, this is a perfectly plausible scenario.

I haven't run tests on a Mac to see how it might be affected. I also don't know if there are other UEFI-capable OSes that might react badly. (Another Linux distribution might conceivably flake out in one way or another, for instance.)

Comment 17 Adam Williamson 2011-11-05 05:32:02 UTC
I think we use FAT for our EFI system partition, not ext2. Did you actually test with Fedora?

Fedora Bugzappers volunteer triage team

Comment 18 Rod Smith 2011-11-05 05:43:08 UTC
I retract my comment about the installer creating a FAT-16 ESP; it doesn't, at least not in my one quick test. It does, however, create a rather huge (1.39 GiB on my test system) ESP. This is bug #748274 (https://bugzilla.redhat.com/show_bug.cgi?id=748274).

Adam, this whole bug is about the Fedora /boot partition being marked as an ESP. (That is, it has its "boot flag set," in libparted terminology, which is very confusing, given the very different meaning of "boot flag" on MBR disks.) The result of this bug, when the disk also has a valid ESP, is that the disk appears to have two ESPs, one that's an appropriate FAT-32 ESP and the other of which has a Linux filesystem (ext4 if you use the default settings; I used ext2 in my tests, but I doubt if the Windows installer knows the difference).

Comment 19 Chris Murphy 2011-11-05 08:00:36 UTC
I, for one, consider this a significant bug, simply because of the unknowns and the very fact that the partition GUID set by Anaconda vis-à-vis parted, is totally bogus. It's extremely optimistic to consider it cosmetic. The release notes should strongly suggest that users correct the GUID. If this were some Tonka Toy operating system I wouldn't be so concerned about it.

With regard to comment #17, the linux boot partition is ext4 by default which is a variant of ext2fs, and it is that partition that is marked as EFI System partition - incorrectly - by anaconda by virtue of it asking parted to set the GPT 'boot' flag. So yes, you have an EFI System partition that is ext2.

The legitimate EFI System partition, on bonafide EFI systems, is FAT32.

Comment 20 Adam Williamson 2011-11-05 09:13:30 UTC
rod: oh, right, I somehow forgot about that. sigh.

Fedora Bugzappers volunteer triage team

Comment 21 Finnbarr P. Murphy 2011-11-06 16:34:26 UTC
The current UEFI specification specifically allows more than one System Partition on a system but only one on a removable media.  It is silent on whether there may be more than on ESP on a disk.

From UEFI 2.3.1 Errata A 12.3.3:

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. 

From UEFI 2.3.1 Errata A

For removable media devices there must be only one UEFI-compliant system partition, and that partition must contain an UEFI-defined directory in the root directory.

Comment 22 Rod Smith 2011-11-06 19:57:32 UTC
Finbarr, I don't think that the UEFI specification section you've quoted absolves this as a bug, for two reasons:

First, the UEFI spec also states "EFI encompasses the use of FAT32 for a system partition..." (UEFI Spec 2.3.1, section 12.3, p. 488). Thus, a Linux filesystem is not a valid filesystem for use on an ESP, making the layout created by the installer a violation of the UEFI specification. In fact, even a FAT12 or FAT16 filesystem is not technically valid for the ESP, although in practice it does work (but see below).

Second, as I wrote earlier, Windows 7 flakes out when presented with a disk that has both a valid FAT32 ESP and an ext2fs partition with the ESP's type code. Thus, no matter how the UEFI spec is interpreted, there is the potential for this bug to create problems with a subsequent Windows installation. (FWIW, the Windows 7 installer flakes out even when the disk has a FAT16 ESP that is valid, aside from being FAT16.) This is a problem that should be avoided on principle, even if the UEFI spec said it was a legal configuration.

Comment 23 Brian Lane 2011-11-07 15:34:48 UTC
Rod, thanks for the Windows testing.

Yes, this is a bug. There's no need to try to justify it.

It is also easy to fix by turning off the boot flag on /boot if it ends up being an issue.

Comment 24 Adam Williamson 2011-11-08 05:33:42 UTC

Fedora Bugzappers volunteer triage team

Comment 25 Andrew McNabb 2011-11-09 20:24:00 UTC
The CommonBugs page says: "To work around any issues caused by this, use a GPT-capable partition editor such as parted to correct the partition type on the /boot partition." Unfortunately, it's not clear to me whether I'm being affected by this problem nor how I should fix it if I am. How does one correct the partition type on the /boot partition?

Comment 26 Brian Lane 2011-11-09 21:41:13 UTC
If you don't know then it probably doesn't matter :)

You can fix the problem by turning off the 'boot' flag on the /boot partition using parted like this:

parted -s /dev/BOOTDEV set BOOTPART boot off

BOOTDEV is something like /dev/sda
BOOTPART is the partition number

eg. parted -s /dev/sda set 2 boot off

Comment 27 Andrew McNabb 2011-11-09 21:54:17 UTC
That's what I tried, and it didn't work, so I must have had a different problem, which I've filed as bug #752548.

Comment 28 Chris Murphy 2012-02-29 20:38:52 UTC
This is still a bug in F17 alpha.

Comment 29 Fedora Update System 2012-03-06 15:00:11 UTC
anaconda-17.12-1.fc17 has been submitted as an update for Fedora 17.

Comment 30 Fedora Update System 2012-03-07 07:20:50 UTC
Package anaconda-17.12-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-17.12-1.fc17'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Note You need to log in before you can comment on or make changes to this bug.