Re: grub2 BIOS booting iso and code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux