Bug 1027624 - Additional checks for existing Windows installation needed
Additional checks for existing Windows installation needed
Status: CLOSED DUPLICATE of bug 971255
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-11-07 03:46 EST by Ondrej
Modified: 2013-11-08 01:47 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-11-07 16:29:34 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ondrej 2013-11-07 03:46:53 EST
Description of problem:
GDISK should offer LBA-0 validity check of the GUID partition table check as per
-i.e. MBR should begin with string "EFI PART"
Some BIOSes refuse EFI boot if the MBR is not compliant

Version-Release number of selected component (if applicable):

How reproducible:

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:
Comment 1 Terje Røsten 2013-11-07 11:48:23 EST
Thanks for report, I will ping upstream.
Comment 2 Rod Smith 2013-11-07 15:56:54 EST
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.
Comment 3 David Shea 2013-11-07 16:29:34 EST

*** This bug has been marked as a duplicate of bug 971255 ***
Comment 4 Ondrej Valousek 2013-11-07 17:11:07 EST
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.
Comment 5 Rod Smith 2013-11-07 18:17:26 EST
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.
Comment 6 Rod Smith 2013-11-07 18:21:47 EST
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.
Comment 7 Ondrej Valousek 2013-11-08 01:47:23 EST
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>

Note You need to log in before you can comment on or make changes to this bug.