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: Always. 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:
Please attach /tmp/storage.log and /tmp/anaconda.log as plain text. Thanks.
parted makes the decision about what GUID to set. The logs might still be useful though.
Created attachment 528852 [details] storage.log
Created attachment 528853 [details] anaconda.log
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.
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.
Give this a try: http://bcl.fedorapeople.org/updates/746895.img It changes things so that on GPT boot is only used for EFI system partitions.
I think I'll have to take your word for it as I'm not at all sure what to do with this file.
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.
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.
(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.
This fix does not appear to be incorporated into RC5. Should it be? 1. I have downloaded: http://serverbeach1.fedoraproject.org/pub/alt/stage/16.RC5/Live/x86_64/Fedora-16-x86_64-Live-Desktop.iso 2. Created a new virtual disk for a VM in VirtualBox (BIOS, not EFI). 3. 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.
This did not make it into F16.
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.
As far as I can tell this is a cosmetic problem. But yes, it should be documented and fixed in F17.
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.)
I think we use FAT for our EFI system partition, not ext2. Did you actually test with Fedora? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
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).
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.
rod: oh, right, I somehow forgot about that. sigh. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
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 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. From UEFI 2.3.1 Errata A 12.3.1.3: 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.
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.
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.
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
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?
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
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.
This is still a bug in F17 alpha.
anaconda-17.12-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/anaconda-17.12-1.fc17
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: https://admin.fedoraproject.org/updates/FEDORA-2012-3157/anaconda-17.12-1.fc17 then log in and leave karma (feedback).