Hi, Neal Gompa wrote: > I don't know if it's been mentioned, IIRC, Chris Murphy did. > but until very recently, pretty > much all TianoCore based UEFI implementations failed to boot > protective MBR marked GPT partitions. > [...] > https://github.com/tianocore/edk2/commit/b3db0cb1f8d163f22b769c205c6347376a315dcd First of all: Thanks for fixing this. But yes, the problem is known and a workaround is known in form of the little dummy MBR partition which takes the plight of carrying the boot/active flag. Old Tianocore will find the 0xEE partition first, see no boot flag there, and break the loop before it inspects the dummy partition. Ubuntu's current ISOs have this dummy MBR partition of type 0x00 and size 1. They seem to boot with the EFI implementations which are around. (Not a complaint towards Tianocore but just an observation: That loop is still barely specs compliant. But now it is on the liberal side. UEFI 2.8 says "5.2.3 Protective MBR [...] 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. " Well, i guess "table 12" was meant as "table 20" which describes the partition slot of type 0xEE. Whether "shall" should be implemented as "must" is a matter of hairsplitting. A picky loop would not break at the first success but rather check all four partition slots. On the other hand it would be nice if it would project the "may be ignored" of "5.2.1 Legacy Master Boot Record (MBR) [...] A Partition Record that contains an OSType value of zero or a SizeInLBA value of zero may be ignored. " onto the rules for a Protective MBR. It would be unfortunate if this fragile compromise would be broken by increased pickiness of EFI implementations. To my understanding only the liberal interpretation of a "shall" and a slightly displaced "may" in the specs protects it. ) I am somewhat astonished that no BIOS machine was encountered yet in the tests of boot-grub2-f36.iso which would refuse to boot with its pure GPT-marking MBR table but would boot if the boot/active flag is set somwhere in the MBR partition table. Testers of grub-mkrescue ISOs and of Ubuntu ISOs encountered such machines. Have a nice day :) Thomas _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
