openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842024-02-21T14:12:30ZopenSUSE Project Management Tool
Redmine qe-yam - action #155758 (Resolved): [sporadic] Reboot takes too long for ppc64lehttps://progress.opensuse.org/issues/1557582024-02-21T14:12:30Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>For some ppc tests, we experience a sporadic reboot failure on different points of the test. As the failure doesn't happen every time on the same point, it could be an infrastructure issue that might be fixed by increasing the timeout.</p>
<p>Failure examples:<br>
<a href="https://openqa.suse.de/tests/13549614#next_previous" class="external">https://openqa.suse.de/tests/13549614#next_previous</a><br>
<a href="https://openqa.suse.de/tests/13554127#next_previous" class="external">https://openqa.suse.de/tests/13554127#next_previous</a></p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: Check if the ppc failures can go away by increasing the reboot timeout for ppc64le.</p>
<a name="Additional-information"></a>
<h4 >Additional information<a href="#Additional-information" class="wiki-anchor">¶</a></h4>
<ul>
<li>In case the issue persists, check if it could be a bug.</li>
<li>In case there are no indications of a bug, ask tools team for more information
note: not sure how this two suggestions above could go, as power kvm is not officially supported and tools squad is not taking care of exotic architecture.
Most likely if unstable it is better to consider disabling the scenario, we'll see...</li>
</ul>
qe-yam - action #154753 (Resolved): [sporadic] Make stable validate_lvm_raid1 reboothttps://progress.opensuse.org/issues/1547532024-02-01T14:17:37Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p><a href="https://openqa.suse.de/tests/13402260/modules/validate_lvm_raid1/steps/62" class="external">validate_lvm_raid1</a> test for x86_64 fails sporadically during reboot, as it is expected to see textmode linux login but the loading screen is taking too long.</p>
<a name="Scope"></a>
<h4 >Scope<a href="#Scope" class="wiki-anchor">¶</a></h4>
<p>The failure rate is about 8/10 test runs with increased bootloader timeout (see : <a href="https://github.com/sofiasyria/os-autoinst-distri-opensuse/blob/589791e625851f5227063559107c9c45e004a34b/tests/console/validate_lvm_raid1.pm#L30" class="external">https://github.com/sofiasyria/os-autoinst-distri-opensuse/blob/589791e625851f5227063559107c9c45e004a34b/tests/console/validate_lvm_raid1.pm#L30</a> )<br>
and 2/10 with increased QEMURAM=2048 </p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: The test should not fail at all.</p>
<a name="Additional-information"></a>
<h4 >Additional information<a href="#Additional-information" class="wiki-anchor">¶</a></h4>
<p>Last good: <a href="https://openqa.suse.de/tests/13373530" class="external">50.1</a> (or more recent)<br>
Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Online&machine=64bit&test=lvm%2BRAID1&version=15-SP6" class="external">latest</a></p>
qe-yam - action #153964 (In Progress): [Research: 24h] Check how to not need to set YUI_REST_API=...https://progress.opensuse.org/issues/1539642024-01-19T13:03:24Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>Currently, we are distinguishing the libuyi test from the non-libyui tests by using the variable YUI_REST_API.<br>
It would be more convenient to create a different way, based on the version of the os (=+sles15-sp3). <br>
The challenge would be to avoid using multiple conditions in the os-autoinst-opensuse-distro repo.<br>
This settings is tightly coupled with the yaml schedule, so it might require some research what are all the points in the code affected.</p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: Find strategy to avoid setting YUI_REST_API at all.</p>
qe-yam - action #133616 (Rejected): agama full_disk_encryption and lvm tests fail due to changes...https://progress.opensuse.org/issues/1336162023-08-01T11:49:49Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>The latest changes in Agama live image is that only dolomite is available for installation, no ALM micro or server. Therefore, we need to adjust our playwright test lvm and full_disk_encryption that currently fail. The Tumbleweed test will remain as is, because tumbleweed is still available.</p>
<p><a href="https://openqa.opensuse.org/tests/overview?distri=alp&version=agama-2.1-staging&build=2.17&groupid=96" class="external">https://openqa.opensuse.org/tests/overview?distri=alp&version=agama-2.1-staging&build=2.17&groupid=96</a></p>
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario alp-agama-2.1-staging-agama-live-default-Playwright-x86_64-agama_dolomite_full_disk_encryption@64bit-2G fails in<br>
<a href="https://openqa.opensuse.org/tests/3470423/modules/agama_full_disk_encryption/steps/6" class="external">agama_full_disk_encryption</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>The base test suite is used for job templates defined in YAML documents. It has no settings of its own.</p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://openqa.opensuse.org/tests/3468486" class="external">2.16</a></p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>Last good: <a href="https://openqa.opensuse.org/tests/3457233" class="external">2.5</a> (or more recent)</p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Always latest result in this scenario: <a href="https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=alp&flavor=agama-live-default-Playwright&machine=64bit-2G&test=agama_dolomite_full_disk_encryption&version=agama-2.1-staging" class="external">latest</a></p>
qe-yam - action #128606 (Rejected): [sporadic] test fails in install_servicehttps://progress.opensuse.org/issues/1286062023-05-03T13:35:08Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>After install_service module is attempting to install,enable and start vsftpd, it runs the /etc/bash/bash.local and we expect it to return no error ( $? = 0 ). Even though the script doesn't seem to fail, openqa is reporting <a href="https://openqa.suse.de/tests/11022849#step/install_service/197" class="external">failure</a> . Find the root cause and provide solution , in case there are false failures reported by openqa.</p>
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP5-Regression-on-Migration-from-SLE12-SPx-ppc64le-offline_sles12sp5_pscc_sdk-lp-asmm-contm-lgm-tcm-wsm-pcm_all_full@ppc64le-2g fails in<br>
<a href="https://openqa.suse.de/tests/10918493/modules/install_service/steps/199" class="external">install_service</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>The base test suite is used for job templates defined in YAML documents. It has no settings of its own.</p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://openqa.suse.de/tests/10905871" class="external">90.1</a></p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>Last good: <a href="https://openqa.suse.de/tests/10849460" class="external">88.1</a> (or more recent)</p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?arch=ppc64le&distri=sle&flavor=Regression-on-Migration-from-SLE12-SPx&machine=ppc64le-2g&test=offline_sles12sp5_pscc_sdk-lp-asmm-contm-lgm-tcm-wsm-pcm_all_full&version=15-SP5" class="external">latest</a></p>
qe-yam - action #128564 (Rejected): [sporadic] investigate failure for validate_first_disk_select...https://progress.opensuse.org/issues/1285642023-05-03T07:22:13Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>select_disk test runs on x86_64, aarch64 and ppc64le. For ppc, we see very often a failure of the test validation, to make the installation on the sda disk. We should investigate if our expectations make sense, contact the developers (possibly ask in linux mail list, in case yast developers are not certain). In case the disk selection cannot be guaranteed, we should disable the test for ppc. Otherwise open a bug report.</p>
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP5-Online-ppc64le-select_disk@ppc64le-hmc-4disk fails in<br>
<a href="https://openqa.suse.de/tests/9518220/modules/validate_first_disk_selection/steps/6" class="external">validate_first_disk_selection</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Test the selection of "first" disk with the guided setup in partitioning. This is also used as a prerequisite for real hardware tests to select the right disk for installation and not a "random" one.</p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://openqa.suse.de/tests/9518220" class="external">21.1</a> (current job)</p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>Last good: (unknown) (or more recent)</p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?arch=ppc64le&distri=sle&flavor=Online&machine=ppc64le-hmc-4disk&test=select_disk&version=15-SP5" class="external">latest</a></p>
qe-yam - action #125717 (Resolved): [sporadic] test fails in openldap_to_389dshttps://progress.opensuse.org/issues/1257172023-03-09T12:46:35Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>There is a sporadic failure for all regression tests that run openlad_to_389ds module, at the validation point that checks if the users belong to group1. It appears from the result , that the group data for the testusers are missing from the output . </p>
<p>openQA test in scenario sle-15-SP5-Regression-on-Migration-from-SLE12-SPx-x86_64-offline_sles12sp4_ltss_pscc_sdk-lp-we-asmm-contm-lgm-pcm-tcm-wsm_def_full@sofiasyria/os-autoinst-distri-opensuse#ldap@64bit fails in<br>
<a href="https://openqa.suse.de/tests/10640986/modules/openldap_to_389ds/steps/70" class="external">openldap_to_389ds</a></p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: Ensure validation is correct</p>
<a name="Suggestions"></a>
<h4 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h4>
<p>We could try a retry on that point.</p>
qe-yam - action #99261 (Rejected): [sporadic] s390x tests fail in first_boot and boot_to_desktop https://progress.opensuse.org/issues/992612021-09-24T16:47:24Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>This failure has occurred both for first_boot and boot_to_desktop on s390x. What happens is that handle_login function in lib/x11utils.pm is checking if the desktop matches with <a href="https://openqa.suse.de/tests/7218545#step/first_boot/9" class="external">gnome-activities</a> and then presses esc.</p>
<pre><code>249 if (match_has_tag('gnome-activities')) {
250 send_key('esc');
251 assert_screen([qw(generic-desktop opensuse-welcome)]);
252 }
</code></pre>
<p>After that it expects that the desktop will match with normal generic desktop, but we see no change. According to the autoinst.log the esc key is sent indeed. We need to check why the key takes no effect on the desktop. An idea would be to add a second check, for example: send_key('esc') if assert_screen "gnome-activities"; so that in case 'esc' is not accepted the first time, it would take effect, the second time.</p>
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP4-Online-s390x-zfcp@s390x-zfcp fails in<br>
<a href="https://openqa.suse.de/tests/7218545/modules/first_boot/steps/11" class="external">first_boot</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Testsuite maintained at <a href="https://gitlab.suse.de/qa-maintenance/qam-openqa-yml" class="external">https://gitlab.suse.de/qa-maintenance/qam-openqa-yml</a>. Maintainer: QE Yast, mgriessmeier</p>
<p>Installation-only test configuring an s390x ZFCP storage.</p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://openqa.suse.de/tests/6950169" class="external">29.1</a></p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>Last good: (unknown) (or more recent)</p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?arch=s390x&distri=sle&flavor=Online&machine=s390x-zfcp&test=zfcp&version=15-SP4" class="external">latest</a></p>
qe-yam - action #97709 (Closed): [sporadic] accept_timezone_configuration fails to navigate next ...https://progress.opensuse.org/issues/977092021-08-30T11:21:48Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>Even though, the yui logs show that next was pressed after the timezone module was shown, the installation doesn't proceed as expected. This happens sporadically. We need to investigate if indeed the button is not pressed or if it takes too long for the next screen to appear and fix the issue accordingly.</p>
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP4-Online-ppc64le-multipath@ppc64le-no-tmpfs fails in<br>
<a href="https://openqa.suse.de/tests/6949823/modules/hostname_inst/steps/2" class="external">hostname_inst</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Testsuite maintained at <a href="https://gitlab.suse.de/qa-maintenance/qam-openqa-yml" class="external">https://gitlab.suse.de/qa-maintenance/qam-openqa-yml</a>. Maintainer: QE Yast</p>
<p>Test installation on machine with virtual multipath hardware. Only tests succesful detection of multipath and installation. No functional testing of multipath itself.</p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://openqa.suse.de/tests/6949823" class="external">29.1</a> (current job)</p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>Last good: <a href="https://openqa.suse.de/tests/6914083" class="external">26.1</a> (or more recent)</p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?arch=ppc64le&distri=sle&flavor=Online&machine=ppc64le-no-tmpfs&test=multipath&version=15-SP4" class="external">latest</a></p>
<a name="Suggestion"></a>
<h2 >Suggestion<a href="#Suggestion" class="wiki-anchor">¶</a></h2>
<p>Most likely the button was pressed but the screen takes some time to load, we can see here <a href="https://openqa.suse.de/tests/6949823#step/accept_timezone_configuration/1" class="external">the time zone combobox</a> is still not loaded, so we could be more strict in is_shown() method of the screen.</p>
qe-yam - action #91425 (Rejected): [sporadic] aarch64 tests incomplete "associated worker re-conn...https://progress.opensuse.org/issues/914252021-04-20T12:35:04Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>We are seeing a lot of similar failures for aarch64.<br>
This ticket is created in order to collect statistics for the particular issue and for labeling the failures on production.</p>
qe-yam - action #89932 (Closed): [sporadic] stabilize partitioning_firstdisk https://progress.opensuse.org/issues/899322021-03-11T13:44:06Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>Failing test: select_disk <a href="https://openqa.suse.de/tests/5646458" class="external">https://openqa.suse.de/tests/5646458</a><br>
The mentioned module is not stable due to the needle use. It can confuse sda with sdd, due to resemblance of the letters. Plus, the conditions of the function "select_first_hard_disk" don't seem to be well defined. When the test (passes)[[https://openqa.suse.de/tests/5553616#step/partitioning_firstdisk/3]] there seems to be an check for all checkboxes, but when the test (fails)[[https://openqa.suse.de/tests/5646458#step/partitioning_firstdisk/4]] this check is missing. </p>
<p>We could make modifications in the current function to make it more precise or we can rewrite the module and use libyui.</p>
<p>Scope is only screen for selecting disk for the partitions, other steps will be covered in <a class="issue tracker-4 status-5 priority-4 priority-default closed child" title="action: Rewrite partition creation with libyui REST API in guided setup (Closed)" href="https://progress.opensuse.org/issues/87919">#87919</a></p>
qe-yam - action #88480 (Closed): [sporadic] boot_encrypt doesn't unlock encrypted disk for cryptl...https://progress.opensuse.org/issues/884802021-02-08T12:35:56Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>It seems that the wrong password is typed.</p>
<p>openQA test in scenario sle-15-SP3-Online-ppc64le-cryptlvm@ppc64le fails in<br>
<a href="https://openqa.suse.de/tests/5422061/modules/first_boot/steps/3" class="external">first_boot</a></p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?arch=ppc64le&distri=sle&flavor=Online&machine=ppc64le&test=cryptlvm&version=15-SP3" class="external">latest</a></p>
<p>Acceptance criteria:</p>
<ul>
<li>Add a stabilization check so that if disk is not unlocked, the password will be entered again.</li>
<li>If there is a tools issue worth investigating, open a new ticket.</li>
</ul>
qe-yam - action #75424 (Closed): [sporadic] test fails in force_scheduled_tasks https://progress.opensuse.org/issues/754242020-10-27T20:16:16Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>Full medium test suites skip_registration and allmodules+allpatterns+registration fail sporadically for aarch64 in force_scheduled_tasks. The module is running in a loop:</p>
<pre><code>read load dummy < /proc/loadavg ; top -n1 -b| head -n30 ; test "${load/./}" -lt $limit && break ;
</code></pre>
<p>and is expected to be finished in 1005 seconds, but it times out.<br>
In all failures spotted so far, the serial returned the same output at the moment of timeout </p>
<pre><code>BTRFS info (device vda2): qgroup scan completed (inconsistency flag cleared)
</code></pre>
<p>so there could be some BTRFS inconsistency that is taking too long to be dealt with by the system.</p>
<p>As we cannot run proper performance tests and goal of the module is to improve stability of the tests.</p>
<p>failures:<br>
<a href="https://openqa.suse.de/tests/4893533/modules/force_scheduled_tasks/steps/6" class="external">allmodules+allpatterns+registration</a><br>
<a href="https://openqa.suse.de/tests/4893537#next_previous" class="external">skip_registration</a></p>
<p>Fails since (at least) Build <a href="https://openqa.suse.de/tests/4879296" class="external">67.1</a> </p>
<p><a href="https://openqa.suse.de/tests/latest?arch=aarch64&distri=sle&flavor=Full&machine=aarch64&test=allmodules%2Ballpatterns%2Bregistration&version=15-SP3" class="external">latest allmodules+allpatterns+registration</a><br>
<a href="https://openqa.suse.de/tests/latest?arch=aarch64&distri=sle&flavor=Full&machine=aarch64&test=skip_registration&version=15-SP3" class="external">latest skip_registration</a></p>
qe-yam - action #73096 (Rejected): [sporadic] msdos test fails in validate_fs_tablehttps://progress.opensuse.org/issues/730962020-10-07T15:14:47Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>During msdos partitioning, the home partition is selected to be created with UDF instead of xfs filesystem. Even though, the screen matches at xfs, there is an extra key sent and the result is that home filesystem is UDF and the filesystem validation fails:</p>
<p>openQA test in scenario sle-15-SP3-Online-x86_64-msdos@svirt-xen-pv fails in<br>
<a href="https://openqa.suse.de/tests/4787764/modules/validate_fs_table/steps/28" class="external">validate_fs_table</a></p>
<p>Similar behavior has been seen before for SWAP partition but was not investigated:<br>
<a href="https://progress.opensuse.org/issues/71638" class="external">https://progress.opensuse.org/issues/71638</a></p>
<p>So we should stabilize test execution that we do not end up sending one extra key press, after wanted filesystem is selected.</p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>Last good: <a href="https://openqa.suse.de/tests/4780316" class="external">51.1</a> (or more recent)</p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Online&machine=svirt-xen-pv&test=msdos&version=15-SP3" class="external">latest</a></p>
qe-yam - action #67078 (Rejected): [functional][y] Implement workaround for shutdown failure on H...https://progress.opensuse.org/issues/670782020-05-20T10:01:38Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>Shutdown module fails on Hyper-V for test suites with DESKTOP=gnome, in scenarios where previous module leaves system in tty2 or tty6, due to <a href="https://bugzilla.suse.com/show_bug.cgi?id=1171290" class="external">bug#1171290</a>. OpenQA failure could be replaced with soft failure until the bug is fixed. An easy way would be to create a needle for the <a href="https://openqa.suse.de/tests/4203853#step/shutdown/11" class="external">stall screen</a> and when matched, any window (e.g. terminal) would maximize and minimize. The movement of the window should resolve the stall screen and the shutdown module should then be able to be completed successfully.</p>
<p>Parent ticket: </p>
<ul>
<li><a href="https://progress.opensuse.org/issues/64466" class="external">https://progress.opensuse.org/issues/64466</a></li>
</ul>
<p>Acceptance criteria:</p>
<ul>
<li>Shutdown module finishes with soft failure.</li>
</ul>