openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842024-03-25T11:05:24ZopenSUSE Project Management Tool
Redmine qe-yam - action #157873 (New): Merge vars HDDVERSION,FROM_VERSION and ORIGIN_SYSTEM_VERSIONhttps://progress.opensuse.org/issues/1578732024-03-25T11:05:24Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Scope"></a>
<h1 >Scope<a href="#Scope" class="wiki-anchor">¶</a></h1>
<p>Currently we are using three different variables HDDVERSION,FROM_VERSION and ORIGIN_SYSTEM_VERSION to describe the same thing.<br>
We should decide on which of these to keep and replace other vars accordingly. This can be tricky as the vars are not only used in the yaml Job groups but in the openqa code as well.</p>
<a name="Acceptance-Criteria"></a>
<h1 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h1>
<ul>
<li>Discuss with the team or create poll to decide which name to keep (I would go with HDDVERSION)</li>
<li>Replace the rest of the var names with the name of choice</li>
<li>Modify openqa code accordingly for our tests and run VRs.</li>
<li>Notify other teams that might use the modified code so that they rename their vars in their job group settings</li>
</ul>
qe-yam - action #154726 (New): revert s390x temporary condition ones suseconnect-ng package is up...https://progress.opensuse.org/issues/1547262024-02-01T10:56:39Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>Some s390x migration tests that use suseconnect-ng while patch_sle, where failing due to PR: <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/18483" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/18483</a> as the latest changes for suseconnect-ng package were not included in s390x iso.</p>
<a name="Scope"></a>
<h4 >Scope<a href="#Scope" class="wiki-anchor">¶</a></h4>
<p>The temporary fix for this issue was implemented here: <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/18555#event-11664768890" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/18555#event-11664768890</a></p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<ul>
<li>Keep an eye on s390x tests:
offline_sles15sp4_pscc_basesys-srv-desk-phub_def_full<br>
offline_sles15sp4_pscc_basesys-srv-lp-contm-lgm-tsm-pcm-wsm_all_full<br>
offline_sles15sp4_pscc_basesys-srv-lp_def_full</li>
</ul>
<p>Once they fail due to license appearance, revert the temporary fix PR</p>
<a name="Additional-information"></a>
<h4 >Additional information<a href="#Additional-information" class="wiki-anchor">¶</a></h4>
<p>Relevant progress ticket: <a href="https://progress.opensuse.org/issues/154120" class="external">https://progress.opensuse.org/issues/154120</a></p>
qe-yam - action #154717 (Rejected): Adjust select_module_desktop to verify the existence of the m...https://progress.opensuse.org/issues/1547172024-02-01T09:54:50Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Scope"></a>
<h4 >Scope<a href="#Scope" class="wiki-anchor">¶</a></h4>
<p>The skip_registration test <a href="https://openqa.suse.de/tests/13400788#step/select_module_desktop/1" class="external">fails for 15SP3</a> because, according to the yui logs, the addon_repos widget seems to have appeared and the module proceeds to select item with value=Desktop+Applications+Module , but in reality the item is not loaded yet and this is causing the Yast error that we mistakenly regarded as a bug result ( see <a href="https://bugzilla.suse.com/show_bug.cgi?id=1219403" class="external">https://bugzilla.suse.com/show_bug.cgi?id=1219403</a> ). </p>
<p>yui logs:<br>
[2024-01-31T23:41:26.647742+01:00] [info] [pid:29717] skip_registration test module finished<br>
[2024-01-31T23:41:26.649364+01:00] [info] [pid:29717] select_module_desktop test module started<br>
[2024-01-31T23:41:26.649764+01:00] [debug] [pid:29717] Finding widget by url: <a href="http://localhost:39103/v1/widgets?id=addon_repos" class="external">http://localhost:39103/v1/widgets?id=addon_repos</a><br>
[2024-01-31T23:41:27.652241+01:00] [error] [pid:29717] Widget not found by url: <a href="http://localhost:39103/v1/widgets?id=addon_repos" class="external">http://localhost:39103/v1/widgets?id=addon_repos</a><br>
[2024-01-31T23:41:29.656276+01:00] [debug] [pid:29717] Finding widget by url: <a href="http://localhost:39103/v1/widgets?id=addon_repos" class="external">http://localhost:39103/v1/widgets?id=addon_repos</a><br>
[2024-01-31T23:41:30.660504+01:00] [debug] [pid:29717] Sending action to widget by url: <a href="http://localhost:39103/v1/widgets?action=check&id=addon_repos&value=Desktop+Applications+Module" class="external">http://localhost:39103/v1/widgets?action=check&id=addon_repos&value=Desktop+Applications+Module</a><br>
[2024-01-31T23:41:31.664662+01:00] [debug] [pid:29717] Finding widget by url: <a href="http://localhost:39103/v1/widgets?id=addon_repos" class="external">http://localhost:39103/v1/widgets?id=addon_repos</a><br>
[2024-01-31T23:41:32.667784+01:00] [error] [pid:29717] Widget not found by url: <a href="http://localhost:39103/v1/widgets?id=addon_repos" class="external">http://localhost:39103/v1/widgets?id=addon_repos</a><br>
[2024-01-31T23:41:34.672477+01:00] [error] [pid:29717] Widget not found by url: <a href="http://localhost:39103/v1/widgets?id=addon_repos" class="external">http://localhost:39103/v1/widgets?id=addon_repos</a><br>
[2024-01-31T23:41:36.675976+01:00] [error] [pid:29717] Widget not found by url: <a href="http://localhost:39103/v1/widgets?id=addon_repos" class="external">http://localhost:39103/v1/widgets?id=addon_repos</a><br>
[2024-01-31T23:41:38.678876+01:00] [error] [pid:29717] Widget not found by url: <a href="http://localhost:39103/v1/widgets?id=addon_repos" class="external">http://localhost:39103/v1/widgets?id=addon_repos</a><br>
[2024-01-31T23:41:40.681975+01:00] [error] [pid:29717] Widget not found by url: <a href="http://localhost:39103/v1/widgets?id=addon_repos" class="external">http://localhost:39103/v1/widgets?id=addon_repos</a><br>
[2024-01-31T23:41:42.685466+01:00] [error] [pid:29717] Widget not found by url: <a href="http://localhost:39103/v1/widgets?id=addon_repos" class="external">http://localhost:39103/v1/widgets?id=addon_repos</a></p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<ul>
<li>Adjust the test module, in order to avoid similar failures in the future.</li>
</ul>
<a name="Additional-information"></a>
<h4 >Additional information<a href="#Additional-information" class="wiki-anchor">¶</a></h4>
<p>The module is used in many test suites for 15-SP{3..6}.<br>
The test suite is now moved to development job group: <a href="https://openqa.suse.de/group_overview/446" class="external">https://openqa.suse.de/group_overview/446</a></p>
qe-yam - action #153113 (New): Create default settings for each product in Job groups yamlhttps://progress.opensuse.org/issues/1531132024-01-04T13:41:49Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>Currently, in the job groups yaml files, we have a lot of repetition, thus everytime we have to make some changes, we need to edit a lot of lines.<br>
This type of work, besides being tiresome is error prone.</p>
<p>We can create some defaults for every product that will be inherited by all the product tests. Example:</p>
<p>default_15sp4_config: &15sp4_config<br>
HDDVERSION: '15-SP4'<br>
SCC_REGCODE_LTSS: somecode</p>
<p>some_15sp4_test:<br>
settings:<br>
<<:*15sp4_config</p>
<p>We could also try to add a variable for ltss enablement in the default settings, so that we don't need to edit every test line when we want to add the addon. Example LTSS='ltss'/''<br>
SCC_ADDONS: 'serverapp,base,%LTSS%'</p>
qe-yam - action #152685 (New): Add typescript syntax check in Playwright repo CI/CDhttps://progress.opensuse.org/issues/1526852023-12-15T13:21:17Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>In <a href="https://github.com/jknphy/e2e-agama-playwright" class="external">Playwright repo</a> we have currently set the basis for CI/CD <a href="https://progress.opensuse.org/issues/134441" class="external">poo#134441</a> after merging: <a href="https://github.com/jknphy/e2e-agama-playwright/pull/30" class="external">https://github.com/jknphy/e2e-agama-playwright/pull/30</a><br>
Currently, the only check available is the typescript formatting, according to file tsfmt.json (complying with the default formatting by vscode). We should enhance the checks by verifying the typescript syntax. In case there is a toll that can verify both syntax and formatting, the typescript-formatter can be completely removed from the workflow.</p>
<p><strong><em>Acceptance Criteria</em></strong></p>
<ul>
<li>The CI in Playwright repo should check the typescript syntax for errors.</li>
<li>Create test actions to verify expected failure and success of the CI.</li>
</ul>
qe-yam - action #152683 (New): Add check for existence of imported files in Playwright repo CI/CDhttps://progress.opensuse.org/issues/1526832023-12-15T13:16:36Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>In <a href="https://github.com/jknphy/e2e-agama-playwright" class="external">Playwright repo</a> we have currently set the basis for CI/CD <a href="https://progress.opensuse.org/issues/134441" class="external">poo#134441</a> after merging: <a href="https://github.com/jknphy/e2e-agama-playwright/pull/30" class="external">https://github.com/jknphy/e2e-agama-playwright/pull/30</a><br>
Currently, the only check available is the typescript formatting, according to file tsfmt.json (complying with the default formatting by vscode). We should enhance the checks in the CI, by adding a step that will get the imported files (lib/actor/page etc) ignoring the "import { type Page } from '@playwright/test';" . It is recommended to create a script directory and place a script inside that will be called by the CI steps in .github/workflows/ci.yaml, instead of polluting the ci.yaml.</p>
<p><strong><em>Acceptance criteria</em></strong></p>
<ul>
<li>The CI should check if the imported files exist in the repo.</li>
<li>Create test actions to verify expected failure and success of the CI.</li>
</ul>
qe-yam - action #152296 (Rejected): Optimize gitlab repo CIhttps://progress.opensuse.org/issues/1522962023-12-08T12:16:45Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>Currently, our <a href="https://gitlab.suse.de/qe-yam/openqa-job-groups" class="external">gitlab repo</a> for openqa job groups is running on a simple checks CI. There is a yamllint check, a check for schedule and data files existence and then the openqa-cli command that checks if it can post the job group . We should make some tests to see if the above checks provide failure and pass when expected.</p>
<p>Note: A specific scenario to look into is if we want to move a test suite to another Job group, within the repo , one MR with two commits, will it pass or will it provide error that the test suite already exists in another Job group?</p>
<p><strong>Acceptance criteria</strong></p>
<ul>
<li>Run tests for different scenarios to verify the CI functionality</li>
<li>Open follow-up tickets for any improvements if needed.</li>
</ul>
qe-yam - action #133271 (New): Make agama auto installation test work for s390xhttps://progress.opensuse.org/issues/1332712023-07-25T08:10:51Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>Currently, we have 3 <a href="https://openqa.opensuse.org/tests/overview?distri=alp&version=agama-2.1-staging&build=1.42&groupid=96" class="external">agama auto installation tests</a> on o3 for x86_64 and aarch64. We could schedule the dolomite test for z/VM on o3 as well. <br>
The bootloader_s390 will need some modifications in order to enter the proper parameters in the parmfile. The details of auto installation on z/VM are described <a href="https://confluence.suse.com/pages/viewpage.action?pageId=1286701688" class="external">here</a>.<br>
The test schedule will have to include handle_reboot or reconnect_mgmt_console for the console reconnection. <br>
In the autoyast profile of <a href="https://openqa.opensuse.org/tests/latest?arch=s390x&distri=opensuse&flavor=DVD&machine=s390x-zVM-vswitch-l2&test=autoyast_zvm&version=Tumbleweed" class="external">autoyast_zvm</a> test suite, we have added the following script for successful reconnection:</p>
<pre><code> <scripts>
<!-- permit root login, password login and pubkeys login -->
<post-scripts config:type="list">
<script>
<filename>post-script.sh</filename>
<interpreter>shell</interpreter>
<location/>
<feedback config:type="boolean">false</feedback>
<source><![CDATA[
sshd_config_file="/etc/ssh/sshd_config.d/permit_root_login.conf"
echo -e "PermitRootLogin yes\nPubkeyAuthentication yes\nPasswordAuthentication yes" > $sshd_config_file
[ -d /root/.ssh ] || mkdir -p /root/.ssh; chmod 700 /root/.ssh
touch /root/.ssh/authorized_keys; chmod 600 /root/.ssh/authorized_keys
echo "##Authorized-Keys##" >> /root/.ssh/authorized_keys
]]>
</source>
</script>
</post-scripts>
</scripts>
</code></pre> qe-yam - action #132839 (New): Use Mojo race condition where applicable in future testshttps://progress.opensuse.org/issues/1328392023-07-17T07:51:48Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>After PR: <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/17150" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/17150</a><br>
for handling the java license popup during installation settings, it was noticed and commended here <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/17150#discussion_r1251875831" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/17150#discussion_r1251875831</a> <br>
that we can use race conditions. An available library for openqa workers, here: <a href="https://docs.mojolicious.org/Mojo/Promise" class="external">https://docs.mojolicious.org/Mojo/Promise</a><br>
We could start using this after we investigate the functionality and proper syntax. Ask for help, if needed, in slack channel #discuss-perl</p>
<p><strong>Acceptance criteria</strong></p>
<ul>
<li>Research how we can use it in our testing code, make an example by refactoring existing code.</li>
<li>Make a demo for sharing the knowledge.</li>
</ul>
qe-yam - action #91677 (Rejected): [sporadic] test fails in validate_fs_tablehttps://progress.opensuse.org/issues/916772021-04-24T19:31:25Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>We are expecting both filesystems for root and home to be xfs as instructed in the test_data, but quite frequently, btrfs is selected, thus filesystem validation fails. We should stabilize the test to select xfs on every run.</p>
<p>openQA test in scenario sle-15-SP3-Online-s390x-xfs@s390x-kvm-sle12 fails in<br>
<a href="https://openqa.suse.de/tests/5846924/modules/validate_fs_table/steps/15" class="external">validate_fs_table</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>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/5840675" class="external">176.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/5825916" class="external">174.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=s390x&distri=sle&flavor=Online&machine=s390x-kvm-sle12&test=xfs&version=15-SP3" class="external">latest</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 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>
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>