openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842024-03-15T07:34:18ZopenSUSE Project Management Tool
Redmine openQA Tests - action #157306 (Workable): [security][QU] seahorse_sshkey fails to enable WE exten...https://progress.opensuse.org/issues/1573062024-03-15T07:34:18Ztjyrinki_susetjyrinki+redmine@suse.de
<p>openQA test in scenario sle-15-SP5-Online-QR-x86_64-fips_env_mode_tests_crypt_x11@64bit fails in<br>
<a href="https://openqa.suse.de/tests/13708414/modules/seahorse_sshkey/steps/18" class="external">seahorse_sshkey</a></p>
<p>This was earlier attributed to <a href="https://bugzilla.suse.com/show_bug.cgi?id=1217071" class="external">https://bugzilla.suse.com/show_bug.cgi?id=1217071</a> but it has been reportedly fixed also in 15-SP5 now.</p>
openQA Tests - action #157291 (Resolved): [security] oqs_provider_openssl error due to failing zy...https://progress.opensuse.org/issues/1572912024-03-15T06:07:21Ztjyrinki_susetjyrinki+redmine@suse.de
<p>openQA test in scenario sle-15-SP4-Server-DVD-Updates-aarch64-fips_env_mode_tests_crypt_core@aarch64-virtio fails in<br>
<a href="https://openqa.suse.de/tests/13789916/modules/oqs_provider_openssl/steps/19" class="external">oqs_provider_openssl</a></p>
<p>This is a new test. The problem happens both on 15-SP4 and 15-SP5.</p>
<p>15-SP5: <a href="https://openqa.suse.de/tests/overview?arch=&flavor=&machine=&test=&modules=oqs_provider_openssl&module_re=&group_glob=&not_group_glob=&comment=&distri=sle&version=15-SP5&build=20240314-1&groupid=429#" class="external">https://openqa.suse.de/tests/overview?arch=&flavor=&machine=&test=&modules=oqs_provider_openssl&module_re=&group_glob=¬_group_glob=&comment=&distri=sle&version=15-SP5&build=20240314-1&groupid=429#</a><br>
15-SP4: <a href="https://openqa.suse.de/tests/overview?arch=&flavor=&machine=&test=&modules=oqs_provider_openssl&module_re=&group_glob=&not_group_glob=&comment=&distri=sle&version=15-SP4&build=20240314-1&groupid=429#" class="external">https://openqa.suse.de/tests/overview?arch=&flavor=&machine=&test=&modules=oqs_provider_openssl&module_re=&group_glob=¬_group_glob=&comment=&distri=sle&version=15-SP4&build=20240314-1&groupid=429#</a></p>
openQA Tests - action #157138 (Workable): [security] SLE Micro 6.0 s390x tests do not start (cont...https://progress.opensuse.org/issues/1571382024-03-13T08:21:13Ztjyrinki_susetjyrinki+redmine@suse.de
<p>openQA test in scenario sle-micro-6.0-Base-qcow-s390x-container_selinux@s390x-kvm fails in<br>
<a href="https://openqa.suse.de/tests/13756851/modules/disk_boot/steps/8" class="external">disk_boot</a></p>
<p>This has not been tried to be executed before. It is likely trying to boot with wrong modules and possibly wrong settings, comparison can be done to <a href="https://openqa.suse.de/tests/13756869" class="external">https://openqa.suse.de/tests/13756869</a> which boots the same image successfully.</p>
openQA Tests - action #156661 (Workable): [security][15-SP6] audit_remote_libvirt fails due to "S...https://progress.opensuse.org/issues/1566612024-03-05T12:50:05Ztjyrinki_susetjyrinki+redmine@suse.de
<p>openQA test in scenario sle-15-SP6-Online-x86_64-cc_audit-remote-libvirt@64bit fails in<br>
<a href="https://openqa.suse.de/tests/13713040/modules/audit_remote_libvirt/steps/13" class="external">audit_remote_libvirt</a></p>
<p>This didn't happen here: <a href="https://openqa.suse.de/tests/12736098#step/audit_remote_libvirt/10" class="external">https://openqa.suse.de/tests/12736098#step/audit_remote_libvirt/10</a> where the fix from ticket <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: [security][15-SP6] Update test audit_remote_libvirt for new libvirt behaviour (Resolved)" href="https://progress.opensuse.org/issues/137627">#137627</a> helped the test to finish with just one baseline test comparison failure.</p>
<a name="Acceptance-Criteria"></a>
<h2 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h2>
<ol>
<li>Make audit_remote_libvirt to pass on 15-SP6 (or, report product bug) without regressing on 15-SP5 (see ticket <a class="issue tracker-4 status-12 priority-4 priority-default" title="action: [security][QU] audit_remote_libvirt fails in 15-SP5 due to new libvirt behavior (Workable)" href="https://progress.opensuse.org/issues/156658">#156658</a> for its issue).</li>
</ol>
openQA Tests - action #156658 (Workable): [security][QU] audit_remote_libvirt fails in 15-SP5 due...https://progress.opensuse.org/issues/1566582024-03-05T12:43:14Ztjyrinki_susetjyrinki+redmine@suse.de
<p>This seems similar to ticket <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: [security][15-SP6] Update test audit_remote_libvirt for new libvirt behaviour (Resolved)" href="https://progress.opensuse.org/issues/137627">#137627</a> which was at the time only done for 15-SP6.</p>
<p>openQA test in scenario sle-15-SP5-Online-QR-x86_64-cc_audit-remote-libvirt@64bit fails in<br>
<a href="https://openqa.suse.de/tests/13708530/modules/audit_remote_libvirt/steps/13" class="external">audit_remote_libvirt</a></p>
<p>Last good: <a href="https://openqa.suse.de/tests/13102161" class="external">127.10</a> (or more recent)</p>
<p>Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Online-QR&machine=64bit&test=cc_audit-remote-libvirt&version=15-SP5" class="external">latest</a></p>
<a name="Acceptance-Criteria"></a>
<h2 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h2>
<ol>
<li>Fix audit_remove_libvirt to pass also on 15-SP5.</li>
</ol>
openQA Tests - action #155440 (Resolved): [security][15-SP6] test fails in suseconnect due to mis...https://progress.opensuse.org/issues/1554402024-02-14T06:35:11Ztjyrinki_susetjyrinki+redmine@suse.de
<p>openQA test in scenario sle-15-SP6-Online-s390x-fips_ker_mode_tests_crypt_tool@s390x-kvm fails in<br>
<a href="https://openqa.suse.de/tests/13495465/modules/suseconnect/steps/2" class="external">suseconnect</a></p>
<p>It's missing SCC_REGCODE_LIVE setting, not sure from where to get the right one though as they are arch specific.</p>
openQA Tests - action #155275 (Resolved): [security][15-SP6] test fails in x3270_ssl and xcahttps://progress.opensuse.org/issues/1552752024-02-09T13:28:00Ztjyrinki_susetjyrinki+redmine@suse.de
<p>openQA test in scenario sle-15-SP6-Online-x86_64-fips_ker_mode_tests_crypt_x11@64bit fails in<br>
<a href="https://openqa.suse.de/tests/13457437/modules/x3270_ssl/steps/29" class="external">x3270_ssl</a></p>
<p>Fails since (at least) Build <a href="https://openqa.suse.de/tests/13328819" class="external">47.2</a></p>
<p>Last good: <a href="https://openqa.suse.de/tests/13085721" class="external">45.1</a> (or more recent)</p>
openQA Tests - action #155269 (Resolved): [security][15-SP6] test fails in scap_workbench because...https://progress.opensuse.org/issues/1552692024-02-09T13:20:01Ztjyrinki_susetjyrinki+redmine@suse.de
<p>openQA test in scenario sle-15-SP6-Online-x86_64-scap_workbench@64bit fails in<br>
<a href="https://openqa.suse.de/tests/13458033/modules/scap_workbench/steps/23" class="external">scap_workbench</a></p>
<p>Last good: <a href="https://openqa.suse.de/tests/13086125" class="external">45.1</a> (or more recent)</p>
<p>It started failing in 47.2 with xterm not starting, but later on it fails reliably at a later stage asking for a supervisor password which it did not ask on 45.1. The test maybe needs some work to adhere to this possible sudo policy change?</p>
openQA Tests - action #155260 (Resolved): [security][15-SP6] test fails in audit2allow in 15-SP6https://progress.opensuse.org/issues/1552602024-02-09T13:00:08Ztjyrinki_susetjyrinki+redmine@suse.de
<p>openQA test in scenario sle-15-SP6-Online-x86_64-selinux@64bit fails in<br>
<a href="https://openqa.suse.de/tests/13458163/modules/audit2allow/steps/20" class="external">audit2allow</a></p>
<p>Fails since (at least) Build <a href="https://openqa.suse.de/tests/13086176" class="external">45.1</a></p>
<p>Last good: <a href="https://openqa.suse.de/tests/13004542" class="external">44.1</a> (or more recent)</p>
<p>Similar to otherwise unrelated ticket <a class="issue tracker-4 status-12 priority-4 priority-default" title="action: [security][15-SP6] logic of passphrase entering failed in autoyast_stig_remediation (Workable)" href="https://progress.opensuse.org/issues/155248">#155248</a>, this started in build 45.1. This time however older test commit does not help (<a href="https://openqa.suse.de/tests/13458163#comments" class="external">https://openqa.suse.de/tests/13458163#comments</a>), so is it maybe a product change or product bug, or something in our configuration?</p>
openSUSE Release Process - action #154528 (Resolved): [security] Expand journal_check ALP white l...https://progress.opensuse.org/issues/1545282024-01-30T09:02:49Ztjyrinki_susetjyrinki+redmine@suse.de
<p>Check bug_refs.json if there's anything from our side that needs additions if sle-micro 6.0 job group gets journal_check enabled.</p>
qe-yam - action #97289 (Rejected): [qem][qu] test fails in await_install in 15-SP3 QUhttps://progress.opensuse.org/issues/972892021-08-20T08:46:33Ztjyrinki_susetjyrinki+redmine@suse.de
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP3-Online-QR-ppc64le-crypt_no_lvm@ppc64le fails in<br>
<a href="https://openqa.suse.de/tests/6903766/modules/await_install/steps/3" class="external">await_install</a></p>
<p>This was passing in 188.13 which was before git commit "Fix YaST-related tests in QR Updates for SP3", maybe even if not directly affected something was changed around that time that fixed others but broke this?</p>
<p>It is however passing for aarch64 and x86: <a href="https://openqa.suse.de/tests/6872059" class="external">https://openqa.suse.de/tests/6872059</a> <a href="https://openqa.suse.de/tests/6872114" class="external">https://openqa.suse.de/tests/6872114</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Maintainer: riafarov. Test installation with encrypted partitions but without lvm enabled. This is supported only by storage-ng, hence, do NOT enable test suite on distris without storage-ng.</p>
<p>(crypt-)LVM installations can take longer, especially on non-x86_64 architectures.</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/6641855" class="external">188.14</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/6590507" class="external">188.13</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-QR&machine=ppc64le&test=crypt_no_lvm&version=15-SP3" class="external">latest</a></p>
qe-yam - action #96842 (Closed): [qe-yast][qu] test fails in new_partitioning_gpt in 15-SP3 QUhttps://progress.opensuse.org/issues/968422021-08-13T13:13:18Ztjyrinki_susetjyrinki+redmine@suse.de
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>Could you check why this repeatedly fails complaining about bootability? Compare to <a href="https://openqa.suse.de/tests/6590552#step/new_partitioning_gpt/3" class="external">https://openqa.suse.de/tests/6590552#step/new_partitioning_gpt/3</a> in the previous build.</p>
<p>openQA test in scenario sle-15-SP3-Online-QR-x86_64-lvm-encrypt-separate-boot@64bit fails in<br>
<a href="https://openqa.suse.de/tests/6837970/modules/new_partitioning_gpt/steps/4" class="external">new_partitioning_gpt</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Same as lvm-full-encrypt, but with separate boot not encrypted partition, only installation to not repeat everything again with small risk.<br>
Maintainer: riafarov</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/6641890" class="external">188.14</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/6590552" class="external">188.13</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-QR&machine=64bit&test=lvm-encrypt-separate-boot&version=15-SP3" class="external">latest</a></p>
qe-yam - action #91175 (Rejected): [qe-yast][qem] Add existing Product QE tests to QEMhttps://progress.opensuse.org/issues/911752021-04-15T06:11:54Ztjyrinki_susetjyrinki+redmine@suse.de
<p>After comparing test coverage of SLE 15 SP2 and SP3 in opneQA I identified several tests that are exclusive to either pre-release or post-release testing and could be easily used to increase our coverage just by using what we already have.</p>
<p>It is possible that are some errors and some of the tests from the list are already being used. It is also just my opinion, therefor review from other colleagues is more then welcome.</p>
<p>These are the YaST tests that run only before release and could be used also after the release (product QE -> QEM)</p>
<p>tests/console/vsftpd.pm<br>
tests/console/yast2_cmdline.pm<br>
tests/console/yast2_dns_server.pm<br>
tests/console/yast2_kdump.pm<br>
tests/console/yast2_lan_hostname.pm<br>
tests/console/yast2_ntpclient.pm<br>
tests/console/yast2_proxy.pm<br>
tests/console/yast2_rmt.pm<br>
tests/console/yast2_samba.pm<br>
tests/console/yast2_settings.pm<br>
tests/console/yast2_snapper_ncurses.pm<br>
tests/console/yast2_vnc.pm<br>
tests/security/yast2_apparmor/manually_add_profile.pm<br>
tests/security/yast2_apparmor/scan_audit_logs.pm<br>
tests/security/yast2_apparmor/settings_disable_enable_apparmor.pm<br>
tests/security/yast2_apparmor/settings_toggle_profile_mode.pm<br>
tests/security/yast2_users/add_users.pm</p>
openSUSE admin - tickets #80354 (Rejected): ns3.opensuse.org reports wrong IP to meet.opensuse.orghttps://progress.opensuse.org/issues/803542020-11-25T09:58:45Ztjyrinki_susetjyrinki+redmine@suse.de
<p>The new meet.o.o server was put into place, and it's at 195.135.221.174. However, ns3.opensuse.org disagrees and reports 173, which breaks meet.o.o for everyone (unless using direct IP).</p>
<p>Meanwhile, ns2 and ns4 are also down, possibly something to look at as well and verify if they'll eventually agree on the IP of meet.o.o.</p>
<p>-Timo </p>
qe-yam - action #80244 (Closed): [qam] setup_libyui fails on aarch64 on 15SP1https://progress.opensuse.org/issues/802442020-11-24T07:33:04Ztjyrinki_susetjyrinki+redmine@suse.de
<p>Commit b391b84490214cfd27387353a5bd18fba1d8e2fe (Adjust qemu backend scheduled for RAID0/1/5/6/10 scenarios) added setup_libyui which fails on 15SP1 on aarch64:</p>
<p><a href="https://openqa.suse.de/tests/overview?distri=sle&version=15-SP1&build=47.3&groupid=249" class="external">https://openqa.suse.de/tests/overview?distri=sle&version=15-SP1&build=47.3&groupid=249</a></p>
<p><a href="https://openqa.suse.de/tests/5060842" class="external">https://openqa.suse.de/tests/5060842</a></p>
<p>The test is part of the QU5 validation being done today.</p>
<p>Note: There is no more QUs to 15SP1 after QU5, possibly finalized today, so this ticket is more for information. Trying to run with customs schedule now.</p>