pMBR size and backup GPT location issue with xorriso-produced GPT-labeled ISO

[Adam Williamson]

Hi folks!

I've been helping out with Fedora's test of moving live image building
from our livemedia-creator tool to Kiwi. Both tools ultimately use
xorriso to produce the final ISO; lmc calls it as xorrisofs, Kiwi calls
it as xorriso.

Recently we realized that, while lmc produces ISOs with a GPT disk
label, Kiwi produces images with an MBR disk label - see
https://bugzilla.redhat.com/show_bug.cgi?id=2328590 for a lot of
discussion. I made a very simple change to Kiwi's xorriso invocation to
try and get it to produce a GPT-labelled ISO, and it...more or less
works, but produces a disk label that fdisk flags up some issues with.

This is an example of the kind of xorriso command Kiwi winds up
running:

/usr/bin/xorriso -application_id Fedora-KDE_Desktop-Live-Rawhide -publisher 
Fedora Project -preparer_id KIWI - https://github.com/OSInside/kiwi -volid 
Fedora-KDE-Live-rawh -joliet on -padding 0 -outdev 
/builddir/result/image/Fedora-KDE-Desktop-Live.x86_64-Rawhide.iso -map 
/builddir/result/image/live-media.reu4q9wb / -chmod 0755 / -- -boot_image grub 
bin_path=boot/x86_64/loader/eltorito.img -boot_image grub 
grub2_mbr=/builddir/result/image/live-media.reu4q9wb/boot/x86_64/loader/boot_hybrid.img
 -boot_image grub grub2_boot_info=on -boot_image any partition_offset=16 
-boot_image any cat_path=boot/x86_64/boot.catalog -boot_image any cat_hidden=on 
-boot_image any boot_info_table=on -boot_image any platform_id=0x00 -boot_image 
any emul_type=no_emulation -boot_image any load_size=2048 -append_partition 2 
0xef /builddir/result/image/efi-loader.qyzkn5d3 -boot_image any next 
-boot_image any efi_path=--interval:appended_partition_2:all:: -boot_image any 
platform_id=0xef -boot_image any emul_type=no_emulation

That results in a pure MBR disk label - the first 512 bytes of the ISO
have a 'real' MBR, the next 512 bytes are empty. I tweaked Kiwi to add:

-boot_image any appended_part_as=gpt

right before -append_partition. With that change, we get a GPT-labeled
ISO - the first 512 bytes have the 'protective MBR' required in the
UEFI spec, the next 512 bytes have the GPT header.

However, when I run fdisk -l on the resulting image (which you can
download at
https://adamwill.fedorapeople.org/04486579-Fedora-KDE-Live-x86_64-126373438_126372371.iso
), it flags up a couple of problems:

GPT PMBR size mismatch (5692751 != 5692799) will be corrected by write.
The backup GPT table is not on the end of the device.
Disk 04486579-Fedora-KDE-Live-x86_64-126373438_126372371.iso: 2.71 GiB, 
2914713600 bytes, 5692800 sectors

The first is complaining about the final field in the single entry in
the protective MBR partition table. This is the SizeInLBA field, it's
four bytes long. Per the UEFI spec it should be "Set to the size of the
disk minus one". In the hex dump of this image, it is 4f dd 56 00, so
that's 0x0056dd4f, which is indeed 5692751 in decimal. And if fdisk is
right about the size of the image (5692800 sectors), that does indeed
seem to be wrong, it should be 5692799, or 0x0056dd7f in hex.

The other error is, well, fairly self-explanatory, but I dunno why the
backup GPT table would be in the wrong place - but maybe these two
issues are related, and xorriso is generally slightly confused (for
some reason) about where the disk ends, so it put the backup GPT
slightly before the end of the disk *and* made the SizeInLBA value
slightly too small?

Does anyone know what might be going on here? Is there a bug in xorriso
or a problem in the command we're using? Thanks!

For comparison, the xorrisofs command livemedia-creator winds up
running looks like this:

xorrisofs -o /var/tmp/lmc-work-0_mfjxid/images/boot.iso -R -J -V 
Fedora-KDE-Live-rawh-20241121-n- --grub2-mbr 
/var/tmp/lorax.imgutils.ljeagd9j/usr/lib/grub/i386-pc/boot_hybrid.img 
-partition_offset 16 -appended_part_as_gpt -append_partition 2 
C12A7328-F81F-11D2-BA4B-00A0C93EC93B 
/var/tmp/lmc-work-0_mfjxid/images/efiboot.img -iso_mbr_part_type 
EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 -c boot.cat --boot-catalog-hide -b 
images/eltorito.img -no-emul-boot -boot-load-size 4 -boot-info-table 
--grub2-boot-info -eltorito-alt-boot -e --interval:appended_partition_2:all:: 
-no-emul-boot -graft-points 
images/pxeboot=/var/tmp/lmc-work-0_mfjxid/images/pxeboot 
LiveOS=/var/tmp/lmc-work-0_mfjxid/LiveOS 
Fedora-Legal-README.txt=/var/tmp/lmc-work-0_mfjxid/Fedora-Legal-README.txt 
LICENSE=/var/tmp/lmc-work-0_mfjxid/LICENSE 
boot/grub2=/var/tmp/lmc-work-0_mfjxid/boot/grub2 
boot/grub2/i386-pc=/var/tmp/lorax.imgutils.ljeagd9j/usr/lib/grub/i386-pc 
images/eltorito.img=/var/tmp/lmc-work-0_mfjxid/images/eltorito.img 
EFI/BOOT=/var/tmp/lmc-work-0_mfjxid/EFI/BOOT

That command produces a GPT-labeled ISO which fdisk has no complaints
about. It's slightly smaller than the Kiwi one, 5502240 sectors. The
SizeInLBA value in the pMBR is 0x0053f51f , which is decimal 5502239 ,
so correct. That image can be found at
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20241121.n.0/compose/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-Rawhide-20241121.n.0.iso
, until it gets garbage-collected at least (but similar images will
still be available if needed).
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org
https://www.happyassassin.net