Bug #13459

Scenario "Booting Tails from a USB drive in UEFI mode" is fragile

Added by bertagaz 2017-07-12 11:44:15 . Updated 2020-05-14 13:46:16 .

Needs Validation
Test suite
Target version:
Start date:
Due date:
% Done:


Feature Branch:
Type of work:

Affected tool:
Deliverable for:


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.



Related issues

Related to Tails - Feature #12289: Deal with June 2017 false positive scenarios Resolved 2017-06-05 2017-07-05
Related to Tails - Bug #16820: UEFI test is broken for Tails based on buster Resolved
Related to Tails - Bug #17646: Establish a coding standards baseline on our Ruby code base Needs Validation


#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

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.