On Sat, Apr 9, 2022 at 1:51 AM Thomas Schmitt <scdbac...@gmx.net> wrote: > > Hi, > > > 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. > > One could probably use core.img for booting from USB stick. But it would > not obsolete the x86 code in MBR and it currently is not necessary for > grub-mkrescue ISOs because eltorito.img does a job equivalent to core.img. > eltorito.img is stored in the ISO 9660 filesystem as normal data file. > The MBR x86 code transfers execution to it and the El Torito catalog has > it as boot image for x86 legacy BIOS.
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. > > 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. > > That's why grub-mkrescue lets xorriso produce a pure GPT with no > boot/active flag at the 0xEE partition. But this lets old HP laptops > refuse to boot from USB stick. > A foul compromise is to add another MBR partition of type 0x00 with > boot/active flag. EFI is known to ignore it, but HP legacy BIOS takes it > as reason to run the MBR x86 code (which is not related to partitions). > > > > (b) we don't really want to work around buggy > > BIOS firmware anyway, we want them to fail here rather than later. > > That's a harsh decision but would match the purpose of this thread, indeed. > If so, then producing a pure GPT instead of the current jackalope seems > the way to go. grub-mkrescue will point the way or could even be the > solution to go for. Still another idea might be to create a "legacy" image variant of Everything ISO that does things exactly as we do them today. That way there is a fallback for one image that isn't release blocking, for as long as it can be maintained. The one thing I think we'd still need to tweak sooner than later is swapping isolinux with GRUB. A legacy/fallback image (or two) would provide some breathing room to remove more legacy layers. Including possibly even ISO 9660. If Everything ISO is for that use case, desktop and server images can focus on being USB centric, including supporting persistence out of the box. > > I would propose to care for a mountable ISO 9660 partition, by moving > the EFI boot image / EFI system partition out of the filesystem and > rather appending it as extra partition. An example can be created by > MKRESCUE_SED_MODE=gpt_appended with script frontend/grub-mkrescue-sed.sh > out of libisoburn.) > Further one would need xorrisofs option > -partition_offset 16 > so that a mountable GPT partition can be created which starts at 512-block > address 64, i.e. after the GPT partition table data. This wastes some > space because a second directory tree has to be generated additionally to > the normal directory tree which will be used when booting or mounting > the ISO from a DVD. > The waste would not be much with Fedora Live ISOs. In 3-year-old > Fedora-Workstation-Live-x86_64-31-1.9.iso the first data file is already > at 2048-block address 43. That would be at most 23 * 2048 bytes for the > directory records which form the file tree (43 - 16 blocks System Area - > 4 blocks of Volume Descriptors). So the waste would be <= 46 KiB. > > At that occasion consider to drop the HFS+ Mac boot image and the Apple > Partition map which marks it for some obscure non-EFI x86 Macs. I.e. > consider to remove from the current xorrisofs command the options > -eltorito-alt-boot > -e images/macboot.img -no-emul-boot -isohybrid-gpt-hfsplus > and try to find a Mac which misses this boot image and refuses to boot > but boots with the original ISO. I have a 2011 Mac. Virtually certain ages ago I booted an openSUSE ISO from USB stick, no problem, and it had no special tricks liks Fedora is using (HFS+ and mactel boot). > > 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. > > A PMBR is an MBR at the start of a partition and gets activated only > if the device MBR decides to do so. Sometimes there is MBR code on newly > bought USB sticks which looks for a partition with boot/active flag and > then chain-loads the PMBR from there. > But in an EL Torito bootable ISO this makes few sense. The little > hybrid MBR and the larger BIOS boot image can do everything that is > needed. > > A neat partition map is indeed a valuable goal. To my knowledge it can > only be achieved by dropping support for the buggy legacy BIOSes which > demand to see an MBR partition with boot/active flag or by dropping > support for buggy EFIs which do not recognize the MBR partition type > 0xEF unless a smell of GPT is on the storage device. > > --------------------------------------------------------------------- > Just for the fun of it i post xorriso's assessment of the jackalope boot > equipment in Fedora-Workstation-Live-x86_64-31-1.9.iso : > > $ xorriso -indev Fedora-Workstation-Live-x86_64-31-1.9.iso > -report_el_torito plain -report_system_area plain > ... > El Torito catalog : 42 1 > El Torito cat path : /isolinux/boot.cat > El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA > El Torito boot img : 1 BIOS y none 0x0000 0x00 4 16852 > El Torito boot img : 2 UEFI y none 0x0000 0x00 21716 43 > El Torito boot img : 3 UEFI y none 0x0000 0x00 45520 5472 > El Torito img path : 1 /isolinux/isolinux.bin > El Torito img opts : 1 boot-info-table isohybrid-suitable > El Torito img path : 2 /images/efiboot.img > El Torito img path : 3 /images/macboot.img > System area options: 0x00000202 > System area summary: MBR isohybrid cyl-align-off GPT > ISO image size/512 : 3768320 > Partition offset : 0 > MBR heads per cyl : 0 > MBR secs per head : 0 > MBR partition table: N Status Type Start Blocks > MBR partition : 1 0x80 0x00 0 3768320 > MBR partition : 2 0x00 0xef 172 21716 > MBR partition : 3 0x00 0x00 21888 45520 > MBR partition path : 2 /images/efiboot.img > MBR partition path : 3 /images/macboot.img > GPT : N Info > GPT disk GUID : 892c8c3c5015534296ffb0417be2c61f > GPT entry array : 2 248 overlapping > GPT lba range : 64 3768256 3768319 > GPT partition name : 1 490053004f00480079006200720069006400 > GPT partname local : 1 ISOHybrid > GPT partition GUID : 1 892c8c3c5015534296feb0417be2c61f > GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7 > GPT partition flags: 1 0x1000000000000001 > GPT start and size : 1 0 3768256 > GPT partition name : 2 490053004f004800790062007200690064003100 > GPT partname local : 2 ISOHybrid1 > GPT partition GUID : 2 892c8c3c5015534296fdb0417be2c61f > GPT type GUID : 2 a2a0d0ebe5b9334487c068b6b72699c7 > GPT partition flags: 2 0x1000000000000001 > GPT start and size : 2 172 21716 > GPT partition path : 2 /images/efiboot.img > GPT partition name : 3 490053004f004800790062007200690064003200 > GPT partname local : 3 ISOHybrid2 > GPT partition GUID : 3 892c8c3c5015534296fcb0417be2c61f > GPT type GUID : 3 005346480000aa11aa1100306543ecac > GPT partition flags: 3 0x1000000000000001 > GPT start and size : 3 21888 45520 > GPT partition path : 3 /images/macboot.img > > Note that the MBR partition table is not "protective" by consisting only > of one partition of type 0xEE. Thus the GPT is not valid, which is good > so, because the EFI system partition in GPT does not show the prescribed > Type GUID 28732ac11ff8d211ba4b00a0c93ec93b > aka C12A7328-F81F-11D2-BA4B-00A0C93EC93B. > (I wonder why this ISO does not show an Apple Partition Map. The xorrisofs > options shown in this thread should have caused one.) I noticed the APM seemed to go away at one point - I'm not sure when. I thought the command had changed but maybe there's a conflict with one of the other commands now? > > For comparison a grub-mkrescue ISO for BIOS and EFI: > > ... > El Torito catalog : 1669 1 > El Torito cat path : /boot.catalog > El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA > El Torito boot img : 1 BIOS y none 0x0000 0x00 4 3544 > El Torito boot img : 2 UEFI y none 0x0000 0x00 5760 84 > El Torito img path : 1 /boot/grub/i386-pc/eltorito.img > El Torito img opts : 1 boot-info-table grub2-boot-info > El Torito img path : 2 /efi.img > System area options: 0x00004201 > System area summary: MBR protective-msdos-label grub2-mbr cyl-align-off GPT > APM > ISO image size/512 : 30848 > Partition offset : 0 > MBR heads per cyl : 64 > MBR secs per head : 32 > MBR partition table: N Status Type Start Blocks > MBR partition : 1 0x00 0xee 1 30847 > GPT : N Info > GPT disk GUID : 07f29bb153383349a5ecd605dcf5ebd6 > GPT entry array : 20 176 separated > GPT lba range : 64 30802 30847 > GPT partition name : 1 4700610070003000 > GPT partname local : 1 Gap0 > GPT partition GUID : 1 07f29bb153383349a5e8d605dcf5ebd6 > GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7 > GPT partition flags: 1 0x1000000000000001 > GPT start and size : 1 64 272 > GPT partition name : 2 > 450046004900200062006f006f007400200070006100720074006900740069006f006e00 > GPT partname local : 2 EFI boot partition > GPT partition GUID : 2 07f29bb153383349a5e9d605dcf5ebd6 > GPT type GUID : 2 28732ac11ff8d211ba4b00a0c93ec93b > GPT partition flags: 2 0x1000000000000001 > GPT start and size : 2 336 5760 > GPT partition path : 2 /efi.img > GPT partition name : 3 48004600530050004c0055005300 > GPT partname local : 3 HFSPLUS > GPT partition GUID : 3 07f29bb153383349a5ead605dcf5ebd6 > GPT type GUID : 3 005346480000aa11aa1100306543ecac > GPT partition flags: 3 0x1000000000000001 > GPT start and size : 3 6096 24104 > GPT partition name : 4 4700610070003100 > GPT partname local : 4 Gap1 > GPT partition GUID : 4 07f29bb153383349a5ebd605dcf5ebd6 > GPT type GUID : 4 a2a0d0ebe5b9334487c068b6b72699c7 > GPT partition flags: 4 0x1000000000000001 > GPT start and size : 4 30200 600 > APM : N Info > APM block size : 2048 > APM gap fillers : 2 > APM partition name : 1 Gap0 > APM partition type : 1 ISO9660_data > APM start and size : 1 16 1508 > APM partition name : 2 HFSPLUS_Hybrid > APM partition type : 2 Apple_HFS > APM start and size : 2 1524 6026 > APM partition name : 3 Gap1 > APM partition type : 3 ISO9660_data > APM start and size : 3 7550 162 > > The Apple Partition Map (APM) marks the mount point of the internal HFS+ > filesystem tree. If we are speaking of legacy, then this is the most > obsolete part of a grub-mkrescue ISO. I'm pretty sure we don't need either APM or HFS+ stuff for mac support anymore. But all the more reason to make an "older models" best effort. -- Chris Murphy _______________________________________________ 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
