Project

General

Profile

Actions

action #116812

open

[qe-core] Leap 15.5 uefi console switch fail size:M

Added by lkocman about 2 years ago. Updated 9 months ago.

Status:
Blocked
Priority:
Low
Assignee:
Category:
Bugs in existing tests
Target version:
QA (public, currently private due to #173521) - future
Start date:
2022-09-19
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

Observation

Hello

I had a conversation with Max about our uefi boot fails on Leap 15.5 and Max believes this is an openQA specific issue related to switching to console.

There seem to be one more related fail with gui login (not console login). But it's also on uefi only

openQA test in scenario opensuse-15.5-DVD-x86_64-autoyast_gnome@uefi fails in
installation (removed by now)

Test suite description

Maintainer: QE Yast

Testing autoyast installation with given profile and expect SLES with gnome. Please, see the profile for more details. Profile is available in distri git repo under data subdirectory. Same as autoyast_gnome but with product defined in the profile.

Reproducible

Fails since (at least) Build 283.1 but currently not reproducing in production due to workaround

Expected result

Last good: 282.3 (or more recent)

Suggestions

  • Try to reproduce manually
  • Create bug report towards the package that virtual console switches does not have an effect anymore since the package upgrade mentioned in #116812#note-9 , also see other bug reports for reference, https://bugzilla.opensuse.org/show_bug.cgi?id=1204067
  • Await suggestions or fixes for the bug
  • Try suggestions or fixes to verify

Rollback steps

  • o3: for i in aarch64 openqaworker4 openqaworker7 openqaworker19 openqaworker20 qa-power8-3 rebel; do echo $i && ssh root@$i "zypper rl qemu-ovmf-x86_64 && zypper -n in qemu-ovmf-x86_64" ; done
  • osd: sudo salt --no-color --state-output=changes -C 'G@roles:worker' cmd.run 'zypper rl qemu-ovmf-x86_64 && zypper -n in qemu-ovmf-x86_64 && rpm -q qemu-ovmf-x86_64'

Further details

Always latest result in this scenario: latest (15.6) (15.5: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=DVD&machine=uefi&test=autoyast_gnome&version=15.5)


Related issues 5 (2 open3 closed)

Related to openQA Tests (public) - action #116914: [qe-core] recent uefi changes makes test failWorkable2022-09-21

Actions
Related to openQA Project (public) - action #111992: Deal with QEMU and OVMF default resolution being 1280x800, affecting (at least) qxl size:MResolvedtinita2022-06-03

Actions
Related to openQA Project (public) - action #113794: Use prepared OVMF image with expected settings size:MResolvedtinita2022-06-03

Actions
Related to openQA Infrastructure (public) - action #152092: Handle all package downgrades in OSD infrastructure properly in salt size:MResolvednicksinger2023-12-05

Actions
Blocks openQA Tests (public) - action #115919: [security] test fails in tpm2_measured_bootBlocked2022-08-29

Actions
Actions #2

Updated by lkocman about 2 years ago

  • Subject changed from Leap 15.5 uefi boot fail to Leap 15.5 uefi console switch fail
Actions #3

Updated by lkocman about 2 years ago

  • Description updated (diff)
Actions #4

Updated by lkocman about 2 years ago

  • Description updated (diff)
Actions #5

Updated by lkocman about 2 years ago

  • Description updated (diff)
Actions #6

Updated by lkocman about 2 years ago

  • Description updated (diff)
Actions #7

Updated by lkocman about 2 years ago

  • Description updated (diff)
Actions #8

Updated by maritawerner about 2 years ago

  • Project changed from openQA Tests (public) to qe-yam
  • Category deleted (Bugs in existing tests)
Actions #9

Updated by okurz about 2 years ago

This might be related to #111992 or #113794 but here it's not about the bootloader resolution. Would need further investigation.

EDIT: Between the "last good" 4.6.1663185141.2738a2c and the "first bad" 4.6.1663185141.2738a2c the os-autoinst version seems to be the same. I think the qemu ovmf image was updated from the older, locked version some more days in the past. Maybe another, different package update that caused this?

Actions #10

Updated by JERiveraMoya about 2 years ago

  • Project changed from qe-yam to openQA Tests (public)

it is worker-related issue.

Actions #11

Updated by maritawerner about 2 years ago

  • Subject changed from Leap 15.5 uefi console switch fail to [qe-core] Leap 15.5 uefi console switch fail

Did I not say 15 minutes ago do not reassign it to me?

Actions #12

Updated by okurz about 2 years ago

  • Related to action #116914: [qe-core] recent uefi changes makes test fail added
Actions #13

Updated by okurz about 2 years ago

  • Related to action #111992: Deal with QEMU and OVMF default resolution being 1280x800, affecting (at least) qxl size:M added
Actions #14

Updated by okurz about 2 years ago

  • Related to action #113794: Use prepared OVMF image with expected settings size:M added
Actions #15

Updated by okurz about 2 years ago

  • Category set to Bugs in existing tests

maritawerner wrote:

Did I not say 15 minutes ago do not reassign it to me?

yes, you did. Very clearly :)

