openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842023-07-16T11:52:32ZopenSUSE Project Management Tool
Redmine openQA Tests - action #132821 (Resolved): agama test fails in validate_lvm due to wrong password ...https://progress.opensuse.org/issues/1328212023-07-16T11:52:32Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>During the beginning of the agama tests we set the root user to linux, but this variable is inherited throughout other test modules.<br>
The actual installation settings are defined in the agama playwright tests here: <a href="https://github.com/jknphy/e2e-agama-playwright/pull/6" class="external">https://github.com/jknphy/e2e-agama-playwright/pull/6</a><br>
username: bernhard<br>
password: nots3cr3t (same for root)</p>
<p>A record_info placed in the beginning of the validate_encrypt and validate_lvm module, shows that the worker variables are different that expected: <br>
<a href="https://openqa.opensuse.org/tests/3433326#step/validate_encrypt/1" class="external">https://openqa.opensuse.org/tests/3433326#step/validate_encrypt/1</a><br>
<a href="https://openqa.opensuse.org/tests/3433327#step/validate_lvm/1" class="external">https://openqa.opensuse.org/tests/3433327#step/validate_lvm/1</a></p>
<p>The variables of password and username are defined in the agama libraries:<br>
<a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/tree/master/lib/Yam/agama" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/tree/master/lib/Yam/agama</a></p>
<p><strong>Acceptance criteria</strong></p>
<ul>
<li>Make sure that the $password and $username inherited by validate_lvm and valicate_encrypt are according to the test expectations. Possibly add a pre-run hook in the module, if needed.</li>
</ul>
<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-aarch64-agama_dolomite_lvm@aarch64 fails in<br>
<a href="https://openqa.opensuse.org/tests/3432174/modules/validate_lvm/steps/5" class="external">validate_lvm</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/3432174" class="external">1.36</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.opensuse.org/tests/3428082" class="external">1.35</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=aarch64&distri=alp&flavor=agama-live-default-Playwright&machine=aarch64&test=agama_dolomite_lvm&version=agama-2.1-staging" class="external">latest</a></p>
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>
openQA Infrastructure - action #127337 (Resolved): Some s390x workers have been failing for all j...https://progress.opensuse.org/issues/1273372023-04-06T09:04:57Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>There are quite a few s390x failures on booting, so after comparing test results, the observation that workers:<br>
<a href="https://openqa.suse.de/admin/workers/1328" class="external">grenache-1:30</a><br>
<a href="https://openqa.suse.de/admin/workers/1348" class="external">grenache-1:40</a><br>
<a href="https://openqa.suse.de/admin/workers/1809" class="external">grenache-1:43</a><br>
<a href="https://openqa.suse.de/admin/workers/1812" class="external">grenache-1:44</a></p>
<p>have been constantly failing for all jobs for the last 11 months. It seeems that before this period of time, the workers (besides grenache-1:44 which was still s390x) were used for ipm and ppc tests and they are now switched to s390x service.</p>
<p>A very frequent error message is : Test died: unexpected end of data at /usr/lib/os-autoinst/consoles/VNC.pm line 187. <a href="https://openqa.suse.de/tests/10869590#step/bootloader_start/39" class="external">example</a> </p>
<p>Possibly related with: <a href="https://progress.opensuse.org/issues/108266" class="external">https://progress.opensuse.org/issues/108266</a></p>
<p>Note: we noticed this issue, after creating a generic s390x-kvm machine, to take advantage of s390-kvm WORKER_CLASS. It seems that other current s390x jobs that are designated to use s390x-kvm-sle12/15 do not run on these workers. For more information, see : <a href="https://progress.opensuse.org/issues/126293" class="external">https://progress.opensuse.org/issues/126293</a></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>
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>
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>
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 #69754 (Resolved): [y][u] tests fail in bootloader_start for ppc64le - Powe...https://progress.opensuse.org/issues/697542020-08-10T08:09:03Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>For the time being, some machines are turned off, see: <a href="https://mailman.suse.de/mlarch/SuSE/maxtorhof/2020/maxtorhof.2020.08/msg00005.html" class="external">https://mailman.suse.de/mlarch/SuSE/maxtorhof/2020/maxtorhof.2020.08/msg00005.html</a></p>
<p>All openqa ppc64le-hmc-single-disk or ppc64le-hmc-4disk test suites fail in bootloader_start or bootloader with the following error message<br>
<a href="https://openqa.suse.de/tests/4543002/modules/bootloader_start/steps/6" class="external">bootloader_start</a></p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since 9th of August (<a href="https://openqa.suse.de/tests/4541148" class="external">https://openqa.suse.de/tests/4541148</a>)</p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>Last good 6th of August (<a href="https://openqa.suse.de/tests/4528757" class="external">https://openqa.suse.de/tests/4528757</a>)</p>
openQA Tests - action #69658 (Resolved): [y] test fails in yast2_control_centerhttps://progress.opensuse.org/issues/696582020-08-06T14:17:05Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP2-Online-x86_64-yast2_gui@64bit fails in<br>
<a href="https://openqa.suse.de/tests/4528958/modules/yast2_control_center/steps/84" class="external">yast2_control_center</a></p>
<p>The needle yast2-control-center-security-center is too generic and validation can be premature, leading to test failure. </p>
<p>In this case, the needle matching happened before typing was finished and assert_and_click did not work as expected:<br>
<a href="https://openqa.suse.de/tests/4528958#step/yast2_control_center/81" class="external">https://openqa.suse.de/tests/4528958#step/yast2_control_center/81</a></p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Sporadic failure</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/4446522" class="external">209.2</a> (or more recent)</p>
openQA Project - action #69313 (Resolved): When using refspec for ppc for a particular job, PRODU...https://progress.opensuse.org/issues/693132020-07-24T10:25:20Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>While attempting to run refspecs for test "autoyast_reinstall" job on various architectures, I faced an issue specifically on ppc64le. The PRODUCTDIR needs to be set manually like following: <br>
<code>openqa-clone-custom-git-refspec https://github.com/sofiasyria/os-autoinst-distri-opensuse/tree/ac68803 https://openqa.suse.de/tests/4427385 ASSET_1="04427383-autoinst.xml" YAML_TEST_DATA=test_data/yast/autoyast_reinstall/autoyast_reinstall_ppc64le-hmc.yaml PRODUCTDIR="os-autoinst-distri-opensuse/products/sle"</code></p>
<p>If the above command is used without the PRODUCTDIR specification, the variable gets the value "os-autoinst-distri-opensuseos-autoinst-distri-opensuse/products/sle" which leads to test failure as here:<br>
<a href="https://openqa.suse.de/tests/4482090" class="external">https://openqa.suse.de/tests/4482090</a></p>
<p>The particular test suite runs for ppc64le-2g, ppc64le-hmc-single-disk, 64bit, s390x and aarch64. For both the ppc machines, the PRODUCTDIR needs to be set manually. For rest of them, it's not necessary.</p>
<p>I have unsuccessfully tried to reproduce the issue with other jobs on ppc.</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>
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>
openQA Project - action #62243 (Resolved): After latest updates, openQA has problematic behavior ...https://progress.opensuse.org/issues/622432020-01-17T12:44:19Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>After updating my workstation, OpenQA started having issue to run any job. The job remains on schedule, even though sometimes it runs. Sometimes it gets terminated without any error messages or logs. Sometimes I get the error "os-autoinst command server not available, job is likely not running" even though job runs. Video or Live view are never available. Initially, I thought this was a problem with Tumpleweed, so I formatted the workstation and installed Leap. I have the exact same behavior on Leap as well. Also in containerized version.</p>
<p>Link to OpenQA in container:<br>
<a href="http://falafel.suse.cz/" class="external">http://falafel.suse.cz/</a></p>