I've been working with an Acer Vero owner that has InsydeH20 UEFI
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
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
cannot be booted.

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

The gdisk tools also loudly report this GPT invalidity. In the diagnosis
I performed I modified gdisk source-code to over-ride its refusal to
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
failure.

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

I modified gdisk source so that "sgdisk --typecode=2:EF00 /dev/sdz"
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
and copied in the EFI-SP contents from the ISO image.

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

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

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

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

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. The file can be
written to USB verbatim. I'm waiting for confirmation that the owner can
get the Acer Vero / InsydeH2O to boot the image, but I've already done
tests in QEMU with Secure Boot enabled and disabled and the installer(s)
start correctly.

Using the script I described to convert the ISO to a regular block
device is confirmed to work for the Acer Aspire Vero's InsydeH20
firmware, both for the Debian 13.3 netinst and a Linux Mint 22.3 live
desktop.

I'm attaching the script for anyone else needing a workaround.

Hi,

Tj <tj.iam.tj@proton.me> wrote:
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= .

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.

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.)

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.
)
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