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. > 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. 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. > Some legacy BIOS insist on seeing certain MBR structures in LBA 0 or > they face plant. I only know of the buggy demand for a boot/active flag at some MBR partition. If you can name more stumble stones, i would be highly interested to learn about them. > 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.) 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. A description of the above listing format is put out by a run of xorriso -report_el_torito help -report_system_area help 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
