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-4 priority-4 priority-default" title="action: [security][QU] audit_remote_libvirt fails in 15-SP5 due to new libvirt behavior (Feedback)" href="https://progress.opensuse.org/issues/156658">#156658</a> for its issue).</li>
</ol>
openQA Tests - action #156658 (Feedback): [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>
openQA Tests - action #155257 (Resolved): [security][15-SP6] test fails in create_hdd_textmode_co...https://progress.opensuse.org/issues/1552572024-02-09T11:56:28Ztjyrinki_susetjyrinki+redmine@suse.de
<p>openQA test in scenario sle-15-SP6-Online-aarch64-create_hdd_textmode_common_criteria@aarch64 fails in<br>
<a href="https://openqa.suse.de/tests/13481151/modules/installation/steps/44" class="external">installation</a></p>
<p>Bootloader type should apparently be grub2-efi instead of grub2 on aarch64?</p>
<p>Last good: <a href="https://openqa.suse.de/tests/12896420" class="external">40.1</a> (or more recent)</p>
<p>Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?arch=aarch64&distri=sle&flavor=Online&machine=aarch64&test=create_hdd_textmode_common_criteria&version=15-SP6" class="external">latest</a></p>
openQA Tests - action #155248 (Workable): [security][15-SP6] logic of passphrase entering failed ...https://progress.opensuse.org/issues/1552482024-02-09T10:42:00Ztjyrinki_susetjyrinki+redmine@suse.de
<p>openQA test in scenario sle-15-SP6-Online-x86_64-autoyast_stig_remediation@64bit fails in<br>
<a href="https://openqa.suse.de/tests/13457092/modules/first_boot/steps/3" class="external">first_boot</a></p>
<p>It started in Build <a href="https://openqa.suse.de/tests/13085395" class="external">45.1</a></p>
<p>While it was still working in <a href="https://openqa.suse.de/tests/13003729" class="external">44.1</a> - over there the "boot_encrypt" module entered the passphrase, while now in boot_encrypt module it's still showing the grub authentication and thein fails in first_boot </p>
<p>If looking at the videos, even on 45.1 it does enter the grub passphrase, but then maybe (possibly, not necessarily) due to ticket <a class="issue tracker-4 status-3 priority-4 priority-default closed child" title="action: [security][15-SP6] GRUB now passes through unlocking, test needs to be changed (Resolved)" href="https://progress.opensuse.org/issues/152455">#152455</a> expects that it would be enough, while in this stig case it does not seem the pass-through is working anymore? Not sure why though, the password is the same but maybe it's part of stig logic to not allow pass-through?</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=64bit&test=autoyast_stig_remediation&version=15-SP6" class="external">latest</a></p>
<p>Automatic re-runs indicate git commit f69e77d29d96cab7c9a3e18c5cd2cfb73f371ee4 (from the time 44.1 build was done) still works for this test suite (<a href="https://openqa.suse.de/tests/13457092#comments" class="external">https://openqa.suse.de/tests/13457092#comments</a>).</p>
openQA Tests - action #155137 (Workable): [security] oscap_bash_pci_dss_4 fails due to unexpect...https://progress.opensuse.org/issues/1551372024-02-08T06:09:44Ztjyrinki_susetjyrinki+redmine@suse.de
<p>aarch64 only:</p>
<p>15-SP4:<br>
<a href="https://openqa.suse.de/tests/13465079/modules/oscap_xccdf_eval#2/steps/25" class="external">https://openqa.suse.de/tests/13465079/modules/oscap_xccdf_eval#2/steps/25</a></p>
<p>15-SP5:<br>
<a href="https://openqa.suse.de/tests/13465157#step/oscap_xccdf_eval#2/25" class="external">https://openqa.suse.de/tests/13465157#step/oscap_xccdf_eval#2/25</a></p>
<p>15-SP6:<br>
<a href="https://openqa.suse.de/tests/13458991#step/oscap_xccdf_eval#2/25" class="external">https://openqa.suse.de/tests/13458991#step/oscap_xccdf_eval#2/25</a></p>
<p>x86_64 and s390x pass:<br>
SP4&SP5:<br>
<a href="https://openqa.suse.de/tests/13461333" class="external">https://openqa.suse.de/tests/13461333</a><br>
<a href="https://openqa.suse.de/tests/13461236" class="external">https://openqa.suse.de/tests/13461236</a><br>
<a href="https://openqa.suse.de/tests/13461772" class="external">https://openqa.suse.de/tests/13461772</a><br>
<a href="https://openqa.suse.de/tests/13461649" class="external">https://openqa.suse.de/tests/13461649</a><br>
SP6:<br>
<a href="https://openqa.suse.de/tests/13457751" class="external">https://openqa.suse.de/tests/13457751</a></p>
openQA Tests - action #155050 (Workable): [security] all oscap tests fail on x86_64 and aarch64 i...https://progress.opensuse.org/issues/1550502024-02-07T07:45:38Ztjyrinki_susetjyrinki+redmine@suse.de
<p>See for example:</p>
<p>openQA test in scenario sle-15-SP4-Server-DVD-Updates-aarch64-oscap_ansible_anssi_bp28_high@aarch64-virtio fails in<br>
<a href="https://openqa.suse.de/tests/13447534/modules/boot_to_desktop/steps/8" class="external">boot_to_desktop</a></p>
<p>This is after the yesterday's changes to switch to GUI environment.</p>
<p>However all of s390x passes: <a href="https://openqa.suse.de/tests/13446821" class="external">https://openqa.suse.de/tests/13446821</a></p>
<p>On x86_64 and aarch64 it boots the desktop HDD but somehow the DESKTOP variable is overridden from somewhere still to be textmode, which probably causes the problem.</p>
<p>On s390x it's the same but it happens not to break on boot, but it also doesn't seem to actually use the desktop as DESKTOP=textmode there too.</p>
ALP - action #151558 (Resolved): [security] firstrun on sle-micro >= 6.0 should be ALPifiedhttps://progress.opensuse.org/issues/1515582023-11-28T06:58:19Ztjyrinki_susetjyrinki+redmine@suse.de
<p>openQA test in scenario sle-micro-6.0-Default-encrypted-x86_64-container_selinux@uefi fails in<br>
<a href="https://openqa.suse.de/tests/12874494/modules/firstrun/steps/5" class="external">firstrun</a></p>
<p>Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle-micro&flavor=Default-encrypted&machine=uefi&test=container_selinux&version=6.0" class="external">latest</a></p>
<p>Firstrun is failing with distri sle-micro and version 6.0 - that is, ALP - in the encrypted flavor (that does not use ignition but uses firstrun wizard). This is likely due to it picking up the SLE Micro 5.x expections while it should now work as intended on ALP. There may or may not be difference between ALP Dolomite and ALP Marble in this regard, but likely it should be largely the same.</p>
<p>selinux_setup was updated to use is_alp || is_sle_micro('>=6.0'), jeos/firstrun should maybe using is_sle || is_sle_micro('<6.0') in some places and the former in other places, not sure what would be optimal.</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>