This morning (CET) I tested a cloned system from a modified iso file according to Thomas Schmitt;
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
in the HP Elitebook 8560p. With an external monitor and in recovery mode I could get it to the desktop. Actually it is enough for this debug task to get it to the grub menu, which fails with the original iso file because of the GUID partition table.
So I am sure that we have identified the problem. Thomas Schmitt's method is a second work-around, more direct and maybe more convenient than creating a persistent live drive with mkusb.
A solution would be to revert to the boot structure of 20.04.x LTS, which provides iso files that boot for all Ubuntu family iso files in all amd64 type computers, that we have tested.
This morning (CET) I tested a cloned system from a modified iso file according to Thomas Schmitt;
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_
in the HP Elitebook 8560p. With an external monitor and in recovery mode I could get it to the desktop. Actually it is enough for this debug task to get it to the grub menu, which fails with the original iso file because of the GUID partition table.
So I am sure that we have identified the problem. Thomas Schmitt's method is a second work-around, more direct and maybe more convenient than creating a persistent live drive with mkusb.
A solution would be to revert to the boot structure of 20.04.x LTS, which provides iso files that boot for all Ubuntu family iso files in all amd64 type computers, that we have tested.