action #128600
closed[security] [QR] [UEFI] test fails in audit_remote_libvirt
0%
Description
Observation¶
openQA test in scenario sle-15-SP4-Online-QR-x86_64-cc_audit-remote-libvirt_uefi@uefi fails in
audit_remote_libvirt
Test suite description¶
Testsuite maintained at https://gitlab.suse.de/qe-security/osd-sle15-security.
Reproducible¶
Fails since (at least) Build 186.1 (current job)
Expected result¶
Last good: 186.1 (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by emiler over 1 year ago
It has been happening sporadically: https://openqa.suse.de/tests/11023530#next_previous
Perhaps we should somehow ensure that the qcow2 image is done uploading before running this?
Updated by amanzini over 1 year ago
- Subject changed from [security] [QR] test fails in audit_remote_libvirt to [security] [QR] [UEFI] test fails in audit_remote_libvirt
- Status changed from New to In Progress
some observation: the same happens both on 15sp4 and 15sp5, but only on @uefi variants.
Probably there is some misconfiguration on the schedule that prevents considering the required security_build_nested_hdd a dependency.
Updated by amanzini over 1 year ago
- Status changed from In Progress to Feedback
Merge Request: https://gitlab.suse.de/qe-security/osd-sle15-security/-/merge_requests/104 , waiting next build result before considering resolved
Updated by amanzini over 1 year ago
- Assignee deleted (
amanzini)
unassigning due to squad rotation - Andrea visiting SAP/HANA Perf squad
Updated by tjyrinki_suse over 1 year ago
- Status changed from Feedback to Workable
In 15-SP5 this still seems to be sporadic: https://openqa.suse.de/tests/11951018#next_previous
Updated by JERiveraMoya over 1 year ago
I did some test comparing current setup and using hdd_2 instead of hdd_l2, so the disk is attached and can be discovered from the beginning that it doesn't exist:
https://openqa.suse.de/tests/overview?build=jknphy%2Fos-autoinst-distri-opensuse%23test&version=15-SP5&distri=sle
Times correlates, so the child really start after both parents jobs. Only 22 minutes passed after the image is supposed to be available.
See bottom of the logs:
https://openqa.suse.de/tests/11935653/logfile?filename=autoinst-log.txt
https://openqa.suse.de/tests/11935777/logfile?filename=autoinst-log.txt
and then the failure searching by "wget -c -P":
https://openqa.suse.de/tests/11935843/logfile?filename=autoinst-log.txt
I asked @qe-tools if this could be some race conditions:
https://suse.slack.com/archives/C02CANHLANP/p1694694822703159
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: cc_audit-remote-libvirt_uefi@uefi
https://openqa.suse.de/tests/11607758#step/audit_remote_libvirt/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 JERiveraMoya over 1 year ago
I did 20 runs for this and I couldn't reproduce the problem. wdyt?
The only clue that I have is about the bridge behaviour,
see this line here [ 845.895964][T17053] virbr0: port 1(vnet1) entered disabled state
The expected behavior of the bridge is to go to forwarding after transitions by all those states, so that might be affecting the test.
See the transition in a passed job: https://openqa.suse.de/tests/11575634#step/audit_remote_libvirt/38
Updated by tjyrinki_suse about 1 year ago
- Status changed from Workable to Closed
In 15-SP5 it has been really stable now:
https://openqa.suse.de/tests/12856678#next_previous
I think whatever it is, it is not worth spending more investigation time on it. If someone again bumps into it and gets linked to this ticket, feel free to increase RETRY for the test.
Updated by openqa_review 10 months ago
- Status changed from Closed to Feedback
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: cc_audit-remote-libvirt_uefi@uefi
https://openqa.suse.de/tests/11607758#step/audit_remote_libvirt/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 204 days if nothing changes in this ticket.
Updated by openqa_review 10 months ago
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: cc_audit-remote-libvirt_uefi@uefi
https://openqa.suse.de/tests/11607758#step/audit_remote_libvirt/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 tjyrinki_suse about 1 month ago
- Status changed from Feedback to Resolved