Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

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

 



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@xxxxxxxxxxxxxxxxxxxxxxx/message/EY4Q5EDHLFW6TBJQTJMJUS6LM6U5ZBFW/
  Date: Sun, 10 Apr 2022 00:29:54 +0200
  Message-Id: <28174385295326549884@xxxxxxxxxxxxxxxxxxxxxx>

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@xxxxxxxxxxxxxxxxxxxxxxx/message/4DSTL34BTZEINKMA3VSBDTJHYSD7VO3O
  Date: Fri, 08 Apr 2022 20:29:07 +0200
  Message-Id: <25501385177039509423@xxxxxxxxxxxxxxxxxxxxxx>
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-xorriso@xxxxxxx
or in private, if not here. Cc me when starting a discussion here.


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