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 #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 #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 #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>
openQA Tests - action #80210 (Rejected): [ppc64le] ppc64le-hmc tests fail in bootloader_starthttps://progress.opensuse.org/issues/802102020-11-23T12:26:00Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>There is an issue with ppc64le-hmc-single-disk workers. All tests fail:</p>
<p>openQA test in scenario sle-15-SP3-Full-ppc64le-allmodules+registration@ppc64le-hmc-single-disk fails in bootloader_start. </p>
<p>"HSCL9010 This operation is only allowed when the managed system is in the Standby or Operating state"</p>
<p>failure example:</p>
<p><a href="https://openqa.suse.de/tests/5057353/modules/bootloader_start/steps/7" class="external">bootloader_start</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>
openQA Tests - action #68764 (Rejected): [functional][y] yast2_gui@svirt-xen-hvm fails when retri...https://progress.opensuse.org/issues/687642020-07-08T12:25:12Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>Test suite yast2_gui@svirt-xen-hvm is set to START_AFTER_TEST=create_hdd_gnome. When a new build is triggering all test suites, create_hdd_gnome@svirt-xen-hvm fails and yast2_gui@svirt-xen-hvm is skipped as expected. <br>
<a href="https://openqa.suse.de/tests/4342327#dependencies" class="external">https://openqa.suse.de/tests/4342327#dependencies</a></p>
<p>If we trigger yast2_gui@svirt-xen-hvm, it would be expected that create_hdd_gnome@svirt-xen-hvm should be triggered as well but this doesn't happen, resulting in failure as the dependent test can't find HDD_1.<br>
<a href="https://openqa.suse.de/tests/4424999" class="external">https://openqa.suse.de/tests/4424999</a></p>
<pre><code>[error] [pid:6204] Failed to download SLES-15-SP2-x86_64-Build209.2@svirt-xen-hvm-gnome.qcow2 to /var/lib/openqa/cache/openqa.suse.de/SLES-15-SP2-x86_64-Build209.2@svirt-xen-hvm-gnome.qcow2
</code></pre> openQA Tests - action #67672 (Rejected): [functional][y] Extend coverage of yast2_gui test moduleshttps://progress.opensuse.org/issues/676722020-06-03T12:02:54Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>There are some modules on the test that fail, due to needle mismatch. Currently the modules are removed from the schedule for the architectures that fail.</p>
<p>s390-> yast2_datetime, yast2_bootloader, yast2_lang <br>
xen-hvm -> yast2_network_settings<br>
ppc -> yast2_bootloader, yast2_lang<br>
aarch64 -> yast2_bootloader</p>
<p>Create the necessary needles and enable the modules on the yast2_gui schedule. For ppc and aarch64, possible the same needles created for s390 would work.</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>
openQA Tests - action #63922 (Rejected): [functional][y] Sporadic failure of mediacheck module in...https://progress.opensuse.org/issues/639222020-02-27T15:14:42Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>After build 131.1, it is observed that while module "mediacheck" runs on hyperV, "Check installation media" is selected, but instead of actually checking the media, test goes back to grub menu and selects "installation". Test fails when warning for Beta distribution appears, after timing out. </p>
<p><a href="https://openqa.suse.de/tests/3928000#step/mediacheck/11" class="external">https://openqa.suse.de/tests/3928000#step/mediacheck/11</a></p>
<p>The issue happens sporadically.</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/3915652" class="external">143.1</a> (or more recent)</p>