Bug 696482
| 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> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | anaconda-maint-list, awilliam, gowdy, jonathan, the.ridikulus.rat, vanmeeuwen+fedora |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-01-27 17:15:50 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 752648 | ||
|
Description
Frantisek Hanzlik
2011-04-14 06:41:19 UTC
Could you attached the output of 'parted /dev/sdX print' from before and after the install? 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. 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 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. 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 *** |