Project

General

Profile

action #31480

[functional][fast]KDE Live / install: fails to initiate reboot

Added by dimstar almost 5 years ago. Updated almost 5 years ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
Bugs in existing tests
Start date:
2018-02-07
Due date:
2018-02-13
% Done:

0%

Estimated time:
Difficulty:

Description

Observation

openQA test in scenario opensuse-Tumbleweed-KDE-Live-x86_64-kde-live_installation@64bit fails in
grub_test

Reproducible

Fails since (at least) Build 20180206

Expected result

Last good: 20180205 (or more recent)

Further details

Always latest result in this scenario: latest

In the past, after the 'softfail' warning, the 'install-shell' console was selected (this is still so in the code) and found (the screen looks exactly as it does in this failed case)
Just now, apparently, it is looking for text-login instead of install-shell-console needles. Going through the git log, I did not (yet) find what might have changed this behaviour


Related issues

Related to openQA Tests - action #31720: [functional][opensuse][fast][easy] Live images fail to shut downResolved2018-02-132018-02-27

History

#1 Updated by okurz almost 5 years ago

  • Subject changed from KDE Live / install: fails to initiate reboot to [functional][fast]KDE Live / install: fails to initiate reboot
  • Due date set to 2018-02-13
  • Priority changed from Normal to High
  • Target version set to Milestone 14

#2 Updated by okurz almost 5 years ago

  • Status changed from New to In Progress
  • Assignee set to okurz

Reproduced the issue locally: http://lord.arch/tests/482 . What happens is that when "install-shell" is selected it tries to activate the console which is already active. Last good: https://openqa.opensuse.org/tests/602847#step/install_and_reboot/4 shows this working when install-shell is activated the first time. The second time the console is selected it is not activated. In the case of the failure it tries to activate the console again. My assumption is that something resets the consoles.

  • H1: REJECTED (E1-2) Recent changes in os-autoinst
  • H2: ACCEPTED (E2-2) Recent changes in os-autoinst-distri-opensuse
  • H3: REJECTED (E1-1) Recent changes in the product
  • H4: It has to be something else

  • E1-1: Checked out older os-autoinst 2a5fad6 from Thu Dec 14 20:41:04 2017 +0100, Running test again with same product version -> test passed -> SUPPORT H1+H2, REJECT H3

  • E1-2: Back to ba6dd1e, reconducting -> test passed -> SUPPORT H2, REJECT H1

  • E2-1: os-autoinst up-to-date, reconducting with updated tests 35f2553d -> test failed -> SUPPORT H2

  • E2-2: os-autoinst up-to-date, reconducting with older tests 37508cc4 -> test passed -> ACCEPT H2

running git bisect on tests in range 37508cc4..35f2553d

Bisecting: 0 revisions left to test after this (roughly 0 steps)
[3f0c424bbb46c126de80829654fb4603f80d40dc] Fix unlocking of encrypted boot partition in storage-ng setups

so it was my own change. But what exactly in it then?

I mean, I changed grub_test but it should still do the same thing: on livecd, select_console('install-shell') and take the already logged in one.

Reverted commit a649d1e6dcce938f4bfbe8ce8dd43f8a290099e7. Maybe it's something about resetting consoles on reboot when we think a console is reset already but it's not.

#3 Updated by okurz almost 5 years ago

  • Status changed from In Progress to Feedback

So reverting worked: http://lord.arch/tests/498 . I unreverted and will try something else:

console('install-shell')->{activated} = 1;

before the select_console call.

Ok, that did not seem to work. Setting this internal member does not seem to work this way but in the end I came up with the correct solution:

https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/4400

#4 Updated by okurz almost 5 years ago

  • Status changed from Feedback to Resolved

#5 Updated by lnussel almost 5 years ago

  • Related to action #31720: [functional][opensuse][fast][easy] Live images fail to shut down added

Also available in: Atom PDF