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

Package: debian-cd
Version: 3.2.3

I've been working with an Acer Vero owner that has InsydeH20 UEFI=20
firmware that does not recognise a USB containing the Debian installer.

As you may know InsydeH20 has an option in its Security menu:

"Select an UEFI file as trusted for executing"

This triggers a file selection dialog that offers all discovered devices=20
and allows navigation to, and selection of, the initial boot loader file.

For USB this is the Removable Media Path /EFI/BOOT/BOOT${architecture}.EFI

A USB with hybrid ISO image on is not offered and so Debian installer=20
cannot be booted.

I've done a considerable amount of methodical diagnosis into this. What=20
I've found is the hybrid GPT is illegal so any tool that verifies GPT=20
integrity will fail. I believe this is what happens with InsydeH2O and=20
it does not fall-back to reading the valid DOS label and therefore does=20
not discover the EFI System Partition.

The gdisk tools also loudly report this GPT invalidity. In the diagnosis=20
I performed I modified gdisk source-code to over-ride its refusal to=20
operate on illegal GPT in order to explore the issue further.

In examining the layout I found a series of issues that might cause the=20
failure.

1. GPT EFI System partition (usually #2) has type-code Basic data (0700)=20
not EFI SP (EF00) - note I'm not typing the real GUIDs here to help=20
readability.

I modified gdisk source so that "sgdisk --typecode=3D2:EF00 /dev/sdz"=20
would write the correct GUID and update header CRC despite the problems.
This did not help.

2. I created a new, basic, block device image with single GPT partition=20
and copied in the EFI-SP contents from the ISO image.

InsydeH2O sees this device, allows its BOOTX64.EFI to be trusted, and=20
boots into GRUB.

3. The hybrid GPT's I've examined for multiple ISO images (Debian,=20
LinuxMint, Ubuntu) have a variety of problems reported by gdisk tools.

For example, I noticed in the LinuxMint ISO GPT shows 2 partitions with=20
partition #2 (EFI-SP) completely contained within partition #1.
For the Debian netinst 13.3 ISO image partition #1 cannot be reported by=20
modified sgdisk but it warns of the (unreported) first partition=20
overlapping the GPT header.

I did some considerable work about 10 years ago on a valid hybrid layout=20
that I could revisit if there is an appetite for it, but I do wonder if=20
we do still need to distribute the installer as an hybrid ISO rather=20
than a regular block device? The only use I can think is due to tools=20
like libvirt expecting installer images to be ISOs.

I provided the owner of this issue a workaround=C2=A0 in the form of a shel=
l=20
script that extracts the EFI-SP and root file-system from the ISO and=20
writes into a file containing a regular block layout. The file can be=20
written to USB verbatim. I'm waiting for confirmation that the owner can=20
get the Acer Vero / InsydeH2O to boot the image, but I've already done=20
tests in QEMU with Secure Boot enabled and disabled and the installer(s)=20
start correctly.