Re: Bug#1128432: ISO UEFI GPT illegal layout prevents detection/boot by some firmwares

Hi,

Just to add my two cents, I believe that any ISOHybrid that uses GPT as 
its partition scheme will always be in breach of the UEFI specs unless 
it is written (in dd mode) to a media that is exactly the same size as 
the ISO.

The reason for this has to do with the backup GPT, which must reside at 
the end of the disk, and is referenced in the main GPT, and is 
elaborated in https://bugzilla.redhat.com/show_bug.cgi?id=2420697. This 
also explains why validation of the media, through byte-by-byte 
comparison with the original ISO image (which is the basic issue of the 
report I pointed to), will always fail if said media was ever plugged on 
a Windows system, as Windows will fix the broken backup GPT, and update 
the prime GPT with the offsets of the (corrected) backup GPT.

In short, I do not believe that you can write a GPT based ISOHybrid, in 
dd-like mode, and get a drive that will be compliant with the UEFI 
specs, because (unless your target disk is not one sector larger than 
the source ISO) the backup GPT will always be broken.

Or maybe I am misreading what is being discussed here entirely.

Regards,

/Pete

On 2026.02.20 08:42, Thomas Schmitt wrote:
> Hi,
> 
> Tj <[email protected]> wrote:
>> I've found is the hybrid GPT is illegal so any tool that verifies GPT
>> integrity will fail.
>> [...]
>> The gdisk tools also loudly report this GPT invalidity.
> 
> Significant nitpicking:
> The GPT is invalid because it is not announced by a "protective MBR"
> partition of type 0xEE and thus cannot be illegal.
> The firmware is at fault already by considering the partition table
> that is governed by the invalid GPT header block at LBA 1.
> 
> AFAIK (being accessory to the crime) the invalid GPT is present to
> lure in firmwares, like old versions of OVMF, which don't accept the
> (virtual) storage device as bootable disk if it only has a MBR
> partition table.
> You obviously found a firmware which hates this trick.
> 
> 
> You could try to just deface the GPT header block
> 
>    # Write the path to your Debian ISO or USB stick here
>    iso=debian-13.1.0-amd64-netinst.iso
>    # iso=/dev/sdX
> 
>    dd if=/dev/zero conv=notrunc bs=512 seek=1 count=1 of="$iso"
> 
> If you do this directly with the USB stick (e.g. /dev/sdc) be extremely
> careful to give the right /dev/ address and run dd under sudo.
> (It might be necessary to unplug and replug the USB stick afterwards.)
> 
> A cautious user might want to use xorriso-dd-target to verify the
> address:
> 
>    xorriso-dd-target -with_sudo sdc
> 
> to get a confirming evaluation like
> 
>    sdc : YES : usb+ has_iso9660+ has_vfat+
> 
> or stern warnings like
> 
>    sdc : NO  : not_usb- has_vfat+ has_ext4-
>    sdc : NO  : usb+ has_iso9660+ has_vfat+ has_ext2-
> 
> which show that the device is not connected via USB and/or has
> filesystems other than ISO 9660 or FAT. This would be suspicious with
> a USB stick that shall be overwritten by an ISO image.
> 
> If GPT is still recognized, you will have to deface the GPT backup
> header block, too. It sits at the last block address of the storage
> device, which above dd command would have to use with its option seek= .
> 
> 
>> 1. GPT EFI System partition (usually #2) has type-code Basic data (0700)
>> not EFI SP (EF00)
> 
> Yep. Totally invalid. I assume it was intentional, not to create more
> confusion in the readers of the partition tables. The inventor
> described the layout in
>    http://mjg59.dreamwidth.org/11285.html
> from where i learned it and since then offer it in xorriso.
> 
> 
>> 3. The hybrid GPT's I've examined for multiple ISO images (Debian,
>> LinuxMint, Ubuntu) have a variety of problems reported by gdisk tools.
> 
> That's because firmwares are so hunchbacked.
> Legacy BIOS in old HP laptops wants to see a MBR partition with "boot"
> flag, various UEFIs want to see a glimpse of GPT (despite the specs
> saying that MBR partition type 0xEF is acceptable too.)
> It is nearly impossible to serve them all in a single ISO image.
> 
> Other distros have left behind some of these jackalopes in favor of
> a neat partition layout in their hybrid ISOs. (xorriso can do it
> specs compliant if the user wants it.)
> 
> 
>> For example, I noticed in the LinuxMint ISO GPT shows 2 partitions with
>> partition #2 (EFI-SP) completely contained within partition #1.
> 
> This should be the case with Debian amd64 ISOs, too.
> The reason is that the EFI boot image is a file in the ISO filesystem.
> Better would be to have it as appended partition like in the Debian
> ISOs for arm64.
> 
> (The Debian arm64 ISOs have two EFI boot images, because the El Torito
>   image is still a file in the ISO filesystem.
>   Hint to debian-cd:
>   This duplication could meanwhile be avoided by xorrisofs option
>     -e --interval:appended_partition_2:all::
>   instead of
>     -e /boot/grub/efi.img
>   Then the file /boot/grub/efi.img in the ISO could be omitted.
> )
> 
> 
>> I provided the owner of this issue a workaround  in the form of a shell
>> script that extracts the EFI-SP and root file-system from the ISO and
>> writes into a file containing a regular block layout.
> 
> Untested:
> You could also simply partition a USB stick to your liking, create a
> FAT filesystem of sufficient size, and copy all files from the ISO
> into that FAT filesystem.
> In Debian amd64 ISOs the directory /EFI is a copy of the tree in the
> FAT filesystem of the boot image.
> 
> (MS-Windows seems to have created a tradition that the FAT partition
> does not even have to bear the defined type of a EFI system partition.
> Firmwares seem to look into any FAT filesystem for an \EFI\BOOT
> directory.)
> 
> 
> Have a nice day :)
> 
> Thomas
>