Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Protective MBR entry on GPT drives must be marked active for some machines to boot, but this is a violation of GPT spec|
|Product:||[Fedora] Fedora||Reporter:||Frantisek Hanzlik <franta>|
|Component:||anaconda||Assignee:||Anaconda Maintenance Team <anaconda-maint-list>|
|Status:||CLOSED DUPLICATE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||anaconda-maint-list, awilliam, gowdy, jonathan, the.ridikulus.rat, vanmeeuwen+fedora|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-01-27 12:15:50 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Frantisek Hanzlik 2011-04-14 02:41:19 EDT
Description of problem: Using GPT disk division (I tested it with only prepared disk, and with disk whereat was installed other system too) with protective MBR, installer during post-installation phase (probably when install bootloader) clear Active partition flag at protective MBR record. Machine BIOS then refuse boot from this partition. Setting this flag manualy again (e.g. booting from rescue CD and activate this flag with fdisk) solve this issue. Version-Release number of selected component (if applicable): anaconda 14.22 from Fedora 14 i686 Steps to Reproduce: 1. take GPT divided disk with protective MBR (and ev. with other OS in some partition) and with some free partition(s) for installing Fedora 14 2. install F14 to some free partition. During packages install phase is possible verify that flag is still set. 3. But when installer finishes and appeal to reboot, flag is cleared (can be verify with fdisk on second shell screen). Additional info: I had in both cases two disks with identical GPT partitions and other system was installed on RAID1 md device. New Fedora 14 system was installed on RAID1 md device too (strictly speaking, old system was occupied two GPT ext4 partition, and new F14 system other three ext4 partitions (/boot,/,/home) + swap partition). But I think same situation occurred several months before, when I install F14 to single disk with GPT and other system on it - unfortunately I have not had time to fill bugreport.
Comment 1 Brian Lane 2011-04-18 19:32:11 EDT
Could you attached the output of 'parted /dev/sdX print' from before and after the install?
Comment 2 Stephen J. Gowdy 2011-10-14 09:31:18 EDT
I just installed Fedora 16 Beta on a HP EliteBook 2560p. I had to set the boot flag on partition 1 with fdisk to get it to boot. In fdisk there is only one partition listed with a label of GPT.
Comment 3 Adam Williamson 2011-12-05 14:37:01 EST
Broadening this out into a general bug. it seems to have become clear during F16 cycle that the protective MBR entry on a GPT-labelled disk ought to be marked as active. mjg59 says so and http://www.rodsbooks.com/gdisk/bios.html (entry 1. under 'Sticking with the BIOS') also suggests this. It's possible this is technically 'wrong' and only happens to make some badly coded BIOSes work, in which case we shouldn't do it, but AIUI things at the moment, this is the 'correct' thing to do, and we should always ensure the protective MBR entry is marked as active in all cases. Just to be clear, it seems anaconda's current behaviour is such that the protective MBR entry is _never_ marked active - whether there's a pre-existing protective MBR and anaconda removes the active flag (as in this initial report), or whether anaconda is entirely formatting the disk and creating the disk label itself, the protective MBR entry always winds up not being marked as active. Proposing as blocking F17 Alpha as we ought to fix this early and it is documented to prevent some systems booting. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 4 Adam Williamson 2011-12-05 14:47:36 EST
So, in further discussion, it seems this is a bit more complex. Apparently setting the protective MBR as bootable is a clear violation of the GPT spec, but we know for sure it's actually *necessary* in practical terms to make some machines boot. So our choices are: 1) keep doing the 'correct' thing in the knowledge that some systems simply won't boot after install (and keep documenting 'nogpt' or manually setting the active flag on the protective MBR) 2) do the 'wrong' thing and set the active flag on the protective MBR, and hope that a) no-one really minds that it violates the spec and b) it doesn't break some *other*, more spec-compliant systems 3) drop the whole GPT-on-BIOS thing as a bad idea and go back to using MS-DOS disk labels for BIOS installs from F17 onwards, using GPT only on EFI installs seems like there should at least be a clear decision on this one.
Comment 5 Adam Williamson 2012-01-27 12:15:50 EST
Bug #754850 covers the action that was decided here: go ahead and enable the flag. So closing this as a dupe. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers *** This bug has been marked as a duplicate of bug 754850 ***