action #34291
closed[functional][y][yast] reproduce failure with autoyast_firewalld_SuSEfirewall_configuration and collect logs
0%
Description
Observation¶
Test fails due to some race condition, as firewalld command fails and in the end network device is not getting up.
As network is down, we cannot collect logs automatically, so need to reproduce it manually and collect all logs and file a bug.
openQA test in scenario sle-15-Installer-DVD-x86_64-autoyast_firewalld_SuSEfirewall_configuration@64bit fails in
wicked
Reproducible¶
Fails since (at least) Build 540.2
Expected result¶
Last good: 538.1 (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by riafarov about 6 years ago
@okurz, please schedule and potentially raise the priority. In latest builds it's seems to be easy to reproduce.
Updated by okurz about 6 years ago
- Due date set to 2018-04-24
- Category set to Bugs in existing tests
- Target version set to Milestone 15
Well checking results from the latest build shows it passed in 550.2, please crosscheck right in the next sprint then if it's now fixed by product changes or what happened or if it fails again in the next build. But I keep the prio as normal as it did not fail in the most recent build.
Updated by okurz about 6 years ago
oh, btw, asmorodskyi managed in https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/4717 to come up with a cool approach to "repair the network" in a post_fail_hook. Maybe this is something you want to try out as well in a more generic approach?
Updated by riafarov about 6 years ago
@okurz Yeah, I was thinking about same thing, but it can be the case that network won't start before we do some extra steps about firewalld service. As I've mentioned above, issue is sporadic and happens due to some race condition. Retriggering for the same build helps sometimes. That's why I've created a ticket, because could not reproduce it in 30 minutes and collect logs.
Updated by okurz about 6 years ago
- Due date changed from 2018-04-24 to 2018-05-22
- Target version changed from Milestone 15 to Milestone 16
not enough capacity in S15 nor S16, moving
Updated by JERiveraMoya about 6 years ago
I was able to reproduce with a vm everytime.
Updated by riafarov about 6 years ago
https://bugzilla.suse.com/show_bug.cgi?id=1089855 (logs not collected, but bug is there)
Updated by riafarov about 6 years ago
- Status changed from Workable to Resolved
Now logs are provided