Bug #13459
Scenario "Booting Tails from a USB drive in UEFI mode" is fragile
0%
Description
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.
Files
Subtasks
Related issues
Related to Tails - |
Resolved | 2017-06-05 | 2017-07-05 |
Related to Tails - |
Resolved | ||
Related to Tails - Bug #17646: Establish a coding standards baseline on our Ruby code base | Needs Validation |
History
#1 Updated by bertagaz 2017-07-12 11:50:26
- Feature Branch set to bugfix/13459-UEFI-scenario-is-fragile
#2 Updated by bertagaz 2017-07-12 12:37:01
- related to
Feature #12289: Deal with June 2017 false positive scenarios added
#3 Updated by bertagaz 2017-07-12 13:42:44
- Status changed from Confirmed to In Progress
Applied in changeset commit:90b73d389137425e965b0bb8d9a3235b3ceab4a2.
#4 Updated by intrigeri 2017-07-13 18:33:23
- Assignee deleted (
anonym) - Target version deleted (
Tails_3.2)
(Please clarify if there’s any reason why this should be handled that urgently compared to sibling tickets.)
#5 Updated by intrigeri 2017-09-09 16:45:56
- File debug-37.log 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.
#6 Updated by intrigeri 2017-09-11 11:43:51
- Feature Branch changed from bugfix/13459-UEFI-scenario-is-fragile to test/13459-UEFI-scenario-is-fragile
(Fixed branch name, deleted the old one.)
#7 Updated by intrigeri 2019-03-08 15:28:05
- Status changed from In Progress to Confirmed
#8 Updated by intrigeri 2019-06-18 18:42:56
- related to
Bug #16820: UEFI test is broken for Tails based on buster added
#9 Updated by intrigeri 2020-05-12 08:22:16
- Status changed from Confirmed to In Progress
Applied in changeset commit:tails|501d4f9f6068d61b929a9b20d05b042e230f3a6d.
#10 Updated by intrigeri 2020-05-14 13:44:55
- related to Bug #17646: Establish a coding standards baseline on our Ruby code base added
#11 Updated by intrigeri 2020-05-14 13:46:16
- Status changed from In Progress to Needs Validation
- Assignee set to anonym
- Target version set to Tails_4.7
- Feature Branch changed from test/13459-UEFI-scenario-is-fragile to feature/17646-ruby-coding-standards-baseline+force-all-tests
This should be reviewed as a subset of Bug #17646: see commit:501d4f9f6068d61b929a9b20d05b042e230f3a6d on that branch.