openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842023-04-17T07:59:50ZopenSUSE Project Management Tool
Redmine openQA Project - action #127739 (New): ASSET_1 gets outdated value when using openqa-clone-custom...https://progress.opensuse.org/issues/1277392023-04-17T07:59:50Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>When using openqa-clone-custom-git-refspec in order to clone a job, the value of ASSET_1 or any other ASSET get's the value from settings. But usually, the ASSET uploaded after the original job is run, gets another file name. For example, if ASSET_1=dev_tools.dud in settings, the original job will have uploaded ASSET_1=10931294-dev_tools.dud and the cloned job will fail because it cannot find dev_tools.dud with error:<br>
[info] [<a class="issue tracker-4 status-5 priority-4 priority-default closed" title="action: Breadcrumbs (Closed)" href="https://progress.opensuse.org/issues/555">#555</a>] Downloading "dev_tools.dud" from "<a href="http://openqa.suse.de/tests/10932003/asset/other/dev_tools.dud" class="external">http://openqa.suse.de/tests/10932003/asset/other/dev_tools.dud</a>"<br>
[info] [<a class="issue tracker-4 status-5 priority-4 priority-default closed" title="action: Breadcrumbs (Closed)" href="https://progress.opensuse.org/issues/555">#555</a>] Download of "/var/lib/openqa/cache/openqa.suse.de/dev_tools.dud" failed: 404 Not Found</p>
<p>In order to have a successful cloning, ASSET_1 has to be manually set to ASSET_1=10931294-dev_tools.dud while typing the refspec command.<br>
#openqa-clone-custom-git-refspec <a href="https://github.com/sofiasyria/os-autoinst-distri-opensuse/tree/master" class="external">https://github.com/sofiasyria/os-autoinst-distri-opensuse/tree/master</a> <a href="https://openqa.suse.de/tests/10931666" class="external">https://openqa.suse.de/tests/10931666</a> ASSET_1='10931294-dev_tools.dud'</p>
<p>It would be useful to automate the above process. </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>
openQA Infrastructure - action #90692 (Rejected): [sporadic] script_output getting wrong output o...https://progress.opensuse.org/issues/906922021-04-06T07:50:59Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>Only for aarch64, the following command:<br>
script_output("cat /proc/sys/kernel/sysrq");<br>
should return the content of the sysrq file, but 10% of the times it returns the character [, which seemt to be taken mistakenly by the serial console.<br>
Failure:<br>
<a href="https://openqa.suse.de/tests/5754960#step/yast2_system_settings/51" class="external">https://openqa.suse.de/tests/5754960#step/yast2_system_settings/51</a></p>
qe-yam - action #90350 (Rejected): Add yast2_system_settings for ncurseshttps://progress.opensuse.org/issues/903502021-03-19T11:08:21Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>Module yast2_system_settings is designed to run on gui, using libyui. The coverage can be extended for ncurses too. We can write a second module. The basic libyui code will be the same, but the x11 handling won't be needed. </p>
qe-yam - action #89494 (Rejected): Validate editing partition for mount_by optionshttps://progress.opensuse.org/issues/894942021-03-04T12:45:10Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>In ticket : <a href="https://progress.opensuse.org/issues/88533" class="external">https://progress.opensuse.org/issues/88533</a> a new test scenario "fstab_mount_by" was implemented , for mount_by option validation after installation. The scenario covers editing the fstab options for new partitions added in the partitioning. </p>
<p>The objective of this follow-up ticket is to extend coverage and perform installation on the image created by "fstab_mount_by" scenario and, while partitioning, edit the existing partitions, check if the existing mount_by option for each partition is recognized correctly by the expert partitioner and validate after installation if the new options take effect correctly.</p>
openQA Project - action #87725 (New): MULTIPATH backend variable doesn't set HDDMODEL for aarch64https://progress.opensuse.org/issues/877252021-01-13T16:48:15Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>According to the definition of the variable, if MULTIPATH=1:<br>
"Add HDD drives as multipath devices. Override HDDMODEL to virtio-scsi-pci"</p>
<p>That indeed happens when used on 64bit or ppc64le, but for aarch64, HDDMODEL remains to default value "virtio-blk-device". Test fails with error: "Device 'virtio-blk-device' can't go on SCSI bus". In order for the test to work, HDDMODEL needs to be set to "scsi-hd".</p>
qe-yam - action #80474 (Rejected): Implement check for emergency shell in case bootloader is stuckhttps://progress.opensuse.org/issues/804742020-11-26T16:49:08Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>In the scenario where the bootloader screen is stuck, the worker will detect stall and enter post_fail_hook. During post_fail_hook, it has occurred that select_console('root') induced the emergency shell. In this case, there is no check that will redirect any logs to the serial console, like <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/lib/utils.pm#L1042-L1066" class="external">handle_emergency</a> function.</p>
<p>We cannot add the check in <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/lib/susedistribution.pm#L683" class="external">activate_console</a> , as the function is called repeatedly in many tests. </p>
<p>A solution would be to find out which step of the activate_console function is triggering the emergency shell and see if we can implement a check for stuck bootloader screen in <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/lib/opensusebasetest.pm#L971" class="external">wait_boot_past_bootloader</a> or post_fail_hook, try to trigger emergency shell and if successful, collect logs.</p>
<p>Failure example:<br>
<a href="https://openqa.suse.de/tests/4922078" class="external">https://openqa.suse.de/tests/4922078</a></p>
<p>It may not be easy to reproduce the scenario, as it is sporadic for SUTs with RAID0 root partition, during firstboot. <br>
<a href="https://bugzilla.suse.com/show_bug.cgi?id=1178515" class="external">https://bugzilla.suse.com/show_bug.cgi?id=1178515</a></p>
qe-yam - action #73093 (Rejected): [y] test fails in installationhttps://progress.opensuse.org/issues/730932020-10-07T14:29:35Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>There have been some failures in installation module for different test suites. Even though the yast installer is still running, the needle match doesn't recognize it. </p>
<p>example:<br>
openQA test in scenario sle-15-SP3-Online-x86_64-autoyast_home_encrypted@64bit fails in<br>
<a href="https://openqa.suse.de/tests/4787697/modules/installation/steps/47" class="external">installation</a></p>
<p>Could be that the timeout in tests/installation/await_install.pm:74 might need to be increased, but as this is a sporadic failure it would need some verification runs.</p>
<p>Notice: The installation progress before and after failure is different, so this doesn't seem like an actual stall.</p>
openQA Tests - action #72184 (New): [virtualization][y] Select_console fails sporadically for svi...https://progress.opensuse.org/issues/721842020-10-01T15:10:12Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>There is a sporadic failure of approximately 17%, for prepare_data module for yast2_gui test suite. The SUT seems to be freezing with black screen, when select_console is called.</p>
<p>It is notable that by simplifying the module to:</p>
<pre><code>sub run {
select_console 'root-console';
}
1;
</code></pre>
<p>it still displays the same percentage of failure.</p>
<p>The issue is not present in case of using xterm and chvt 6.</p>
<pre><code>sub run {
x11_start_program('xterm');
wait_still_screen(5);
become_root;
assert_script_run "chvt 6";
assert_screen "tty6-selected";
}
1;
</code></pre>
<p>Unfortunately, the logs are not helpful. When successfully switching to tty6, the autoinst logs contain:<br>
[2020-09-30T17:28:05.896 CEST] [debug] <<< testapi::select_console(testapi_console="root-console")<br>
....<br>
[ 82.601276] <strong>systemd[1]: Started Getty on tty6.</strong></p>
<p>Looking at the logs from failed runs, the above phrase is missing.</p>
<p>openQA test in scenario sle-15-SP3-Online-x86_64-yast2_gui@svirt-xen-hvm fails in<br>
<a href="https://openqa.suse.de/tests/4718229/modules/prepare_test_data/steps/3" class="external">prepare_test_data</a></p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p><a href="https://openqa.suse.de/tests/4752856" class="external">48.1</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=x86_64&distri=sle&flavor=Online&machine=svirt-xen-hvm&test=yast2_gui&version=15-SP3" class="external">latest</a></p>
openQA Tests - action #71638 (Rejected): [y] test fails in validate_fs_tablehttps://progress.opensuse.org/issues/716382020-09-22T10:50:02Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>During msdos partitioning, the SWAP partition is selected to be created with UDF instead of swap filesystem. Even though, the screen matches at swap, there is an extra key sent and the result is that SWAP partition is missing and the filesystme validation fails:</p>
<p>[2020-09-22T04:58:41.696 CEST] [debug] <<< testapi::check_screen(mustmatch="partitioning_swap-format-selected", timeout=5)<br>
�[37m[2020-09-22T04:58:42.046 CEST] [debug] load of /var/lib/openqa/cache/openqa.suse.de/tests/sle/products/sle/needles/partitioning_swap-format-selected-20200217.png took 0.35 seconds<br>
�[0m�[32m[2020-09-22T04:58:44.670 CEST] [debug] >>> testapi::_handle_found_needle: found partitioning_swap-format-selected-20200121, similarity 1.00 @ 368/351<br>
�[0m[2020-09-22T04:58:44.670 CEST] [debug] tests/installation/partitioning/msdos_partition_table.pm:27 called Installation::Partitioner::LibstorageNG::v4::ExpertPartitionerController::add_partition_msdos -> lib/Installation/Partitioner/LibstorageNG/v4/ExpertPartitionerController.pm:168 called Installation::Partitioner::LibstorageNG::v4::ExpertPartitionerController::add_new_partition -> lib/Installation/Partitioner/LibstorageNG/v4/ExpertPartitionerController.pm:180 called Installation::Partitioner::AbstractExpertPartitionerController::_set_partition_options -> lib/Installation/Partitioner/AbstractExpertPartitionerController.pm:114 called Installation::Partitioner::FormattingOptionsPage::select_mount_device_radiobutton -> lib/Installation/Partitioner/FormattingOptionsPage.pm:96 called testapi::assert_screen<br>
[2020-09-22T04:58:44.670 CEST] [debug] <<< testapi::assert_screen(mustmatch="partition-format", timeout=30)<br>
�[32m[2020-09-22T04:58:44.791 CEST] [debug] >>> testapi::_handle_found_needle: found partitioning-format-20160504, similarity 1.00 @ 275/273<br>
�[0m[2020-09-22T04:58:44.792 CEST] [debug] tests/installation/partitioning/msdos_partition_table.pm:27 called Installation::Partitioner::LibstorageNG::v4::ExpertPartitionerController::add_partition_msdos -> lib/Installation/Partitioner/LibstorageNG/v4/ExpertPartitionerController.pm:168 called Installation::Partitioner::LibstorageNG::v4::ExpertPartitionerController::add_new_partition -> lib/Installation/Partitioner/LibstorageNG/v4/ExpertPartitionerController.pm:180 called Installation::Partitioner::AbstractExpertPartitionerController::_set_partition_options -> lib/Installation/Partitioner/AbstractExpertPartitionerController.pm:114 called Installation::Partitioner::FormattingOptionsPage::select_mount_device_radiobutton -> lib/Installation/Partitioner/FormattingOptionsPage.pm:97 called testapi::send_key<br>
[2020-09-22T04:58:44.792 CEST] [debug] <<< testapi::send_key(key="alt-o", do_wait=0, wait_screen_change=0)</p>
<p><a href="https://openqa.suse.de/tests/4711745#step/msdos_partition_table/86">https://openqa.suse.de/tests/4711745#step/msdos_partition_table/86</a></p>
<p><a href="https://openqa.suse.de/tests/4711745/modules/validate_fs_table/steps/35">https://openqa.suse.de/tests/4711745/modules/validate_fs_table/steps/35</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Installation with MSDOS partition table.</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/4686599" class="external">33.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/4636012" class="external">23.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&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 #67669 (Rejected): [y] Enable yast2_lan_restart_bond module for s390xhttps://progress.opensuse.org/issues/676692020-06-03T11:48:56Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>Module yast2_lan_restart_bond is part of yast2_gui test suite.<br>
For s390x, it fails due to <a href="https://bugzilla.suse.com/show_bug.cgi?id=1172444" class="external">bug#1172444</a>.</p>
<p>Check of the bug is fixed and modify the test suite schedule, accordingly. </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>