On 4/9/22 03:07, Chris Murphy wrote:
On Fri, Apr 8, 2022 at 4:31 PM Thomas Schmitt <scdbackup@xxxxxxx> wrote:
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.
If they did, then they would have problems with GPT disks, initialized
by Windows 10, because Windows 10 puts its standard non-GPT aware
bootloader code there. :)
Only Fedora-initialized disks have zeros there. :)
I can confirm this, because I have three disks (two 512GB SSDs and one
2TB HDD) on my UEFI-enabled, dual booting between Windows 11 and Fedora,
desktop computer.
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.
I haven't looked at GRUB's MBR code, but there's enough space in the MBR
to scan the GPT entries, find a specific GUID partition type and load
the first several kilobytes from it and transfer control to it. And this
is even without assuming 512-byte sectors. I know this, because I have
written such code for my hobby DOS-like OS, which I want to be able to
support GPT in BIOS legacy mode, so it can coexist with modern Windows
and Linux distros (which boot in UEFI mode, while my OS boots in legacy
mode - I can switch between the two modes from my UEFI boot menu).
Here's the code I've written (consider it proof of concept), but it can
be used by GRUB as well:
https://sourceforge.net/p/fpcdos/code/HEAD/tree/trunk/src/gptboot/mbr.asm
The code takes up only 262 bytes so far, so it has plenty of bytes to
spare (for e.g. nicer diagnostic error messages). The only thing it
assumes is that the INT 13h LBA BIOS extensions are available - there's
no CHS fallback support.
The code *doesn't* assume that the sectors size is 512 bytes, it doesn't
assume the GPT partition it is looking for is in a specific position in
the table, or starting on a specific LBA, it doesn't assume the number
of GPT partitions are less than 128, it doesn't assume that GUID
partition entries are 128-byte sized and it doesn't care about the 4 MBR
partitions at all, it only searches through the GPT partitions.
The code assumes that the GPT partition table is correct, and doesn't do
a lot of error checking, e.g. it doesn't check the CRC32 fields in the
GPT header.
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
_______________________________________________
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