@JERiveraMoya please try to find useful assignees, not just put tickets back to a generic project with no team-assignments. We should collaborate to assign tickets to the right teams.

This seems to be also related to #116914.

What could be tried is to downgrade the qemu-ovmf-x86_64 package on o3 workers again to crosscheck if that fixes the tests.

Actions #16

Updated by tinita about 2 years ago

  • Status changed from New to Feedback
  • Assignee set to tinita

So it seems this is fixed.

Actions #17

Updated by tinita about 2 years ago

  • Target version set to Ready
Actions #18

Updated by tinita about 2 years ago

I set UEFI_PFLASH_VARS=ovmf-x86_64-ms-vars-800x600.qcow2 for the MACHINE uefi-2G as well (uefi was already set).

It should work now for the next schedule.
Let me know if the problem appears again.

Actions #19

Updated by tinita about 2 years ago

I downgraded qemu-ovmf-x86_64 on all workers again.

We are waiting for feedback on https://bugzilla.opensuse.org/show_bug.cgi?id=1204067

For uefi #116914 I changed back UEFI_PFLASH_VARS to /usr/share/qemu/ovmf-x86_64-ms-vars.bin because there it resulted in a different failure.

Actions #20

Updated by livdywan about 2 years ago

  • Status changed from Feedback to Blocked

This is blocked by the above bugzilla ticket for now

Actions #21

Updated by slo-gin about 2 years ago

This ticket was set to High priority but was not updated within the SLO period. Please consider picking up this ticket or just set the ticket to the next lower priority.

Actions #22

Updated by slo-gin almost 2 years ago

This ticket was set to High priority but was not updated within the SLO period. Please consider picking up this ticket or just set the ticket to the next lower priority.

Actions #23

Updated by slo-gin almost 2 years ago

This ticket was set to High priority but was not updated within the SLO period. Please consider picking up this ticket or just set the ticket to the next lower priority.

Actions #24

Updated by livdywan almost 2 years ago

tinita wrote:

We are waiting for feedback on https://bugzilla.opensuse.org/show_bug.cgi?id=1204067

There's a new comment apparently:

The symptom looks the same as bsc#1203825.

Please try to upgrade qemu-ovmf-x86_64 that at least contains the following change:
Actions #25

Updated by slo-gin almost 2 years ago

This ticket was set to High priority but was not updated within the SLO period. Please consider picking up this ticket or just set the ticket to the next lower priority.

Actions #26

Updated by livdywan over 1 year ago

See #111992

Actions #27

Updated by okurz over 1 year ago

  • Status changed from Blocked to In Progress
  • Assignee changed from tinita to okurz

With #111992#note-67 I have upgraded all o3 workers and retriggered a job from the original scenario. Let's monitor https://openqa.opensuse.org/tests/3193787 and then resolve if there are no problems observed.

Actions #28

Updated by okurz over 1 year ago

  • Description updated (diff)
  • Status changed from In Progress to New
  • Assignee deleted (okurz)

https://openqa.opensuse.org/tests/3193787#step/console/2 shows that the job fails same as it did originally so I went back to the old package with

o3:

for i in aarch64 openqaworker4 openqaworker7 openqaworker19 openqaworker20 qa-power8-3 rebel; do echo $i && ssh root@$i "zypper rl qemu-ovmf-x86_64 && zypper -n in --oldpackage http://download.opensuse.org/update/leap/15.3/sle/noarch/qemu-ovmf-x86_64-202008-150300.10.14.1.noarch.rpm; zypper al -m 'poo#116812' qemu-ovmf-x86_64; zypper ll" ; done

osd:

sudo salt --no-color --state-output=changes -C 'G@roles:worker' cmd.run 'zypper rl qemu-ovmf-x86_64 && zypper -n in --oldpackage http://download.opensuse.org/update/leap/15.3/sle/noarch/qemu-ovmf-x86_64-202008-150300.10.14.1.noarch.rpm; zypper al -m 'poo#116812' qemu-ovmf-x86_64; zypper ll'
Actions #29

Updated by livdywan over 1 year ago

  • Subject changed from [qe-core] Leap 15.5 uefi console switch fail to [qe-core] Leap 15.5 uefi console switch fail size:M
  • Description updated (diff)
Actions #30

Updated by okurz over 1 year ago

  • Status changed from New to Workable
Actions #31

Updated by okurz over 1 year ago

  • Description updated (diff)
Actions #32

Updated by okurz over 1 year ago

  • Description updated (diff)
Actions #33

Updated by tjyrinki_suse over 1 year ago

  • Blocks action #115919: [security] test fails in tpm2_measured_boot added
Actions #34

Updated by okurz over 1 year ago

  • Priority changed from High to Normal
Actions #35

