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

[Thomas Schmitt]

Hi,

Adam Williamson wrote (and i added newlines and '\' for clarity):
> /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.

Try with xorriso command

   -compliance no_emul_toc

The position in the command list does not matter much with this command.
It just has to be given before the ISO gets written by -commit or by the
end of the command list if not -dialog is "on".


------------------------------------------------------------------------
Reasoning:

The number 5692799 (+1) looks like the effect of the padding to get end
alignment to chunks of 32 blocks of 2048 bytes, which is a preparation for
multi-session on overwritable media:
  (5692799.0 + 1.0) / 4.0 / 32.0 = 44475.0
A data file or a block device is handled as such a medium, similar to
DVD+RW or BD-RE media.
(Division by 4 is done because GPT counts by blocks of 512 bytes.)

This padding together with the separate multi-session superblock can be
disabled by xorriso command
  -compliance no_emul_toc
which the mkisofs emulation of xorriso applies by default.

On the other hand the native command mode of xorriso leans much to
multi-session for data backups. So the emulated table-of-content is
enabled by default.

The 32-blocks alignment padding is not considered to be part of the
ISO 9660 filesystem. So the position of the backup GPT and the count in
the protective MBR do not take it into account.

In general multi-session and bootability do not play well together.
When modification of existing bootable ISOs is desired with preserved
boot equipment, then the better approach is

  -indev "$orig_iso" -outdev "$new_iso" ... -boot_image any replay

See for an example:
  
https://wiki.debian.org/RepackBootableISO#In_xorriso_load_ISO_tree_and_write_modified_new_ISO

For a technical description of multi-session table-of-content emulation
see
  https://dev.lovelyhq.com/libburnia/libburn/raw/branch/master/doc/cookbook.txt
sections "ISO 9660 multi-session emulation on overwriteable media"
and "ISO 9660 based TOC emulation on overwriteable media"

Another reason for GPT-size smaller than image file size would be the
default padding of 150 blocks against the Linux TAO CD read-ahead bug.
(It is very old and laden with urban legends ...)

The xorriso command list of Kiwi has -padding 0. So this padding cannot
spoil GPT-size in the Kiwi ISO.
If this padding would be desired because the ISO could end up on a CD,
then command
  -padding included
would cause the padding to be counted as part of the ISO 9660 filesystem.
This padding mode is enabled by default in mkisofs emulation.
Therefore the ISO made with mkisofs emulation has no GPT size problem,
although option -no-pad is not among the given options.


Have a nice day :)

Thomas