action #122176
open
[ppc64le][y] test fails in bootloader - waiting for lpar x to shutdown
Added by punkioudi about 2 years ago.
Updated 9 months ago.
Category:
Bugs in existing tests
Description
All ppc64le tests fail in the latest 15-SP5 runs with the message waiting for lpar 12 to shutdown
Observation¶
openQA test in scenario sle-15-SP5-Online-ppc64le-create_hdd_hmc_fips_envmode_Firefox@ppc64le-hmc-single-disk fails in
bootloader
Test suite description¶
Testsuite maintained at https://gitlab.suse.de/qe-security/osd-sle15-security.
Reproducible¶
Fails since (at least) Build 61.1
Expected result¶
Last good: 58.1 (or more recent)
Further details¶
Always latest result in this scenario: latest
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: autoyast_create_hdd_gnome
https://openqa.suse.de/tests/10346206#step/bootloader_start/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.
- Subject changed from [ppc64le] test fails in bootloader - waiting for lpar x to shutdown to [ppc64le][y] test fails in bootloader - waiting for lpar x to shutdown
- Priority changed from Normal to High
@punkioudi You created the ticket with the keyword [ppc64le] but not assigned to any team. This will make it likely that no one would pick up the ticket so I added [y] for the yam-team to look into.
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: create_hdd_hmc_fips_envmode_Firefox
https://openqa.suse.de/tests/10435065#step/bootloader/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.
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: create_hdd_hmc_fips_envmode_Firefox
https://openqa.suse.de/tests/10576654#step/bootloader/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.
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: create_hdd_hmc_fips_envmode_Firefox
https://openqa.suse.de/tests/10718719#step/bootloader/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 56 days if nothing changes in this ticket.
Is that ticket still valid? I think adding [y] has no effect because the yast and migration team uses its own sub project (https://progress.opensuse.org/projects/qe-yast/issues) . And the ticket is assigned to @szarate, the PO of the qe core team?
If this ticket is for the qe yam team, I can move it to their project if it is for the qe-core team I can add the relevant label, please advise.
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.
- Priority changed from High to Normal
The ticket will be set to the next lower priority Normal
Also available in: Atom
PDF