Bug #16820

UEFI test is broken for Tails based on buster

Added by anonym 2019-06-18 14:24:26 . Updated 2019-06-19 09:33:29 .

Status:
Resolved
Priority:
Normal
Assignee:
intrigeri
Category:
Test suite
Target version:
Start date:
Due date:
% Done:

100%

Feature Branch:
test/16820-uefi+force-all-tests
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

This is about Scenario: Booting Tails from a USB drive in UEFI mode.

Both in my test VM and on Jenkins the UEFI scenario fails. We reach the part where the kernel command-line is shown, but we never manage to find TailsBootMenuKernelCmdlineUEFI.png even though the matching area is in plain sight. I’ve tried updating the image without success. I’ve tried lowering the sensitivity (0.5, which is very generous):

--- a/features/step_definitions/common_steps.rb
+++ b/features/step_definitions/common_steps.rb
@@ -239,7 +239,9 @@ Given /^Tails is at the boot menu's cmdline( after rebooting)?$/ do |reboot|
         Process.kill("CONT", tab_spammer.pid)
         dealt_with_uefi_setup = true
       end
-      @screen.wait(boot_menu_cmdline_image, 15)
+      p = Sikuli::Pattern.new(boot_menu_cmdline_image)
+      p.similar(0.5)
+      @screen.wait(p, 15)
     rescue FindFailed => e
       debug_log('We missed the boot menu before we could deal with it, ' +
                 'resetting...')


also without success. I’ve even pause()d and tried to match it, but it just doesn’t work. Perhaps we’re hitting some corner-case of Sikuli’s image detection?

Also, if I remove the tab spammer, then the Tiano Core splash screen is shown for a shorter duration, indicating that the spammer makes makes the splash show for significantly longer: I’ve seen > 10x, so the boot splash never managed to appear, which is worrying. Also, pressing TAB doesn’t seem to open the UEFI configuration, so we might be able to drop that workaround.


Subtasks


Related issues

Related to Tails - Bug #13459: Scenario "Booting Tails from a USB drive in UEFI mode" is fragile Needs Validation 2017-07-12

History

#1 Updated by intrigeri 2019-06-18 18:39:57

  • Description updated

#2 Updated by intrigeri 2019-06-18 18:42:56

  • related to Bug #13459: Scenario "Booting Tails from a USB drive in UEFI mode" is fragile added

#3 Updated by intrigeri 2019-06-18 18:57:44

  • Status changed from Confirmed to In Progress
  • Assignee set to intrigeri
  • Bug #13459#note-5 might be relevant.
  • I’ve tried making the tab spammer more relaxed, by increasing the sleep duration from 0.1 to 1. It makes the tianocore splash screen display only very briefly on my system, and then the kernel cmdline is there super quickly. Given our syslinux timeout is 5s, I see no reason to press tab 10 times per second. Regardless of this ticket, IMO we should raise this value to at least 0.5 and quite possibly 1s.
  • I’ve tried removing all the dealt_with_uefi_setup special casing but see the same behavior as anonym reported about: the kernel cmdline is there but sikuli can’t find it.
  • I’ve tried making TailsBootMenuKernelCmdlineUEFI.png bigger (more specific than a mere “boot=live”) and it fixed the problem. Will push a branch and we’ll see what Jenkins thinks.

#4 Updated by intrigeri 2019-06-18 19:01:40

  • Feature Branch set to test/16820-uefi+force-all-tests

#5 Updated by intrigeri 2019-06-18 19:04:10

#6 Updated by intrigeri 2019-06-18 19:08:49

Let’s see what Jenkins thinks

#7 Updated by intrigeri 2019-06-19 05:48:55

  • Status changed from In Progress to Needs Validation
  • Assignee deleted (intrigeri)

The affected scenario has passed on https://jenkins.tails.boum.org/view/Tails_ISO/job/test_Tails_ISO_test-16820-uefi-force-all-tests/1/consoleFull :)

#8 Updated by hefee 2019-06-19 08:16:22

  • Assignee set to hefee

#9 Updated by hefee 2019-06-19 08:32:14

  • Status changed from Needs Validation to In Progress
  • Assignee changed from hefee to intrigeri

Nice to learn more about the insights of the test suite. Checked Jenkins status and looked at images changes. And as it is code removal that looks logic for me. What I don’t get why we can remove the TAB spammer workaround for UEFI. Is it because we only send tab after 1sec, and after 1sec the boot splash is already passed to grub, so we don’t need the workaround anymore?

#10 Updated by intrigeri 2019-06-19 08:55:24

> What I don’t get why we can remove the TAB spammer workaround for UEFI.

Ouch, sorry I should of course have explained in the commit message.

The reason that as reported by anonym on this ticket, and confirmed by my testing, “pressing TAB doesn’t seem to open the UEFI configuration”, so the very reason why we had this workaround is gone.

#11 Updated by intrigeri 2019-06-19 08:55:37

  • Status changed from In Progress to Needs Validation
  • Assignee changed from intrigeri to hefee

#12 Updated by hefee 2019-06-19 09:28:56

  • Status changed from Needs Validation to In Progress
  • Assignee changed from hefee to intrigeri

intrigeri wrote:
> > What I don’t get why we can remove the TAB spammer workaround for UEFI.
>
> Ouch, sorry I should of course have explained in the commit message.

Yepp that would be great.

> The reason that as reported by anonym on this ticket, and confirmed by my testing, “pressing TAB doesn’t seem to open the UEFI configuration”, so the very reason why we had this workaround is gone.

Thx for clearifing. I don’t see any showstoppers anymore from merging.

#13 Updated by intrigeri 2019-06-19 09:33:27

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Applied in changeset commit:tails|288e1631ae3f5c4e9b200e20e0fddc9a9a1f4826.

#14 Updated by intrigeri 2019-06-19 09:33:29

>> Ouch, sorry I should of course have explained in the commit message.

> Yepp that would be great.

Done!