Edit:
Call for testing the current daily Groovy iso files
The current daily Ubuntu Groovy iso file is modified, so that it gets a valid GUID partition table (GPT).
Code:
$ ls -l groovy-desktop-amd64.iso
-rw------- 1 sudodus sudodus 2936969216 okt 9 21:15 groovy-desktop-amd64.iso
$ md5sum groovy-desktop-amd64.iso
00cbcce8855c00dd2231077e3a01aebc groovy-desktop-amd64.iso
$ sudo gdisk groovy-desktop-amd64.iso
[sudo] password for sudodus:
GPT fdisk (gdisk) version 1.0.3
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): q
After this modification a USB drive with the system cloned from the iso file can boot also problematic Lenovo V series computers, for example my Lenovo V130 laptop, in UEFI mode with secure boot.
I checked that it works also in a Dell Precision M4800 both in BIOS mode and UEFI mode.
There have been many modifications of the boot structure of the Groovy iso files. There may be regressions for computers, that we (the testers involved in squashing the bug) have not tested. Please wait for the next daily Groovy iso file of your favourite flavour of Ubuntu, and test that it can boot correctly in the computers, where you want it to work.
The iso file must be released at or after Oct 9 21:15 for this modification to be there.
See the long story at Bug #1886148 - failure to boot groovy daily
Original post:
The boot structure of the Ubuntu family Groovy iso files for PC computers, the amd64 iso files, is modified in a radical way and it has caused problems to boot. The problem has been solved for most of the computers tested by us 'isotesters', but there are still problems.
Both older and newer computers are still failing to boot into the current daily Groovy iso files. Those computers boot into USB drives cloned from the daily iso files uploaded during June (before the radical modification of the boot structure). It seems the developers have no more ideas. See Bug report #1886148.
So in order to be ready for a situation, where some computers fail to boot from USB drives created via the standard method, cloning, I suggest that we help each other test if our computers work, and if not, if there is some workaround for the problematic computers.
- I know (from the bug report) that there are problems with some Core2Duo computers (but I have no such computer).
- I have a fairly new computer (the newest one, that I can access for testing right now, Lenovo V130 bought in Dec 2019), that cannot boot (in UEFI mode with secure boot). This computer works with Focal iso files and with Groovy iso files from June. This computer finds the USB drive in the temporary boot menu (via F12), but skips directly into the grub menu of the internal drive, when I try from a cloned USB drive.
I found that the Lenovo V130 works as expected, when mkusb-dus creates a persistent live drive with the setting 'upefi' - using usb-pack-efi. There is a menu entry for a live-only session for people who want that, so I would say that it is a workaround.
We can suspect that there is more than one mode of failure, different for older and newer computers. We (end users) can hardly guess what needs to be done, but we might be able to find workarounds, when cloned USB drives won't boot.
Examples of workarounds, that I can think of (to be worthwhile testing),
- persistent live by mkusb-dus with various settings (not only 'upefi')
- 'grub-n-iso' or 'isoboot' for example according to this link
- Unetbootin
- Rufus (in Windows)
- burned DVD disk (I guess there is a DVD drive in your old computers).
Finally, new workarounds are welcome 
