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 #153964 (In Progress): [Research: 24h] Check how to not need to set YUI_REST_API=...https://progress.opensuse.org/issues/1539642024-01-19T13:03:24Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>Currently, we are distinguishing the libuyi test from the non-libyui tests by using the variable YUI_REST_API.<br>
It would be more convenient to create a different way, based on the version of the os (=+sles15-sp3). <br>
The challenge would be to avoid using multiple conditions in the os-autoinst-opensuse-distro repo.<br>
This settings is tightly coupled with the yaml schedule, so it might require some research what are all the points in the code affected.</p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong>: Find strategy to avoid setting YUI_REST_API at all.</p>
qe-yam - action #153154 (New): Replace different arch yaml schedules with one for continuous migr...https://progress.opensuse.org/issues/1531542024-01-05T10:36:25Zsyrianidou_sofiasofia.syrianidou@suse.com
<p>Test offline_sle12sp5_sles15sp4_sles15sp_latest_*_ph0 from migration_miscellaneous job group has a dedicated yaml schedule for each arch. The schedules are quite similar and could be replaced by one, if properly written. The differences are mainly the bootloader (bootloader_start can replace all), isosize module for aarch64 and ppc64le and for s390x reconnect_mgmt_console module instead of grub_test module. Files:<br>
schedule/migration/migration_offline_scc_deregistration_x86_64.yaml <br>
schedule/migration/migration_offline_scc_deregistration_s390x.yaml<br>
schedule/migration/migration_offline_scc_deregistration_aarch64.yaml<br>
schedule/migration/migration_offline_scc_deregistration_ppc64le.yaml </p>
<p><strong>Acceptance criteria</strong></p>
<ul>
<li>Unify the above files to one</li>
<li>Research which archs should include isosize module (preferably all or none)</li>
<li>Edit the Job group yaml to point to the new schedule.</li>
</ul>
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 #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 #131483 (Resolved): agama auto tests don't die on failurehttps://progress.opensuse.org/issues/1314832023-06-27T13:53:39Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>The agama auto tests for agama-live.x86_64-2.1.0-ALP-Build2.46.iso currently fail because on product selection, tumbleweed is missing. The issue is that the auto module failure should stop the test, but the rest of the modules run. In autoinst-log.txt :</p>
<pre><code>......
[2023-06-27T09:37:28.918297+02:00] [info] [pid:31049] ::: basetest::runtest: # Test died: no candidate needle with tag(s) 'agama-main-page' matched
[2023-06-27T09:37:28.923163+02:00] [debug] [pid:31049] lib/yam/agama/agama_base.pm:23 called testapi::select_console
[2023-06-27T09:37:28.923289+02:00] [debug] [pid:31049] <<< testapi::select_console(testapi_console="root-console")
[2023-06-27T09:37:29.337002+02:00] [debug] [pid:31049] activate_console, console: root-console, type: console
[2023-06-27T09:37:29.337589+02:00] [debug] [pid:31049] lib/yam/agama/agama_base.pm:23 called testapi::select_console -> lib/susedistribution.pm:826 called testapi::wait_still_screen
...
</code></pre>
<p>We should check if the lib/yam/agama/agama_base.pm post_fail_hook is properly written and what causes this "proceed on failure" phenomenon. <br>
Tips: </p>
<ul>
<li>Try to run the test with _SKIP_POST_FAIL_HOOKS=1 to see if this is the issue.</li>
<li>If there is no aparent reason add a flag for the test to die on failure (DIE_ON_FAIL=1)</li>
</ul>
<p>More auto tests in <a href="https://openqa.opensuse.org/group_overview/96" class="external">Development agama job group</a></p>
<p>openQA test in scenario alp-agama-2.1-staging-agama-live-default-x86_64-agama_auto_tumbleweed@64bit-2G fails in<br>
<a href="https://openqa.opensuse.org/tests/3384257/modules/auto/steps/7" class="external">auto</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Auto installation of Tumbleweed on ALP Agama using .sh format</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/3367657" class="external">2.26</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.opensuse.org/tests/latest?arch=x86_64&distri=alp&flavor=agama-live-default&machine=64bit-2G&test=agama_auto_tumbleweed&version=agama-2.1-staging" class="external">latest</a></p>
qe-yam - action #129460 (New): Create sync scripts for SCC/SMT/RMT servershttps://progress.opensuse.org/issues/1294602023-05-17T09:35:36Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Motivation"></a>
<h4 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h4>
<p>When we have to do manual testing for milestone builds, there is a procedure that can be automated, described <a href="https://confluence.suse.com/pages/viewpage.action?pageId=1118405556" class="external">here</a><br>
We should try to create scripts in order to make the procedure much faster and also include some clean up in the beginning on each script, in order to avoid running out of space on the SMT/RMT servers due to hoarding of old updates/products.</p>
<a name="Acceptance-criteria"></a>
<h4 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h4>
<p><strong>AC1</strong> : find out which products are necessary for SMT and RMT servers<br>
<strong>AC2</strong> : find ways to efficiently clean up the old data e.g. smt-mirror --cleanup will remove majority of data from /srv/www/htdocs/SUSE/ but will leave the old unused product directories there, so on next cleanup, we need to wait for these directories to be scanned as well. <br>
<strong>AC3</strong> : Create scripts with sufficient comments/documentation for easy maintenance, that will automate the SMT/RMT maintenance.<br>
<strong>AC4</strong> : Update confluence page</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 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 #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 #67120 (Resolved): [functional][y]test fails in zypper_ref while trying to ...https://progress.opensuse.org/issues/671202020-05-21T12:50:28Zsyrianidou_sofiasofia.syrianidou@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>Related to this change: <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/10288">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/10288</a></p>
<p>openQA test in scenario sle-15-SP2-Online-ppc64le-lvm@ppc64le fails in<br>
<a href="https://openqa.suse.de/tests/4264225/modules/zypper_ref/steps/2" class="external">zypper_ref</a></p>
<p><a href="https://openqa.suse.de/tests/4247142" class="external">Last good</a> was using root-console, but after <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/commit/4e9cca349646152944d403c221b8322ac6842a72#diff-aff3537aeb29a78d33dc1fc514ab716dR26">https://github.com/os-autoinst/os-autoinst-distri-opensuse/commit/4e9cca349646152944d403c221b8322ac6842a72#diff-aff3537aeb29a78d33dc1fc514ab716dR26</a><br>
the module is attempting to use virtio console due to <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/lib/opensusebasetest.pm#L1098">https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/lib/opensusebasetest.pm#L1098</a> , but fails. Even though the commit looks like it's 22 days old and last good already had VIRTIO_CONSOLE=1, it didn't use the root-virtio-console. </p>
<p>Last good autoinst.log:</p>
<pre><code>[2020-05-16T11:57:49.052 CEST] [debug] ||| starting zypper_ref tests/console/zypper_ref.pm
[2020-05-16T11:57:49.053 CEST] [debug] tests/console/zypper_ref.pm:25 called testapi::select_console
[2020-05-16T11:57:49.053 CEST] [debug] <<< testapi::select_console(testapi_console="root-console")
[2020-05-16T11:57:49.859 CEST] [debug] tests/console/zypper_ref.pm:25 called testapi::select_console -> lib/susedistribution.pm:883 called testapi::assert_screen
[2020-05-16T11:57:49.859 CEST] [debug] <<< testapi::assert_screen(mustmatch="root-console", timeout=30, no_wait=1)
[2020-05-16T11:57:50.025 CEST] [debug] >>> testapi::_handle_found_needle: found root-console-top-20200304, similarity 1.00 @ 96/2
[2020-05-16T11:57:50.025 CEST] [debug] tests/console/zypper_ref.pm:26 called utils::zypper_enable_install_dvd -> lib/utils.pm:554 called utils::zypper_call -> lib/utils.pm:509 called testapi::script_run
</code></pre>
<p>Failed tests:</p>
<pre><code>�[0m�[1;34m[2020-05-21T05:14:21.047 CEST] [debug] ||| starting zypper_ref tests/console/zypper_ref.pm
�[0m[2020-05-21T05:14:21.047 CEST] [debug] tests/console/zypper_ref.pm:26 called opensusebasetest::select_serial_terminal -> lib/opensusebasetest.pm:1115 called testapi::select_console
[2020-05-21T05:14:21.047 CEST] [debug] <<< testapi::select_console(testapi_console="root-virtio-terminal")
[2020-05-21T05:14:21.048 CEST] [debug] <<< consoles::virtio_terminal::open_pipe(pipe_prefix="/var/lib/openqa/pool/8/virtio_console")
�[33m[2020-05-21T05:14:21.049 CEST] [info] ::: consoles::virtio_terminal::open_pipe: Set PIPE_SZ from 1048576 to 1048576
�[0m�[33m[2020-05-21T05:14:21.049 CEST] [info] ::: consoles::virtio_terminal::open_pipe: Set PIPE_SZ from 1048576 to 1048576
�[0m�[37m[2020-05-21T05:14:21.049 CEST] [debug] activate_console, console: root-virtio-terminal, type: virtio-terminal
�[0m[2020-05-21T05:14:21.050 CEST] [debug] tests/console/zypper_ref.pm:26 called opensusebasetest::select_serial_terminal -> lib/opensusebasetest.pm:1115 called testapi::select_console -> lib/susedistribution.pm:746 called serial_terminal::login -> lib/serial_terminal.pm:82 called bmwqemu::log_call
[2020-05-21T05:14:21.050 CEST] [debug] <<< serial_terminal::login()
[2020-05-21T05:14:21.050 CEST] [debug] tests/console/zypper_ref.pm:26 called opensusebasetest::select_serial_terminal -> lib/opensusebasetest.pm:1115 called testapi::select_console -> lib/susedistribution.pm:746 called serial_terminal::login -> lib/serial_terminal.pm:87 called testapi::wait_serial
[2020-05-21T05:14:21.050 CEST] [debug] <<< testapi::wait_serial(timeout=5, record_output=undef, expect_not_found=0, quiet=1, buffer_size=undef, regexp=qr/login:\s*$/ui, no_regex=0)
[2020-05-21T05:14:21.050 CEST] [debug] <<< consoles::serial_screen::read_until(quiet=1, expect_not_found=0, buffer_size=undef, pattern="(?^ui:login:\\s*\$)", timeout=5, json_cmd_token="sEJFMwpt", cmd="backend_wait_serial", no_regex=0, regexp="(?^ui:login:\\s*\$)", record_output=undef)
�[32m[2020-05-21T05:14:26.056 CEST] [debug] >>> testapi::wait_serial: (?^ui:login:\s*$): fail
�[0m[2020-05-21T05:14:26.056 CEST] [debug] tests/console/zypper_ref.pm:26 called opensusebasetest::select_serial_terminal -> lib/opensusebasetest.pm:1115 called testapi::select_console -> lib/susedistribution.pm:746 called serial_terminal::login -> lib/serial_terminal.pm:90 called testapi::type_string
[2020-05-21T05:14:26.056 CEST] [debug] <<< testapi::type_string(text="\n")
[2020-05-21T05:14:26.057 CEST] [debug] <<< consoles::serial_screen::type_string(cmd="backend_type_string", text="\n", json_cmd_token="CJjINXgN")
[2020-05-21T05:14:26.057 CEST] [debug] tests/console/zypper_ref.pm:26 called opensusebasetest::select_serial_terminal -> lib/opensusebasetest.pm:1115 called testapi::select_console -> lib/susedistribution.pm:746 called serial_terminal::login -> lib/serial_terminal.pm:91 called testapi::wait_serial
[2020-05-21T05:14:26.057 CEST] [debug] <<< testapi::wait_serial(regexp=qr/login:\s*$/ui, buffer_size=undef, no_regex=0, quiet=undef, expect_not_found=0, record_output=undef, timeout=90)
[2020-05-21T05:14:26.058 CEST] [debug] <<< consoles::serial_screen::read_until(pattern="(?^ui:login:\\s*\$)", timeout=90, json_cmd_token="zVPhpmAp", quiet=undef, expect_not_found=0, buffer_size=undef, record_output=undef, regexp="(?^ui:login:\\s*\$)", cmd="backend_wait_serial", no_regex=0)
�[32m[2020-05-21T05:15:56.106 CEST] [debug] >>> testapi::wait_serial: (?^ui:login:\s*$): fail
�[0m�[33m[2020-05-21T05:15:56.106 CEST] [info] ::: basetest::runtest: # Test died: Failed to wait for login prompt at /var/lib/openqa/cache/openqa.suse.de/tests/sle/lib/serial_terminal.pm line 91.
</code></pre>
<p>Further investigation is needed and possibly follow up ticket with tools' team.</p>
<p>Fails since (at least) Build <a href="https://openqa.suse.de/tests/4261497" class="external">197.1</a></p>
<p>Last good: <a href="https://openqa.suse.de/tests/4247142" class="external">195.1</a> (or more recent)</p>