openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842022-10-19T13:12:21ZopenSUSE Project Management Tool
Redmine qe-yam - action #119083 (Rejected): [Timebox: 3 days] Investigate how to make SUT offline on PowerVMhttps://progress.opensuse.org/issues/1190832022-10-19T13:12:21Zgeorggkioulis@suse.com
<p>Related to <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="action: Run offline_install+skip_registration with PowerVM (Resolved)" href="https://progress.opensuse.org/issues/116116">#116116</a></p>
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>Testsuite <a href="https://openqa.suse.de/tests/overview?arch=&flavor=&machine=&test=offline_install%2Bskip_registration_dev&modules=&module_re=&version=15-SP5&distri=sle&groupid=456#" class="external">offline_install+skip_registration_dev</a> on ppc64le in development group is similar to <a href="https://openqa.suse.de/tests/overview?arch=ppc64le&flavor=&machine=&test=offline_install%2Bskip_registration&modules=&module_re=&version=15-SP5&distri=sle&groupid=129#" class="external">offline_install+skip_registration</a> but it runs on PowerVM backend (<code>pvm_hmc</code>) instead of QEMU.<br>
Both <code>offline_install+skip_registration_dev</code> and <code>offline_install+skip_registration</code> require an offline SUT to run. This is achieved by providing the <code>OFFLINE_SUT=1</code> setting.</p>
<p>However the <code>OFFLINE_SUT=1</code> can only set a QEMU backend offline as can be seen in <a href="https://github.com/os-autoinst/os-autoinst/blob/master/backend/qemu.pm#L825" class="external">os-autoinst/qemu.pm</a>.<br>
This ticket aims to investigate whether it is possible to set the system offline via <a href="https://github.com/os-autoinst/os-autoinst/blob/master/backend/pvm_hmc.pm" class="external">os-autoinst/pvm_hmc.pm</a> backend or even via boot parameters in the bootloader stage of the testsuite.<br>
This would hopefully prevent the failure on the PowerVM job <a href="https://openqa.suse.de/tests/overview?arch=&flavor=&machine=&test=offline_install%2Bskip_registration_dev&modules=&module_re=&version=15-SP5&distri=sle&groupid=456#" class="external">offline_install+skip_registration_dev</a></p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: Investigate whether it is possible to set the PowerVM system offline via it's hypervisor settings (maybe as an <code>HMC_*</code> variable). <br>
<strong>AC2</strong>: If <strong>AC1</strong> is not possible, investigate whether it is possible to set the PowerVM system offline via a boot parameter. Some candidates here can be the <code>netdev</code> kernel parameter or the even the obsoleted <code>ether</code> parameter, which might be used to disable Ethernet cards.<br>
<strong>AC3</strong>: If any of the above works, create a new progress ticket to implement the change and move <code>offline_install+skip_registration_dev</code> from development to production, replacing the existing <code>offline_install+skip_registration</code> testsuite that runs there.</p>
qe-yam - action #118966 (Rejected): Testuiste mru-iscsi_{client,server}_normal_auth_backstore_{lv...https://progress.opensuse.org/issues/1189662022-10-17T16:13:22Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>Related to <a class="issue tracker-4 status-3 priority-5 priority-high3 closed child" title="action: Add AutoYaST test suites for chained dependencies in YaST Maintenance Updates (rest of products) (Resolved)" href="https://progress.opensuse.org/issues/111743">#111743</a><br>
Testsuites <code>create_hdd_yast_maintenance_desktop</code> and <code>create_hdd_yast_maintenance_minimal</code> are performing an autoyast installation which is used by subsequent testsuites (eg <code>mau-extratests-yast2ui</code>, <code>mau_extratests_yast2_ncurses</code>, <code>mau_extratests_yast_cmd</code>).</p>
<p>However the <code>mru-iscsi</code> multimachine testsuites that have <code>create_hdd_yast_maintenance_desktop</code> as a dependency seem to bump into an issue where the Network of the resulting image is not configured, ending up with <a href="https://openqa.suse.de/tests/9742604#step/addon_products_via_SCC_yast2/25" class="external">this type of failure</a>.</p>
<a name="Scope"></a>
<h4 >Scope<a href="#Scope" class="wiki-anchor">¶</a></h4>
<p><a href="https://openqa.suse.de/tests/overview?arch=&flavor=&machine=&test=mru-iscsi_client_normal_auth_backstore_lvm_dev&test=mru-iscsi_server_normal_auth_backstore_lvm_dev&test=mru-iscsi_client_normal_auth_backstore_fileio_dev&test=mru-iscsi_server_normal_auth_backstore_fileio_dev&test=mru-iscsi_client_normal_auth_backstore_hdd_dev&test=mru-iscsi_server_normal_auth_backstore_hdd_dev&modules=&module_re=&distri=sle&build=20221016-1&groupid=446#" class="external">mru-iscsi_{client,server}_normal_auth_backstore_{lvm,fileio,hdd}</a> for MU YaST 12-SP4 to 15-SP2 Job groups.<br>
arch: x86_64</p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: The mru-iscsi_{client,server}<u>normal_auth_backstore</u>{lvm,fileio,hdd} testsuites succeed on the Registration step.<br>
<strong>AC2</strong>: The mru-iscsi_{client,server}<u>normal_auth_backstore</u>{lvm,fileio,hdd} are removed from the development group, and their equivalent testsuites in the YaST MU Job Groups now have a dependency on the <code>create_hdd_yast_maintenance_desktop</code> testsuite.</p>
<a name="Suggestions"></a>
<h4 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h4>
<ul>
<li>This is most probably an AutoYaST profile related issue. The <code>mru-iscsi_{client,server}_normal_auth_backstore_{lvm,fileio,hdd}</code> seem to run fine for <a href="https://openqa.suse.de/tests/overview?distri=sle&version=15-SP3&build=20221016-1&groupid=421" class="external">15-SP3</a> and <a href="https://openqa.suse.de/tests/overview?distri=sle&version=15-SP4&build=20221016-1&groupid=421" class="external">15-SP4</a>, maybe it is worth observing how network configuration is done on these autoyast installation <code>create_hdd_yast_maintenance_desktop</code> jobs.</li>
</ul>
qe-yam - action #116131 (Rejected): Ensure Boot from Hard Disk is selected in grub, migrationhttps://progress.opensuse.org/issues/1161312022-09-01T15:38:54Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p><a href="https://openqa.suse.de/tests/9427729#step/grub_test/3" class="external">Migration from 12SP5 fails</a> because the entry <code>Boot from Hard Disk</code> is not selected in grub menu of the migrated system.</p>
<a name="Scope"></a>
<h4 >Scope<a href="#Scope" class="wiki-anchor">¶</a></h4>
<p>testsuite <a href="https://openqa.suse.de/tests/9427729#step/grub_test/3" class="external">sle-15-SP5-Migration-from-SLE12-SPx-x86_64-Build19.1-autoupgrade_sles12sp5_pscc_lp_def_full</a></p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: Ensure <code>Boot from Hard Disk</code> is selected in grub menu</p>
<a name="Suggestions"></a>
<h4 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h4>
<p>It seems that the input that selects the entry is not registered, but also that the grub timeout is too big compared to the needle timeout. Maybe it is worth investigating if this is unexpected behavior/bug</p>
qe-yam - action #116128 (Rejected): Rectify unsupported configuration in bootloader settings when...https://progress.opensuse.org/issues/1161282022-09-01T14:20:22Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>When migrating form 15sp4 hpc to 15sp5, the test encounters an unsupported bootloader configuration (unkown udev device), as seen <a href="https://openqa.suse.de/tests/9426332#step/start_install/2" class="external">here</a>. The issue is likely caused by an earlier configuration which would need to be mitigated.</p>
<a name="Scope"></a>
<h4 >Scope<a href="#Scope" class="wiki-anchor">¶</a></h4>
<p>Migration: HPC <a href="https://openqa.suse.de/tests/9426332#step/start_install/2" class="external">https://openqa.suse.de/tests/9426332#step/start_install/2</a> </p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: Adjust the test so that bootloader configuration is written to an existing disk.</p>
qe-yam - action #114730 (Rejected): [Timebox: 16h] Investigate which job results block approval f...https://progress.opensuse.org/issues/1147302022-07-27T12:58:27Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>When a job from our <a href="https://openqa.suse.de/group_overview/421" class="external">aggregate maintenance updates</a> fails, it blocks all the related maintenance updates from approval by the members of the <code>qam-openqa</code> group (maintenance openqa reviewers).<br>
The questions arises, what job states, other than <code>failed</code>, result in maintenance updates being blocked?<br>
Does for instance an <a href="https://openqa.suse.de/tests/9222738" class="external">incomplete</a> job or a <a href="https://openqa.suse.de/tests/9222743#" class="external">cancelled</a> job also block their related updates? <br>
Knowing this will help us better organize the required actions in the context of our Maintenance Update Review process. </p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong> Figure out what job results block update approval for qam-openqa</p>
<a name="Suggestions"></a>
<h4 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h4>
<p>The maintenance openqa reviewer use this dashboard <a href="http://dashboard.qam.suse.de/blocked" class="external">http://dashboard.qam.suse.de/blocked</a> to have visibility on the blocked updates.<br>
The maintainer of this dashboard (maybe someone from qe-tools?) should be able to help.<br>
Also we could check what happen when some arch doesn't run any job.</p>
qe-yam - action #109452 (Rejected): [Timebox: 8h] Investigate script_output failure in validate_a...https://progress.opensuse.org/issues/1094522022-04-04T13:20:24Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h3 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h3>
<p>Modules <code>validate_addon_extension_repo_http</code> and <code>validate_addon_extension_repo_ftp</code> fail sporadically in <code>validate_repo_properties()</code>.<br>
The failure occurs during inside <code>script_ouput</code> stage of <code>parse_repo_data()</code> and can be seen <a href="https://openqa.suse.de/tests/8463394#step/validate_addon_extension_repo_ftp/5" class="external">here</a>, <strong>but</strong> it is most likely not related to the bsc#1193214 failure (seen <a href="https://openqa.suse.de/tests/8463394#step/validate_addon_extension_repo_http/8" class="external">here</a>).</p>
<a name="Acceptance-criteria"></a>
<h3 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h3>
<p><strong>AC1</strong>: Investigate the failure in <a href="https://github.com/os-autoinst/os-autoinst/blob/master/distribution.pm#L232" class="external">script_output</a>.<br>
<strong>AC2</strong>: File a new progress issue (or a product bug) depending on the findings.</p>
<a name="Further-Information"></a>
<h2 >Further Information<a href="#Further-Information" class="wiki-anchor">¶</a></h2>
<p>It is a bit weird that in <a href="https://openqa.suse.de/tests/8463394/logfile?filename=autoinst-log.txt" class="external">autoinst-log.txt</a> we see <code>command 'curl -f -v http://10.0.2.2:20063/k2w1yCaJzocsF6Je/current_script > /tmp/scriptC_1nj.sh' failed at /usr/lib/os-autoinst/testapi.pm line 953.</code> but the command is different in the <a href="https://openqa.suse.de/tests/8463394/#step/validate_addon_extension_repo_ftp/5" class="external">console before the failure</a></p>
qe-yam - action #108803 (Rejected): Fix key navigation in yast2 snapper ncurses testhttps://progress.opensuse.org/issues/1088032022-03-23T18:56:09Zgeorggkioulis@suse.com
<a name="Motivation"></a>
<h3 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h3>
<p>Module <code>yast2_snapper_ncurses.pm</code> fails because the snapshot is never highlighted, as can be seen here: <a href="https://openqa.suse.de/tests/8368512#step/yast2_snapper_ncurses/77" class="external">https://openqa.suse.de/tests/8368512#step/yast2_snapper_ncurses/77</a><br>
This is due to <code>send_key_until_needlematch</code>'s key <code>pgdn</code> no navigating as intended.</p>
<a name="Acceptance-criteria"></a>
<h3 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h3>
<p><strong>AC1</strong>: Manually check which key to highlight the snapshot with. If <code>pgdn</code> no longer works, investigate whether this is intended.<br>
<strong>AC2</strong>: Adjust <code>send_key_until_needlematch</code> of <code>sub y2snapper_new_snapshot</code> so that the newly created snapshot is highlighted.</p>
qe-yam - action #105978 (Rejected): Investigate kex_exchange_identification error in s390x-kvmhttps://progress.opensuse.org/issues/1059782022-02-04T17:24:22Zgeorggkioulis@suse.com
<p>Testsuites <a href="https://openqa.suse.de/tests/8104383#step/prepare_test_data/7" class="external">transactional_server_snapper</a> and <a href="https://openqa.suse.de/tests/8104382#step/prepare_test_data/6" class="external">transactional_server_helper</a> fail in <code>prepare_test_data</code> module.</p>
<p>It seems that the ssh connection of the SUT to the worker (grenache-1) is interrupted due to <code>kex_exchange_identification error</code>.</p>
<p><strong>Note:</strong> This ticket is probably not primarily for our squad, but given that it is a testsuite blocker and it would be good to see it addressed relatively quickly, I suggest that we investigate ourselves as a starting point.</p>
qe-yam - action #105975 (Rejected): Investigate disk Input/output error on ppc64le-hmchttps://progress.opensuse.org/issues/1059752022-02-04T17:05:08Zgeorggkioulis@suse.com
<p>The testsuite <a href="https://openqa.suse.de/tests/latest?arch=ppc64le&distri=sle&flavor=Online&machine=ppc64le-hmc-single-disk&test=cryptlvm%2Bcancel_existing&version=15-SP4" class="external">cryptlvm+cancel_existing</a> fails for ppc64le-hmc in <code>bootloader_start</code> module.</p>
<p>The failure appears when creating the GPT partition table on the disk.</p>
<p>The same issue appears in <a href="https://openqa.suse.de/tests/8104886" class="external">RAID5</a>, but it is only visible through the video of the job run. <br>
The job times out during <code>Performing Installation</code> due to a popup window appearing (message is: <code>Creating GPT on /dev/sdd, Unexpected situation found in the system.</code>)</p>
<p>Investigation is needed to verify whether this is a ppc64le-hmc infrastructure issue or a product bug for creating the GPT table in this specific setup.</p>
qe-yam - action #105972 (Rejected): New version of nvme package causes nvme_checks module to failhttps://progress.opensuse.org/issues/1059722022-02-04T16:28:46Zgeorggkioulis@suse.com
<p>Since build 91.2 the nvme package has been bumped to version 2.0 (from 1.13).</p>
<p>This causes (among other things) some changes in the output of <code>nvme list</code> and <code>nvme list-ns /dev/nvme0</code>.</p>
<p>The <code>nvme_checks.pm</code> module fails when running <code>nvme list-ns /dev/$nvm_test_data->{nvm_char_device} | awk -F ':' '{print $2}'"</code>, because, in the new version, <code>nvme list-ns /dev/nvme0</code> outputs nothing, instead of <code>[ 0]:0x1</code>.</p>
<p>Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Online&machine=uefi&test=nvme&version=15-SP4" class="external">latest</a></p>
<p><strong>Suggestion:</strong> change the <code>nvme list-ns</code> command to verify the 0x1 namespace array</p>
qe-yam - action #103320 (Rejected): Create new test module for DASD disk filteringhttps://progress.opensuse.org/issues/1033202021-11-30T14:13:15Zgeorggkioulis@suse.com
<a name="Description"></a>
<h2 >Description<a href="#Description" class="wiki-anchor">¶</a></h2>
<p>In DASD Disk Management page (can be seen <a href="https://openqa.suse.de/tests/7125537#step/disk_activation/2" class="external">here</a>) there is the capability of filtering DASD disks by inputting a channel range in the minimum and maximum channel ID fields.</p>
<p>We can test this by using the functionality (<code>enter_maximum_channel</code>, <code>enter_minimum_channel</code>, <code>press_filter_button</code>) provided by <code>DASDDiskManagementPage.pm</code>.</p>
<a name="Acceptance-Criteria"></a>
<h2 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li>Create a test module that filters the shown DASD devices by a selected channel range and validate the output.</li>
<li>It is sufficient to include this test module in a single job's schedule that includes the <code>configure_dasd</code> test module, not all of them.</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>An easy implementation can be to have the same channel value for minimum and maximum channel. This will make validating the output easier, since the device table item list will contain only one item to be asserted.</li>
</ul>
qe-yam - action #101903 (Rejected): Investigate test failure in integration_serviceshttps://progress.opensuse.org/issues/1019032021-11-03T15:18:29Zgeorggkioulis@suse.com
<p>The <code>integration_services.pm</code> module fails at the <code>select_console 'root-console'</code> call.<br>
This fails because the System Under Test finds itself in the display manager screen.<br>
When fixed the test behavior should be similar to <a href="https://openqa.suse.de/tests/5785744#step/integration_services/2" class="external">the old runs</a>.</p>
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP4-Full-x86_64-select_modules_and_patterns+registration@svirt-hyperv-uefi fails in<br>
<a href="https://openqa.suse.de/tests/7591216/modules/integration_services/steps/5" class="external">integration_services</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Full Medium installation that covers the following cases:<br>
1. Additional modules enabled using SCC (Legacy, Development Tools,<br>
Web and Scripting, Containers, Desktop Applications);<br>
2. Yast patterns installed;<br>
3. System registration is skipped during installation;<br>
4. Installation is validated by successful boot and that YaST does not<br>
report any issues;<br>
5. Registration is performed on the installed system.</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/7200373" class="external">38.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=x86_64&distri=sle&flavor=Full&machine=svirt-hyperv-uefi&test=select_modules_and_patterns%2Bregistration&version=15-SP4" class="external">latest</a></p>
qe-yam - action #99603 (Rejected): svirt-xen-hvm jobs entering emergency mode in first boothttps://progress.opensuse.org/issues/996032021-10-01T09:59:42Zgeorggkioulis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP4-Online-x86_64-xfs@svirt-xen-hvm fails in<br>
<a href="https://openqa.suse.de/tests/7262467/modules/first_boot/steps/9" class="external">first_boot</a></p>
<p>also fails on <a href="https://openqa.suse.de/tests/7276616#step/first_boot/9" class="external">textmode</a> and <a href="https://openqa.suse.de/tests/7262464#step/first_boot/9" class="external">minimal+base_yast</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, QE Kernel</p>
<p>Installation test with explicit selection of "xfs" instead of default.</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/7262467" class="external">43.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/7218822" class="external">39.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-hvm&test=xfs&version=15-SP4" class="external">latest</a></p>
qe-yam - action #99600 (Rejected): Investigate System Role page not loadinghttps://progress.opensuse.org/issues/996002021-10-01T09:43:51Zgeorggkioulis@suse.com
<p>Until now, at the end of <code>addon_products_sle</code> module, once the next button is pressed using keyboard, the System Role page appears, as can be seen in the last screen of the <code>addon_products_sle</code> module <a href="https://openqa.suse.de/tests/7200374#step/addon_products_sle/60" class="external">on previous runs</a>.</p>
<p>In the new build however, the transition to the System Role page never happens resulting in a failing needle in the <code>system_role</code> module.</p>
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP4-Full-x86_64-select_modules_and_patterns+registration@svirt-hyperv2016 fails in<br>
<a href="https://openqa.suse.de/tests/7279621/modules/system_role/steps/2" class="external">system_role</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Full Medium installation that covers the following cases:<br>
1. Additional modules enabled using SCC (Legacy, Development Tools,<br>
Web and Scripting, Containers, Desktop Applications);<br>
2. Yast patterns installed;<br>
3. System registration is skipped during installation;<br>
4. Installation is validated by successful boot and that YaST does not<br>
report any issues;<br>
5. Registration is performed on the installed system.</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/7124547" class="external">36.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=x86_64&distri=sle&flavor=Full&machine=svirt-hyperv2016&test=select_modules_and_patterns%2Bregistration&version=15-SP4" class="external">latest</a></p>
qe-yam - action #99573 (Rejected): Investigate failure of LVM activationhttps://progress.opensuse.org/issues/995732021-09-30T15:36:18Zgeorggkioulis@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP4-Online-aarch64-activate_encrypted_volume+import_users@aarch64 fails in<br>
<a href="https://openqa.suse.de/tests/7274219/modules/skip_install_addons/steps/1" class="external">skip_install_addons</a></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/7269640" class="external">43.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/7217928" class="external">39.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=aarch64&distri=sle&flavor=Online&machine=aarch64&test=activate_encrypted_volume%2Bimport_users&version=15-SP4" class="external">latest</a></p>