Hi,
Chris Murphy wrote:
> At least with the BIOS firmware without a bug, the GRUB LBA 0 code
> jumps direct to core.img, no instruction on how to read the GPT and
> find the core.img from BIOS boot partition.
That's probably because the GRUB MBR code for hard disk gets the LBA
of the next stage patched in at install time.
xorrisofs does the equivalent to the boot_hybrid.img MBR from GRUB:
--grub2-mbr disk_path
Install disk_path in the System Area and treat it as modern
GRUB2 MBR. The content start address of the first boot image is
converted to a count of 512 byte blocks, and an offset of 4 is
added. The result is written as 64 bit little-endian number to
byte address 0x1b0.
"Install in the System Area" means "Copy it to the start of the ISO image".
"first boot image" means the one that is pointed to by first entry in the
El Torito catalog, which is supposed to be the GRUB boot image for
El Torito. GRUB docs say that this image gets concatenated from "cdrom.img"
and a suitably built "core.img".
> Still another idea might be to create a "legacy" image variant of
> Everything ISO that does things exactly as we do them today.
This would be handy at least during the first months of a new ISO image
layout being used. Any user complaint could be checked whether the problem
was introduced by the ISO image change.
> A legacy/fallback image (or two) would provide some breathing room to
> remove more legacy layers. Including possibly even ISO 9660.
Aww. 14 years of xorriso development would be obsoleted. {:|
Giving up ISO 9660 would mean to give up El Torito, which means to give
up legacy BIOS booting from CD/DVD/BD.
With UEFI i am not so sure about the consequences. OVMF is known to boot
via partition table from qemu -cdrom devices and via El Torito from -hda.
Whether other EFIs do the same would have to be broadly tested.
UEFI 2.8 Errata A, February 2020 still has the prescription for EFI to
follow the El Torito boot catalog when it encounters an optical drive
with medium:
10.3.5.2 CD-ROM Media Device Path
The CD-ROM Media Device Path is used to define a system partition that
exists on a CD-ROM. The CD-ROM is assumed to contain an ISO-9660 file
system and follow the CD-ROM “El Torito” format. [...]
In EFI the bootable entity is an EFI System Partition that is pointed to
by the Boot Entry.
10.4.5 Media Device Path Rules
The Media Device Path is used to define the location of information on
a medium. Hard Drives are subdivided into partitions by the MBR and a
Media Device Path is used to define which partition is being used.
A CD-ROM has boot partitions that are defined by the “El Torito”
specification, and the Media Device Path is used to point to these
partitions.
(Somebody at UEFI should look at the statement "subdivided into
partitions by the MBR" whether this needs mentioning of GPT.)
EFI was not invented when El Torito was specified. Thus UEFI extends
the original El Torito specs by
13.3.2.1 ISO-9660 and El Torito
[...] To boot from a CD-ROM or DVD-ROM in the boot services environment,
an EFI System partition is stored in a “no emulation” mode as defined
by the “El Torito” specification. A Platform ID of 0xEF indicates an
EFI System Partition. EFI differs from “El Torito” “no emulation” mode
in that it does not load the “no emulation” image into memory and jump
to it. EFI interprets the “no emulation” image as an EFI system
partition. [... more technicalities follow ...]
> The one thing I think we'd still need to
> tweak sooner than later is swapping isolinux with GRUB.
I am optimistic that this will be possible with few new user complaints.
Summary as i understand this part of our discussion:
Fedora just has to decide whether it wants to stay with the layout
described in
https://mjg59.dreamwidth.org/11285.html
or whether it wants to migrate to a specs compliant GPT as i propose in
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EY4Q5EDHLFW6TBJQTJMJUS6LM6U5ZBFW/
Date: Sun, 10 Apr 2022 00:29:54 +0200
Message-Id: <28174385295326549...@scdbackup.webframe.org>
In the latter case the xorrisofs options to change are given in the above
list post. It would drop support for an obscure class of x86 Macs which
need HFS+ for booting, and it would drop support for a class of buggy
legacy BIOSes which don't boot if the boot/active isn't set in any MBR
partition table slot. (Old HP laptops have been caught with such BIOS.)
In the former case my change proposal is in
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4DSTL34BTZEINKMA3VSBDTJHYSD7VO3O
Date: Fri, 08 Apr 2022 20:29:07 +0200
Message-Id: <25501385177039509...@scdbackup.webframe.org>
Please read the first part up to "More unsolicited info:" to see all
proposed options.
I am ready to discuss xorriso-specific problems at bug-xorr...@gnu.org
or in private, if not here. Cc me when starting a discussion here.
Have a nice day :)
Thomas
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
