Created attachment 534321 [details] Add disk flag toggle support to parted, along with the legacy_boot disk flag Some machines will refuse to boot if they see a disk without a bootable partition in the MBR. This includes GPT disks with a protective MBR, since the UEFI spec clearly states that such MBRs must have that flag cleared. Let's add support for ignoring that aspect of the spec to parted, and add code to anaconda to set it.
*** Bug 754472 has been marked as a duplicate of this bug. ***
*** Bug 696482 has been marked as a duplicate of this bug. ***
Discussed at the blocker review meeting of 2012-01-27. Agreed that this should block F17 Alpha under criterion "In most cases (see Blocker_Bug_FAQ), a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. This includes correctly accessing any encrypted partition" For F16 this wasn't accepted as a blocker - discussion in 696482 - as it was unclear whether we should infringe the UEFI spec in this way, but we have now talked to the UEFI group and got permission to do so (and their assurance it ought not to break any other systems). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
*** Bug 750853 has been marked as a duplicate of this bug. ***
This is implemented in anaconda-17.6-1.fc17 . F17 Alpha TC2 will include that anaconda. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This would set the active flag on the 1st MBR entry (the protective MBR)? Or sets a flag in the GPT?
The protective MBR.
I want to clearly understand in what situations this flag will and will not be set. Because on Apple hardware, both 2008 Macbook Pro and 2011 Macbook Pro, doing this makes the computer completely unbootable. By completely unbootable, I mean even Mac OS is rendered unbootable. The user would have to boot from alternate media, and use a command line tool to remove the active flag in order to make any installed OS function.
How broadly is this change applied? I ask because it's almost certain to cause problems on some systems if applied universally. Intel-based Macintoshes, in particular, will fail to boot if the bootable flag is set on the protective MBR's 0xEE entry. They come up to a gray screen with a flashing file-folder icon with a question mark in it. I wouldn't be at all surprised if some UEFI systems reacted badly, too, even despite "assurance it ought not to break any other systems." IMHO, the best way to handle this is as follows: 1) If installing to a disk with an existing partition table, don't change its type or (for GPT disks) alter the protective MBR's 0xEE partition. 2) If installing to an EFI-based system with a blank disk (no partition table), create a standards-compliant protective MBR without the "boot" flag set on the 0xEE partition. Such systems should never need this workaround, so setting it is violating the standard and asking for trouble. 3) If installing to a BIOS-based system with a blank (no partition table) sub-2TiB disk, use MBR, *NOT* GPT. GPT does have its advantages, but they don't outweigh the problems of GPT on buggy BIOSes. 3) If installing to a BIOS-based system with a blank (no partition table) over-2TiB disk, use GPT and set the "boot" flag on the 0xEE protective partition, *BUT* warn the user about the issue and give an option to unset that flag, and be sure the warning is issued before anything is written to the disk, so that the user can abort to research the issue more before proceeding. You might also want to change the default for Macs, if you can detect that the OS is installing to a Mac in BIOS mode. Ideally, the user should have explicit control over all these decisions to override them (say, to use GPT on a sub-2TiB disk). I realize that a warning about a default setting, as I recommend in #3, is off-putting, but IMHO this is better than breaking a user's system without warning. FWIW, I'm the author of GPT fdisk (http://www.rodsbooks.com/gdisk/), so I've been dealing with GPT partitioning issues for years. In fact, a sub-page on my GPT fdisk page covers the BIOS boot issues specifically, and has been up since at least mid-2010. See http://www.rodsbooks.com/gdisk/bios.html for details.
re: comment 9, listed handling #3: If it's Apple hardware, and the disk is GPT, and MBRs 0xEE's boot/active flag is set, the hardware will not boot. Period. It doesn't matter if it's EFI or BIOS mode booting - actually the system doesn't even get that far, it's an EFI boot blocking condition. The CSM is never loaded. For computers that have existing OS's that boot, to install Fedora and have Fedora not boot is one small problem[1], but it's a magnificent show stopper problem to break the bootability of the previously functioning OS. Therefore this feature needs some kind of hardware detection to conditionally set the protective MBR active flag. I bet dollars to donuts Microsoft encountered these inconsistencies with BIOS and GPT disks some time ago, and hybrid MBRs that they basically said "screw it - if BIOS, then it's only MBR for booting, and if UEFI, then it's only GPT for booting." That is their policy. BIOS computers do not boot from GPT disks. [1] current behavior of F16.
The patch in this update (against anaconda 17.7) should keep it from setting boot on the PMBR when installing on macs. http://bcl.fedorapeople.org/updates/mactel_754850.img If this doesn't work, lets open a bug for it specifically and deal with it there. Rod, thanks for the info and you're right we should probably not set it on EFI systems as well.