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/
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.)
Hi,
so the world might begin to split into incompatible camps. /cdimage. debian. org/debian- cd/current/ amd64/iso- cd/
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:/
But this GPT allergy would have to be verified by repacking a GPT Ubuntu /bugs.launchpad .net/ubuntu- cdimage/ +bug/1886148/ comments/ 174
ISO to a MBR Ubuntu ISO which the Lenovos seem to hate.
Continuing the repack endeavors of
https:/
one may do
original= groovy- desktop- amd64_20201010_ gpt.iso
test -f test_mbr.iso && rm test_mbr.iso
xorriso \ part_as= mbr
-indev "$original" \
-outdev test_mbr.iso \
-boot_image any replay \
-boot_image any appended_
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 \ bootflag. iso \ part_as= gpt \ bootable= on
-indev "$original" \
-outdev test_gpt_
-boot_image any replay \
-boot_image any appended_
-boot_image any mbr_force_
(If partition editors complain about some Protective MBR mismatch in bootflag. iso: I am investigating this. It happens only with
test_gpt_
replay runs. Let's hope it does not influence the outcome ot the test.)
Have a nice day :)
Thomas