Description of problem: When a disk contains a valid legacy MBR (without an 0xEE entry), and a stale (but otherwise valid) primary and backup GPT, parted becomes confused, honoring neither. User is presented with two options: honor the stale GPT, or start from scratch with disklabel 'unknown'. Version-Release number of selected component (if applicable): parted 3.0-7 How reproducible: Always. Steps to Reproduce: 1. Use parted or gdisk to create a GPT disk. 2. Use fdisk to edit the PMBR, remove 0xEE entry and add a plausible entry or entries 3. Use parted to edit the disk partition. Actual results: Warning: /dev/sdd contains GPT signatures, indicating that it has a GPT table. However, it does not have a valid fake msdos partition table, as it should. Perhaps it was corrupted -- possibly by a program that doesn't understand GPT partition tables. Or perhaps you deleted the GPT table, and are now using an msdos partition table. Is this a GPT partition table? Yes/No? Yes results in GPT being honored and editable. No results in Partition Table 'unknown' with no entries. Expected results: Honor and edit the valid legacy MBR. Or an option to choose between the valid MBR and stale GPT. Additional info: From UEFI 2.3.1 Errata A. 5.2.3 says a protective MBR may be located at LBA 0 if GPT is being used. 5.2.1 says a legacy MBR may be located at LBA 0 if GPT is not being used. 5.3.2 says:If a GPT formatted disk is reformatted to the legacy MBR format by legacy software, the last logical block might not be overwritten and might still contain a stale GPT. If GPT-cognizant software then accesses the disk and honors the stale GPT, it will misinterpret the contents of the disk. Software may detect this scenario if the legacy MBR contains valid partitions rather than a protective MBR (see Section 5.2.1). Taking these together, it the GPT should only be honored when: a.) The GPT is valid, passing the test in 5.3.2; and b.) the MBR is missing, invalid, or protective.
Proposed as F17 Final blocker, based on final release criterion #8: "installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration..." This bug causes anaconda to present the user with the option to exit (fail to install), or discard all data with an entirely new partition layout rather than using an existing workable partition layout.
See also the discussion at https://www.redhat.com/archives/anaconda-devel-list/2012-March/msg00144.html for an example of a real-world case where this is a problem: format a disk as GPT, then let Windows re-format it as MS-DOS. It will leave one of the GPT signatures intact, and parted will wind up in this situation. The thread and IRC discussions resulted in broad agreements that it's unrealistic to expect tools that format disks with MS-DOS labels to correctly and fully wipe GPT signatures when doing so, because often they were written before GPT was completed (or even conceived). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #2) I originally reported the wild case with Windows 7 from another user. I first reproduced it with parted and fdisk as described in this bug. I then tried to reproduce it with the Windows Vista installer, which will not install to a GPT disk when BIOS booted. (Likewise it will only install to a GPT disk when UEFI booted.) The Microsoft prescribed procedure for this situation calls for using 'diskpart' to 'clean' the disk which removes all traces of MBR and GPT. Then Windows will install. And parted will not fail as described here. But there are other tools in the wild that won't be this thorough, and will present as described. Windows installs, parted subsequently fails to recognize the valid legacy MBR.
Here's a scratch build to try out: http://koji.fedoraproject.org/koji/taskinfo?taskID=3915886
Works for me. However, when I remove or add an entry, while the MBR is updated, the stale GPT is not blanked. While this meets the requirements, the follow-up question then is, should a GPT aware app like parted, also blank the GPT in this case so there isn't subsequent (though specious) ambiguity?
I think we should err on the side of changing as little as possible.
> From UEFI 2.3.1 Errata A. > > 5.2.3 says a protective MBR may be located at LBA 0 if GPT is being used. Ah, this is crazy, there is difference between the standard versions 2.3 and 2.3.1. old 2.3 standard, section 5.2.2: On all GUID Partition Table disks a Protective MBR (PMBR) in LBA 0. So currently PMBR is *required* by many tools (libblkid, linux kernel, ...), for example to ignore missing PMBR you have boot with "gpt" on kernel command line. > 5.2.1 says a legacy MBR may be located at LBA 0 if GPT is not being used. > > 5.3.2 says:If a GPT formatted disk is reformatted to the legacy MBR format by > legacy software, the last logical block might not be overwritten and might > still contain a stale GPT. If GPT-cognizant software then accesses the disk and > honors the stale GPT, it will misinterpret the contents of the disk. Software > may detect this scenario if the legacy MBR contains valid partitions rather > than a protective MBR (see Section 5.2.1). > > Taking these together, it the GPT should only be honored when: > > a.) The GPT is valid, passing the test in 5.3.2; and > b.) the MBR is missing, invalid, or protective. IMHO is better to require the protective MBR, it seems like a more robust and backwardly compatible solution. BTW, some "smart" users use hybrid GPT where is GPT as well as valid MBR. I don't think we have support this crazy setup.
Karel, are you saying that the kernel requires a PMBR before examining the GPT data? If so, that's (IMHO) the right thing to do, and that's what this scratch build does in parted. Also: parted has never cleaned up the missing PMBR, it just keeps prompting you while using GPT and falls into a unknown label if you say no. I don't think it should be touching the stale GPT data, it should just treat it as a msdos disk, which as far as it can tell, it is.
(In reply to comment #7) > IMHO is better to require the protective MBR, it seems like a more robust and > backwardly compatible solution. I agree it is foolish for a tool to produce a GPT disk without producing a PMBR. > BTW, some "smart" users use hybrid GPT where is GPT as well as valid MBR. I > don't think we have support this crazy setup. It's a huge maze of rabbit holes as to how the computer firmware will behave in such a situation. There is no standard defining the hybrid parameters, and it arguably violates the current UEFI spec, section 5.2.3: "One of the Partition Records shall be as defined in table 12, reserving the entire space on the disk after the Protective MBR itself for the GPT disk layout. The remaining Partition Records shall each be set to zeros." There is no allowance in the first sentence for the 0xEE entry being other than LBA 1 to the end of the disk. And the second sentence is even more clear. That said, one of the worst offenders of this is Apple, who require such a scheme for their supported dual boot Mac OS / Windows setup. Mac OS of course uses EFI/GPT and Window uses BIOS/MBR as a consequence of Apple's CSM-BIOS for Windows support, rather than supporting (U)EFI Windows 7 x86_64 only. (In reply to comment #6&8) I tentatively agree, but there should be assurance that GRUB2's components likewise treat such a disk as legacy MBR, ignoring stale GPT. I haven't tested if this is true.
(In reply to comment #9) And for that matter, grubby, and whatever else is responsible for what is inserted in grub.cfg when the kernel is updated. grub.cfg syntax distinguishes between GPT and MBR partitions. If anything that edits grub.cfg behaves like upstream parted does...
grubby at least is dumb and makes no attempt to interpret the partition table. it just takes the most recent entry, copies it, and changes the appropriate bits for the new kernel: the description, the kernel filename, and the initramfs filename. All other bits it just copies straight over. I don't know for sure exactly how grub2-mkconfig works, but we use grubby on kernel updates, not grub2-mkconfig. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #8) > Karel, are you saying that the kernel requires a PMBR before examining the GPT > data? Yes, PMBR is required by default.
parted-3.0-9.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/parted-3.0-9.fc17
Proposing as Beta NTH, just in case. Chris, Karel, Brian, what's your take on whether this is urgent enough to poke parted for the Beta? Or should we just leave it to Final? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I'd leave it for final.
I just tested creating such a legacy MBR + stale GPT disk, partprobe, zero'd the sectors containing BIOS Boot core.img, ran grub2-install to install new MBR gap core.img, and ran grub2-mkconfig. Reboots fine. The new grub.cfg replaces 'insmod part_gpt' with 'insmod part_msdos' and 'hd0,gpt2' with 'hd0,msdos2'. And I see those msdos references from within the GRUB2 bootloader edit feature. So that's promising, and really my only major outstanding concern.
-1 to nth -1 to beta blocker +1 to final
-1 nth (seems overly risky at this point) -1 beta blocker
i think we're reasonably -1 at this point. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Package parted-3.0-9.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing parted-3.0-9.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-4482/parted-3.0-9.fc17 then log in and leave karma (feedback).
parted-3.0-9.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.