BenLunt wrote:
I think what Brendan is talking about and what I do, is have one of the Protected MBR's partition entries point to one of the GPT partitions within the GPT space.
this is a problem already, since Protective MBR
could have only 1 partition entry, it should be of 0xEE type, covering all the space behind MBR.Quote:
For example, an EFI boot will find the GPT, find the "active" GPT partition, and search for the boot.efi file, which in turn will boot the OS. On a Legacy BIOS boot, the BIOS will load the Protected MBR, find one of the partition entries active, load that VBR, which just so happens to be the first sector of the same partition the boot.efi file resides in. Then this VBR will, using Legacy BIOS services, boot the OS.
This is perfectly legal and allows the same partition (same volume) to be booted from either a Legacy BIOS boot or an EFI boot.
This is what I do for GPT partitioned media. Different boot loaders, but exactly the same kernel and drivers, just different forms of loading them.
Ben
As I've said it's not legal.
Generally, it's impossible to make GPT and Legacy MBR friends, every magic methods will turn to be a source of incompatibility and PITA in the future.
You either have a disk with GPT
and without usable MBR or just MBR. Protectiuve MBR by design could serve only one purpose - to protect GPT from legacy code not understanding GPT. Not even a hint on "booting" from it by this code. It
should be marked as inactive, the quote:
Quote:
Set to 0x00 to indicate a non-bootable partition. If set to
any value other than 0x00 the behavior of this flag on
non-UEFI systems is undefined. Must be ignored by
UEFI implementations.
Quite a clear answer on being "perferct legal", right?
UEFI could boot from non-GPT anyway, but trying to make legacy BIOS to boot from GPT is a bad idea. Better to just supply two layouts for installations - one for legacy and one for UEFI systems.
And UEFI doesn't have concept of "active" partitions. It searches for its payload by examining Boot options, held in its environment in non-volatile storage, and only then, if not succeeded, falls to the "default" behavior, well defined in section 3.4 "Boot Mechanisms" of the specification. Shortly, the UEFI Boot Manager after failing to load its payload from a normal options' defined scenario, will enumerate all removable "media" devices, followed by "fixed" ones. (although it's quite silly to expect a meaningful distinction between removable and persistent storage nowadays). Without specified order in the groups, it will try to load using FS protocol, then image protocol for every device, with possible additional enumeration if it happens that the device doesn't support FS protocol, but supports IO block protocol. then children of that device are tried too with the same algorithm. The FS protocol means booting from FAT (or any else FS, but it should be supported by the device handle, meaning the appropriate FS driver should exist), the "load image protocol" means loading some "obscure" PE image from a device that understands how to load the image "directly" from it, meaning the driver of this device is able to populate memory with the image by some specific to it means. and then passing to the loaded image all the remining FilePath so that the image could do farther job by itself.
Default loading for the FS variant adds to the path \efi\boot\boot{machine_type}.efi. It's only a fallback. And even
"optional" for fixed media devices. Normally you use boot options having the path pointing to the image to load.
See, it's not like MBR booting, it requires from you to just put your loader into a proper location in the FS, basically you are free to put it wherever you want, just don't screw up Boot option creation so that it will point exactly where the file is.
It's not that hard having already different loaders for both scenarios just add two installation layouts for them. It looks easier for me, than that juggling trying to make BIOS work on GPT disks.