Description of problem: GDISK should offer LBA-0 validity check of the GUID partition table check as per http://en.wikipedia.org/wiki/GUID_Partition_Table -i.e. MBR should begin with string "EFI PART" Reason: Some BIOSes refuse EFI boot if the MBR is not compliant Version-Release number of selected component (if applicable): all How reproducible: easily Steps to Reproduce: 1. Take Win-8 EFI booting PC 2. Install Fedora 19 in legacy mode - LBA-0 gets destroyed as the installer overwrites MBR 3. Win-8 can not boot any longer Expected results: If we run GDISK from a recovery CD, we should be able to fix MBR Additional info:
Thanks for report, I will ping upstream.
I don't believe this bug report identifies the correct problem. First, the GPT spec (in the EFI documents, or as paraphrased on the Wikipedia page referenced) does ***NOT*** require that the string "EFI PART" appear in the MBR. In fact, the MBR, whether a conventional MBR or a GPT's protective MBR, begins with 440 bytes (or 446 bytes, if the serial number is used) that are devoted to boot loader code. Thus, requiring that the MBR begin with "EFI PART" would render it useless for holding boot loader code, unless that ASCII string corresponded to valid 16-bit x86 code that would be useful to a boot loader. The "EFI PART" string, however, must be part of the partition table's header, which is at LBA 1, not LBA 0 (the MBR). If that string is not present, gdisk would most likely identify the disk as NOT having a valid GPT (although I haven't verified this presumed behavior). That said, the problem identified under the "Steps to Reproduce" section of the report is real; however, the cause is different. Specifically, and if I recall correctly, Anaconda now sets the boot/active flag on the type-0xEE protective partition when the Fedora installer is booted in BIOS/CSM/legacy mode. Some EFIs use this flag as a hint to boot the computer in BIOS/CSM/legacy mode, and in the scenario described, because Windows was installed in EFI mode, there is no BIOS/CSM/legacy-mode Windows boot loader, and Windows won't boot. I've never verified this personally, but I have seen reports of this problem in Web forums. I don't know offhand if Windows itself cares about the presence or absence of a boot/active flag on the 0xEE protective partition. GPT fdisk version 0.8.8 adds a check for the boot/active flag on the 0xEE protective partition to the verify ("v") operation. GPT fdisk does not count this flag's presence as an error, but it does warn users if it's present. The flag can be removed, if desired, by using the "n" option on the experts' menu; this command creates a fresh protective MBR. A similar effect can be achieved in recent versions of parted by using the "disk_toggle" or "disk_set" commands. Ultimately, therefore, this is not a gdisk bug. IMHO, it's a bug in Anaconda, which should do a better job of checking for an existing Windows installation, detecting its boot mode (BIOS/CSM/legacy vs. EFI/UEFI), and warning the user if Fedora is about to be installed in the other (and therefore wrong) mode.
*** This bug has been marked as a duplicate of bug 971255 ***
Let me clarify the reproduce steps: Steps to Reproduce: 1. Take Win-8 EFI booting PC 2. Install Fedora 19 in legacy mode - LBA-0 gets destroyed as the installer overwrites MBR 3. Win-8 can not boot any longer I should add the FIX steps as well: 1. dd if=/dev/sda of=mbr.bin count=1 2. Use you favourite text editor and set the first 8 chars in mbr.bin to string "EFI PART" 3. dd if=mbr.bin of=/dev/sda count=1 4. Use gdisk to fix checksums in MBR (note that the string "EFI PART" stays there in LBA-0 after this operation) 5. I can no longer boot fedora using Legacy mode (makes a sense, right) but I can now boot Windows That said, I do not believe Rod's assumption above is correct, my BIOS _really_ expects the "EFI PART" string in LBA-0. If it is not there, the EFI BIOS simply ignores the whole disk. I agree that the anaconda installer is guilty as well (should warn about destroying the EFI signature in LBA-0), but even after resetting the partitions boot flags I still can not boot Windows. I really HAVE to fix MBR using these steps to make it working again. I admit I am no EFI expert, but my observation says that Rod is not right here and we are facing a different problem. Please re-inspect this, and reopen this report unless 100% sure that it is not a problem of gdisk.
Ondrej, please see the discussion on bug #971255. Note that the GPT spec does ***NOT*** require "EFI PART" to be in LBA 0, although it should be in LBA 1. If you're using a text editor, all bets are off as to where "EFI PART" will appear in the final result, since these data structures are binary, not ASCII, and text editors can do odd things when fed binary data files.
Oh, and concerning whether this is a problem with gdisk: Your original report did not describe use of gdisk in reproducing the problem. (The Fedora installer does *NOT* use gdisk!) Your expanded procedure uses gdisk to fix a problem that was caused by mangling your disk's data in a text editor, but doesn't show gdisk as causing any problems. If you think this is a bug in gdisk, please provide a clear description of what gdisk is doing wrong -- that is, provide a procedure in which use of gdisk creates a problem or in which gdisk misbehaves in some way.
Ok, got it. Looks like my fancy hack with the text editor atually did the same is in bug #971255 - i.e. resetting the pmbr_boot flag. Sorry for the noise then. <OT> Note - I was trying Refind as this tool did not detect my HDD either when the pmbr_boot flag was set on </OT>