Bug #10288: Fix newly identified issues to make our test suite more robust and faster
Scenario "Booting Tails from a USB drive in UEFI mode" is fragile
Happened 30 times in June, 58 for what 2017 logs we had on July 10th.
Test suite can not find the kernel boot command line, and loop over reseting the VM as expected, but eventually fails. Could it be that we need to wait a bit more longer for the UEFI firmware to boot?
Attaching typical mkv and debug.log.
#5 Updated by intrigeri about 2 years ago
- File debug-37.log View added
- File 00_48_06_Booting_Tails_from_a_USB_drive_in_UEFI_mode.mkv added
So we're doing "We missed the boot menu before we could deal with it, resetting..." a number of time before the boot menu could actually appear. Looks as if lizard was particularly loaded at that time. And on the last try the boot menu does eventually appear but we stop waiting (the 3 minutes
boot_timeout has expired) before the tab spammer could open the boot command line. In this specific case, presumably a slightly larger
boot_timeout would have been enough, but I don't think that's the root cause of the problem:
screen.wait('UEFIFirmwareSetup.png', 30) wrongly matches something on the screen: I don't see the firmware setup on the video, but there are a few
[log] TYPE "#ENTER." followed by a reset in the logs. Perhaps some OVMF upgrade changed its behaviour and now our special handling code is somewhat obsolete and behaving weirdly? It seems that this code is making things less robust in some cases, by repeatedly resetting a system that otherwise would perhaps boot just fine.
It's tempting to drop the UEFI firmware setup handling code, or to update that picture, and see what happens.
I've seen 2 runs of the — erroneously named BTW — topic branch (Aug 30, Aug 31) that exposed exactly the same behavior.