On Fri, Apr 8, 2022 at 4:31 PM Thomas Schmitt <scdbackup@xxxxxxx> wrote: > > Hi, > > Chris Murphy wrote: > > Is there a possibility of dropping MBR? i.e. use GPT containing both a > > biosboot partition type, and EFI System partition type? > > I am not aware that legacy BIOS would hop directly on any GPT partition > or any MBR partition table partition. > > The convention for hard-disk-like devices is to start the x86 code in > bytes 0 to 439 (or maybe to byte 445) of the MBR as 16-bit program. > In case of ISOLINUX or GRUB hybrid MBR, the only goal is to hand over > program execution to the El Torito boot image which is allowed to be > larger and is also the starting point for booting from DVD. > The connection is made by xorriso by patching the LBA of the boot image > into the x86 code of the MBR. Format and byte address for this patching > depends on the boot loader. Thus the mutually exclusive options > -isohybrid-mbr and --grub2-mbr. OK so there isn't (yet) an option to embed the GRUB core.img in a GPT BIOS boot partition, I take it? The assumption is MBR? On hard drives, core.img goes in the MBR gap. I'm not sure where it goes on xorriso produced ISOs though, but presumably not the gap because there's a valid GPT there too. > > The advantage of this is not just to get rid of MBR really. > > We have the room for those 440 bytes anyways if we have GPT. > The magic number of GPT is the "protective" MBR partition table at > bytes 446 to 509. There must be one partition slot of type 0xee and > no other valid partition marked by the other three slots. > The content of bytes 0 to 439 is specified by UEFI for "Protective > MBR" as "Unused by UEFI systems". In contrast to that, the bytes from > 440 to 445 are specified as "Unused. Set to zero." > (UEFI 2.4 Table 15, UEFI 2.8 Table 19) Yeah, I'm not aware off hand of any UEFI that have a problem with the first 440 bytes of LBA 0 being non-zero. I am aware though, of this tianocore bug [1] where if the active bit on that 0xEE partition is set, the GPT is considered invalid. This is now fixed in Tianocore, but it might be widespread in firmware in hardware. But the idea would be to not set this boot flag on our increasingly hypothetical future ISOs because (a) it might cause UEFI to drop to an EFI shell, if this bug is more widespread (b) we don't really want to work around buggy BIOS firmware anyway, we want them to fail here rather than later. Pretty sure I discovered this bug when testing Fedora 35 Cloud base images, which are GPT with PMBR, and boot both BIOS and UEFI systems. There's jump code in the first 440 bytes of LBA 0, pointing to the core.img in BIOS Boot partition, and also there's an EFI system volume that UEFI firmware discover. > > But if > > there are still some systems out there that will face plant on GPT > > anyway, it's probably best if they face plant when booting the > > installation media rather than getting all the way to a successful > > installation, just to face plant upon reboot. > > Legacy BIOS does not care for partition tables. At least to my knowledge > from supporting production of bootable ISOs. My mileage may vary. > Problems with partitions will arise only after BIOS handed control to > the MBR x86 code on USB stick or the El Torito boot image on DVD. Some legacy BIOS insist on seeing certain MBR structures in LBA 0 or they face plant. This was why Fedora never proceeded with GPT by default on BIOS systems. Too many at the time didn't like the PMBR for one reason or another. I think the more common reason (?) was the single partition in the PMBR didn't have BootIndicator set, hence parted's pmbr_boot flag, which sets this bit. > Possibly this here describes what is needed for GRUB if started by > legacy BIOS and facing GPT: > https://wiki.archlinux.org/title/GRUB#BIOS_systems > I understand that the GPT boot partition substitutes for the traditional > gap between MBR block and the start of the first MBR partition. 1 MiB > of "embedded area" if i remember correctly. yeah that's what I'm calling BIOS boot partition type, it's partition type GUID is 21686148-6449-6E6F-744E-656564454649 which grub-install is looking for, and how it knows where to embed core.img. But as I understand it, the code in the first 440 bytes of LBA 0, written by grub-install as well, is just jump to the LBA for core.img. There's no code to "teach" the computer how to read the GPT and go find BIOS Boot. It's a hard coded LBA to just blindly jump to. > > But grub-mkrescue ISOs have GPT without a dedicated boot partition. > Probably that job is fulfilled by the El Torito boot image which has a > few more KiB than the MBR x86 code. > > So i assume that face planting will happen only at later stages if the > booted system makes false assumptions like "GPT means EFI". Well it's been a long time since the GPT by default attempts, so I kinda forget how they manifested, though that information is probably in this list's archive :) My vague recollection is black screen. That's it. No error, no forward progress. Maybe some systems had an underscore character in the upper left corner? Maybe? Anyway, too many people hit it and it was canned so we never did it. If we can opt out of making a hybrid/faux MBR, and create a PMBR instead, that'd also mean there's one clear unambiguous partition map for USB sticks, which could make it easier to implement persistence. [1] https://bugzilla.tianocore.org/show_bug.cgi?id=3474 -- Chris Murphy _______________________________________________ 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
