Comment 10 for bug 1899308

Hi,

so the world might begin to split into incompatible camps.
New Lenovos versus old HPs.
Debian still has the "mac" amd64 ISOs which simply have no EFI equipment
in order to please some old Apple machines:
  https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/

But this GPT allergy would have to be verified by repacking a GPT Ubuntu
ISO to a MBR Ubuntu ISO which the Lenovos seem to hate.
Continuing the repack endeavors of
  https://bugs.launchpad.net/ubuntu-cdimage/+bug/1886148/comments/174
one may do

  original=groovy-desktop-amd64_20201010_gpt.iso

  test -f test_mbr.iso && rm test_mbr.iso

  xorriso \
    -indev "$original" \
    -outdev test_mbr.iso \
    -boot_image any replay \
    -boot_image any appended_part_as=mbr

Partition editors should report MBR/DOS partition table and boot flag

  $ /sbin/fdisk -l test_mbr.iso
  ...
  Disklabel type: dos
  ...
  Device Boot Start End Sectors Size Id Type
  test_mbr.iso1 * 64 5724655 5724592 2.7G 83 Linux
  test_mbr.iso2 5724656 5734607 9952 4.9M ef EFI (FAT-12/16/32)

If this does not boot then it is not about MBR or boot flag, but about
something else.

If it boots, it's maybe only the addiction to MBR boot flags, for which
there is a barely legal solution:
One may create a pseudo partition with boot flag which is on the other
side invisible enough not to disturb GPT recognition.

  test -r test_gpt_bootflag.iso && rm test_gpt_bootflag.iso

  xorriso \
    -indev "$original" \
    -outdev test_gpt_bootflag.iso \
    -boot_image any replay \
    -boot_image any appended_part_as=gpt \
    -boot_image any mbr_force_bootable=on

(If partition editors complain about some Protective MBR mismatch in
 test_gpt_bootflag.iso: I am investigating this. It happens only with
 replay runs. Let's hope it does not influence the outcome ot the test.)

Have a nice day :)

Thomas