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