Updated by openqa_review over 1 year ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: autoyast_gnome@uefi
https://openqa.opensuse.org/tests/3279871#step/console/1

To prevent further reminder comments one of the following options should be followed:

  1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
  2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
  3. The bugref in the openQA scenario is removed or replaced, e.g. label:wontfix:boo1234

Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.

Actions #36

Updated by okurz over 1 year ago

  • Target version changed from Ready to future
Actions #37

Updated by okurz 10 months ago

  • Status changed from Workable to In Progress
  • Assignee set to okurz
  • Target version changed from future to Ready

Found the ticket as nicksinger and me discussed about #152092

https://bugzilla.opensuse.org/show_bug.cgi?id=1204067 was actually VERIFIED FIXED long ago.

Actions #38

Updated by okurz 10 months ago

  • Related to action #152092: Handle all package downgrades in OSD infrastructure properly in salt size:M added
Actions #39

Updated by okurz 10 months ago

  • Description updated (diff)
  • Due date set to 2024-02-28
  • Status changed from In Progress to Feedback
  • Priority changed from Normal to Low

As we did not have qemu-ovmf-x86_64 for long now on multiple hosts I did

sudo salt \* cmd.run 'zypper rl qemu-ovmf-x86_64 && zypper -n in qemu-ovmf-x86_64'

with output

s390zl12.oqa.prg2.suse.org:
    No lock has been removed.
s390zl13.oqa.prg2.suse.org:
    No lock has been removed.
openqaworker17.qa.suse.cz:
    1 lock has been successfully removed.
backup-qam.qe.nue2.suse.org:
    No lock has been removed.
openqaworker18.qa.suse.cz:
    1 lock has been successfully removed.
worker37.oqa.prg2.suse.org:
    No lock has been removed.
worker40.oqa.prg2.suse.org:
    No lock has been removed.
worker39.oqa.prg2.suse.org:
    No lock has been removed.
worker31.oqa.prg2.suse.org:
    No lock has been removed.
worker35.oqa.prg2.suse.org:
    No lock has been removed.
worker38.oqa.prg2.suse.org:
    No lock has been removed.
worker36.oqa.prg2.suse.org:
    No lock has been removed.
worker33.oqa.prg2.suse.org:
    No lock has been removed.
openqaworker16.qa.suse.cz:
    1 lock has been successfully removed.
worker32.oqa.prg2.suse.org:
    No lock has been removed.
worker34.oqa.prg2.suse.org:
    No lock has been removed.
osiris-1.qe.nue2.suse.org:
    No lock has been removed.
sapworker3.qe.nue2.suse.org:
    No lock has been removed.
worker29.oqa.prg2.suse.org:
    No lock has been removed.
qesapworker-prg5.qa.suse.cz:
    No lock has been removed.
worker-arm2.oqa.prg2.suse.org:
    No lock has been removed.
qesapworker-prg6.qa.suse.cz:
    No lock has been removed.
worker30.oqa.prg2.suse.org:
    No lock has been removed.
qesapworker-prg4.qa.suse.cz:
    No lock has been removed.
qesapworker-prg7.qa.suse.cz:
    No lock has been removed.
sapworker2.qe.nue2.suse.org:
    No lock has been removed.
worker-arm1.oqa.prg2.suse.org:
    No lock has been removed.
sapworker1.qe.nue2.suse.org:
    No lock has been removed.
openqaworker14.qa.suse.cz:
    1 lock has been successfully removed.
openqaworker1.qe.nue2.suse.org:
    1 lock has been successfully removed.
petrol.qe.nue2.suse.org:
    1 lock has been successfully removed.
openqa.suse.de:
    No lock has been removed.
qamaster.qe.nue2.suse.org:
    No lock has been removed.
monitor.qe.nue2.suse.org:
    No lock has been removed.
imagetester.qe.nue2.suse.org:
    No lock has been removed.
jenkins.qe.nue2.suse.org:
    No lock has been removed.
unreal6.qe.nue2.suse.org:
    No lock has been removed.
baremetal-support.qe.nue2.suse.org:
    No lock has been removed.
backup-vm.qe.nue2.suse.org:
    No lock has been removed.
schort-server.qe.nue2.suse.org:
    No lock has been removed.
tumblesle.qe.nue2.suse.org:
    No lock has been removed.
diesel.qe.nue2.suse.org:
    1 lock has been successfully removed.
openqa-piworker.qe.nue2.suse.org:
    No lock has been removed.
mania.qe.nue2.suse.org:
    No lock has been removed.

and according installation logs. Let's monitor if something breaks and then continue with o3.

Actions #42

Updated by okurz 10 months ago

  • Due date deleted (2024-02-28)
  • Status changed from Feedback to Blocked

No currently online o3 machine has a lock on qemu-ovmf-x86_64. We should check openqaworker19+openqaworker20 as soon as they are online again. Blocking on #153784 and #153787

Actions #43

Updated by okurz 9 months ago

  • Target version changed from Ready to future
Actions

Also available in: Atom PDF