action #162239
open[s390x] test fails in bootloader_start due to slow response from z/VM hypervisor and/or changed response on "cp i cms" command
0%
Description
Observation¶
openQA test in scenario sle-15-SP5-Server-DVD-Incidents-Minimal-s390x-qam-minimal@s390x-zVM fails in
bootloader_start
Reproducible¶
Fails since (at least) Build :33664:libyui
Expected result¶
Last good: :34226:openssl-3 (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by okurz 7 months ago
No change, similar observations on multiple z/VM instances. the serial output shows either no response to cp i cms
like in https://openqa.suse.de/tests/14602793#step/bootloader_start/19 or just the welcome header as in https://openqa.suse.de/tests/14602791#step/bootloader_start/19 . What next to try?
Updated by okurz 7 months ago
- Related to action #157975: Upgrade osd workers to openSUSE Leap 15.6 size:S added
Updated by okurz 7 months ago
(Oliver Kurz) and why does the display and font in bad https://openqa.suse.de/tests/14602738#step/bootloader_start/2 look so different compared to last good https://openqa.suse.de/tests/14565491#step/bootloader_start/2 ?
@Deepthi Yadabettu Venkatachala
you created https://gitlab.suse.de/openqa/os-autoinst-needles-sles/-/commit/21cab646e91e1a3ace45a347bc1b8a9e0243ca68 just today. Why does x3270 look different? And should that be acceptable? On 2024-06-12 x3270 was upgraded on openQA workers. That might be the problem. I will see if I can revert that update. That's why I would like to know from @Deepthi Yadabettu Venkatachala why she created updated needles
From /var/log/zypp/history
2023-07-31 16:14:08|install|x3270|3.6-6.1|x86_64|root@worker33|openSUSE-Leap-15.5-1|66ccab656f9630029fbca059b7f5c05aa4717834f64509f899ab08cd543925f0|
2024-06-12 13:56:49|install|x3270|4.3-150600.1.5|x86_64||openSUSE-Leap-15.5-1|04d5cfb89543de53578bc55c6799033a2377d01540a2a517aeee26c770e4de36258c1065d917ffccfaaa4cc09296a6d0438cf021f58c11d30aaf68dcd7ce1bdd|
Apparently workers upgraded themselves to Leap 15.6, see #157975-4
From
http://download.opensuse.org/distribution/leap/15.5/repo/oss/x86_64/?P=*x3270*
I found the available version in 15.5. I assume there was no other version in updates or anything as the last version installed was 3.6-6.1 so matching the above oss 15.5 GA repo
zypper in --oldpackage http://download.opensuse.org/distribution/leap/15.5/repo/oss/x86_64/x3270-3.6-6.1.x86_64.rpm
and
openqa-clone-custom-git-refspec https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/19513 https://openqa.suse.de/tests/14600543 WORKER_CLASS+=,worker33 TEST+=-300s-worker33-downgraded-x3270
- sle-12-SP5-Server-DVD-Incidents-Minimal-s390x-Build:34269:kernel-ec2-qam-minimal@s390x-zVM -> https://openqa.suse.de/tests/14605733
this test progressed. So I will revert all x3270 packages where installed and add a package lock in the pillar repo
sudo salt \* cmd.run 'rpm -q x3270-4.3 && zypper -n in --oldpackage http://download.opensuse.org/distribution/leap/15.5/repo/oss/x86_64/x3270-3.6-6.1.x86_64.rpm'
and https://gitlab.suse.de/openqa/salt-pillars-openqa/-/merge_requests/840 for the package lock
Updated by openqa_review 7 months ago
- Due date set to 2024-06-28
Setting due date based on mean cycle time of SUSE QE Tools
Updated by okurz 7 months ago
- Related to action #162101: [s390x] timeouts on s390x openQA Workers size:M added
Updated by okurz 7 months ago
- Related to action #157972: Upgrade o3 workers to openSUSE Leap 15.6 size:S added
Updated by okurz 7 months ago
- Subject changed from [s390x] test fails in bootloader_start due to slow response from z/VM hypervisor to [s390x] test fails in bootloader_start due to slow response from z/VM hypervisor and/or changed response on "cp i cms" command
- Status changed from In Progress to Blocked
Awaiting further feedback or ideas from domain experts. Also in the meantime we could continue with e.g. #157972 first and then later come back to this.
Updated by livdywan 6 months ago
okurz wrote in #note-9:
Awaiting further feedback or ideas from domain experts. Also in the meantime we could continue with e.g. #157972 first and then later come back to this.
Note that this ticket is due the day after tomorrow but also blocking on a ticket that's not on the backlog. We'll need to resolve the parafox.