QA » openQA Project » openQA Tests

Thanks for the report. However, if we never had a test executing "shutdown" on icewm the ticket is rather a request for new test coverage, not a regression, right?

I checked "minimalx" on openSUSE Tumbleweed, https://openqa.opensuse.org/tests/829126, and also there I can not see "shutdown" being scheduled.

In theory we have the code, but it is never used and it does not work (on SLE15), so I would rather vote for 'enhancement'
My primary intention is to investigate and fix the shutdown module, scheduling it a side bonus to avoid running in something like this again

Actually is relevant.
There are at least two password dialogs, I will implement a workaround with a softfail

We have at least 3x root password prompts so far, one for a wall message, one for shutdown while other users are logged in and one for setting the powertarget.
I suppose that we simply shut it down over the console until the bug is fixed

First part which is fixing the code
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/6551

Still needs to be scheduled in main.pm

This PR schedules the shutdown tests on minimalx:
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/6570

Now waiting for merges and verification in production to close this ticket.
Setting to feedback meanwhile

PR merged, waiting for verification in production

Followup PR:
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/6844

Looks like the test failed to select the console properly:
https://openqa.suse.de/tests/2479298#step/shutdown/26

I see shutdown on minimalx previously working on
https://openqa.opensuse.org/tests/858731#step/shutdown/7
and now failing in
https://openqa.opensuse.org/tests/861496#step/shutdown/10
As currently there seem to be too many failures related to shutdown on minimalx I removed it again from the schedule as we had discussed already on friday but then did not revert:
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/6881
already merged, will retrigger the failed staging tests.

I retriggered about 100 jobs, mainly "cryptlvm" and "minimalx", not only Leap 15.1 staging but also Factory staging, aarch64 build validation jobs as well as maintenance tests. The outreach was wider than I thought.

@jorauch based on this we can now more carefully test the different scenarios when you want to bring back the test module. Let's talk next week how to continue as well.

Could you please clarify at what point we are?

• Is the shutdown module now scheduled?
• What needs to be done here at all?

jorauch wrote:

Could you please clarify at what point we are?

• Is the shutdown module now scheduled?

yes, in case of INSTALLONLY

• What needs to be done here at all?

Add it back to the cases of !INSTALLONLY and make sure it works in a stable manner in the scenarios where it was reported as failing. Also, work around bugs with proper record_soft_failure.

We have three interesting variables here:

• cryptlvm
• INSTALLONLY
• DISTRI

Tumbleweed staging:

With cryptlvm:
http://pinky.arch.suse.de/tests/107#

Without cryptlvm:
http://pinky.arch.suse.de/tests/106#

Seems like the shutdown works as it should?

SLE cryptlvm:
http://pinky.arch.suse.de/tests/108#

Seeing this, I would assume that it is related to SLE <-> Opensuse

Looks promising so far. Do you have a PR where you referenced these tests?

I guess if you can make http://pinky.arch.suse.de/tests/108#step/shutdown/23 not fail you are good to go :)

Test#23 is with disabled workaround, the last both are basically the upstream code

Test with PPC and cryptlvm
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/6939

PPC + Cryptlvm + timeout 360 sec
https://openqa.suse.de/tests/2509212#

New try after history got scrambled:

https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/6949

https://openqa.suse.de/tests/2515227

With a 3 minute timeout it seems to work as intended, I am not yet sure what are the consequences of this

Here we have another failure (360sec timeout):
https://openqa.suse.de/tests/2515499#step/shutdown/10

After sleeping a night over the results I come to the conclusion that we ran in the wrong direction here, we should go back to the initial apporach of detecting unwanted popups instead of wanting to discover a failed shutdown. This avoids a lot of trouble with corner cases

As discussed in review:

Steps to shutdown:

initiate shutdown
press shutdown
press ok on confirmation
check if we get unwanted popups {
if no popups:
either continue
if popups:
change to console
poweroff
}

merged, please carefully track in production as well as update the blocked tickets.

Looks like we get a pop up but the system is shutting down anyways

https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/6983

merged

Opensuse shuts down normally on SLE I have the following behaviour on the latest build:
http://pinky.arch.suse.de/tests/124#step/shutdown/24

I really do not understand when it just shuts down, when it shuts down with a popup and when the shutdown gets blocked

Maybe a detection for "Authentication is required to shut down while users are logged in" could help?

We should wait at least until after the RC with this

My current idea would be to check for SHUTDOWN_NEEDS_AUTH and then in the error case use check_shutdown(120) and then manually shutting down