action #116812
open[qe-core] Leap 15.5 uefi console switch fail size:M
Added by lkocman over 2 years ago. Updated 10 months ago.
0%
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)
Updated by lkocman over 2 years ago
Updated by lkocman over 2 years ago
- Subject changed from Leap 15.5 uefi boot fail to Leap 15.5 uefi console switch fail
Updated by maritawerner over 2 years ago
- Project changed from openQA Tests (public) to qe-yam
- Category deleted (
Bugs in existing tests)
Updated by okurz over 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?
Updated by JERiveraMoya over 2 years ago
- Project changed from qe-yam to openQA Tests (public)
it is worker-related issue.
Updated by maritawerner over 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?
Updated by okurz over 2 years ago
- Related to action #116914: [qe-core] recent uefi changes makes test fail added
Updated by okurz over 2 years ago
- Related to action #111992: Deal with QEMU and OVMF default resolution being 1280x800, affecting (at least) qxl size:M added
Updated by okurz over 2 years ago
- Related to action #113794: Use prepared OVMF image with expected settings size:M added
Updated by okurz over 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.
Updated by tinita over 2 years ago
- Status changed from New to Feedback
- Assignee set to tinita
So it seems this is fixed.
https://openqa.opensuse.org/tests/2695368#next_previous is green since 3 days (
UEFI_PFLASH_VARS=ovmf-x86_64-ms-vars-800x600.qcow2)https://openqa.opensuse.org/tests/2699430#next_previous -> I took the last failing https://openqa.opensuse.org/tests/2761252 and cloned it with
UEFI_PFLASH_VARS=ovmf-x86_64-ms-vars-800x600.qcow2and it passed: https://openqa.opensuse.org/tests/2765137#settings
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.
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.
Updated by livdywan about 2 years ago
- Status changed from Feedback to Blocked
This is blocked by the above bugzilla ticket for now
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.
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.
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.
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:
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.
Updated by okurz almost 2 years 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.
Updated by okurz almost 2 years 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'
Updated by livdywan almost 2 years 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)
Updated by tjyrinki_suse over 1 year ago
- Blocks action #115919: [security] test fails in tpm2_measured_boot added
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:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released" or "EOL" (End-of-Life)
- 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.
Updated by okurz 11 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.
Updated by okurz 11 months ago
- Related to action #152092: Handle all package downgrades in OSD infrastructure properly in salt size:M added
Updated by okurz 11 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.
Updated by okurz 10 months ago
- Related to action #153784: Move of selected LSG QE machines NUE1 to PRG2e - openqaworker19 added
Updated by okurz 10 months ago
- Related to action #153787: Move of selected LSG QE machines NUE1 to PRG2e - openqaworker20 size:M added