https://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842019-02-26T16:10:31ZopenSUSE Project Management ToolopenQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=1932982019-02-26T16:10:31Zokurzokurz@suse.com
<ul></ul><pre><code>[26/02/2019 15:45:16] <SergioAtSUSE> okurz, then here. There is already a built Tumbleweed IDO for s390x than can be installed on a nested ZVM/KVM. We want to start performing tests on O3. We need to have the assets synced there. Do you have access to the script that syncs Tumbleweed?
[26/02/2019 15:45:22] <SergioAtSUSE> ISO*
[26/02/2019 15:46:18] <okurz> SergioAtSUSE: every SUSE employee has access. And there are already tests enabled for s390x. You don't need to "start" anything but just make sure the media are released to the according :ToTest repo
[26/02/2019 15:47:17] <okurz> SergioAtSUSE: https://gitlab.suse.de/openqa/scripts/blob/master/rsync_opensuse.pm#L72
[26/02/2019 15:49:29] <okurz> SergioAtSUSE: you can compare https://build.opensuse.org/package/show/openSUSE:Factory/000product with https://build.opensuse.org/package/show/openSUSE:Factory:zSystems:ToTest/000product
[26/02/2019 15:50:52] <okurz> SergioAtSUSE: let me check the current sync status on o3
[26/02/2019 15:56:01] <okurz> SergioAtSUSE: hm, actually seems like the assets are more or less fine but "ERROR: destination must be a directory when copying more than 1 file"
[26/02/2019 15:56:49] <SergioAtSUSE> okurz, where have you got that error?
[26/02/2019 15:57:03] <okurz> SergioAtSUSE: from o3
[26/02/2019 16:01:27] <SergioAtSUSE> okurz, could you create the missing directory on O3?
[26/02/2019 16:52:25] <okurz> DimStar: maybe you can crosscheck nevertheless. rsync://openqa@obs-backend.publish.opensuse.org/opensuse-internal/build//openSUSE:Factory:zSystems:ToTest/images//local/*product:openSUSE-ftp-ftp-s390x/openSUSE-*-s390x-Media1/media.1/media should be right to read out build information, right?
[26/02/2019 16:54:51] <okurz> yes, that could help
[26/02/2019 16:57:08] <DimStar> okurz: cleaned; let's give OBS a couple minutes then retry.. maybe that's already all we need
[26/02/2019 17:02:56] <okurz> DimStar: seems like that helped already, sync started
</code></pre> openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=1933042019-02-26T16:10:40Zokurzokurz@suse.com
<ul><li><strong>Related to</strong> <i><a class="issue tracker-4 status-1 priority-3 priority-lowest" href="/issues/46349">action #46349</a>: [s390x] Add qemu backend support</i> added</li></ul> openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=1933072019-02-26T16:11:00Zokurzokurz@suse.com
<ul></ul><p>currently syncing on o3</p>
openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=1933222019-02-26T16:53:44Zokurzokurz@suse.com
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul><p>successfully synced. <a href="https://openqa.opensuse.org/tests/863522/file/autoinst-log.txt" class="external">https://openqa.opensuse.org/tests/863522/file/autoinst-log.txt</a> shows missing dependencies on the worker "imagetester".</p>
<pre><code>imagetester:~ # transactional-update pkg install icewm x3270 xterm-console && reboot
</code></pre> openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=1933582019-02-26T17:14:37Zokurzokurz@suse.com
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Workable</i></li><li><strong>Assignee</strong> deleted (<del><i>okurz</i></del>)</li></ul><p><a href="https://openqa.opensuse.org/tests/863533/file/autoinst-log.txt" class="external">https://openqa.opensuse.org/tests/863533/file/autoinst-log.txt</a> shows failures, e.g. "IceWM: Warning: Failed to load theme default/default.theme: Permission denied" . I guess the way we used for the SLE workers is to have apparmor disabled on the specific worker machines.</p>
<p>I suggest to crosscheck with coolo</p>
openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=1935802019-02-27T10:30:21ZSLindoMansillaslindomansilla@suse.com
<ul></ul><p>coolo is ok to deactivate apparmor if there is no other service running on that machine (IT policy for company public services).</p>
<ul>
<li><strong>imagetester</strong> is a worker for x86_64 and it is not possible to disable apparmor.</li>
<li>remote-backend workers ssh into the wild, which cannot be properly confined in apparmor</li>
</ul>
<p>Proposed solution, we need to find a dedicated machine for remote-backend workers for openqa.opensuse.org.</p>
openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=1936612019-02-27T12:28:49Zokurzokurz@suse.com
<ul></ul><p>SLindoMansilla wrote:</p>
<blockquote>
<ul>
<li><strong>imagetester</strong> is a worker for x86_64 and it is not possible to disable apparmor.</li>
</ul>
</blockquote>
<p>why should it be not possible?</p>
openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=1937512019-02-27T16:27:54ZSLindoMansillaslindomansilla@suse.com
<ul></ul><p>Trying to setup a Raspberry Pi as worker for svirt. (with the intention to put it on the O3 network if the experiment works)</p>
openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=1956532019-03-05T14:12:29ZSLindoMansillaslindomansilla@suse.com
<ul><li><strong>Assignee</strong> set to <i>SLindoMansilla</i></li></ul><a name="Possible-solutions-for-a-dedicated-openQA-worker-for-svirt-backends"></a>
<h2 >Possible solutions for a dedicated openQA-worker for svirt backends<a href="#Possible-solutions-for-a-dedicated-openQA-worker-for-svirt-backends" class="wiki-anchor">¶</a></h2>
<p>Glossary:</p>
<ul>
<li><strong>O3</strong>: openqa.opensuse.org</li>
<li><strong>dedicated openQA worker</strong>: a virtual or physical machine with AppArmor disabled, the package openQA-worker installed and offering only this service.</li>
</ul>
<a name="Linux-container"></a>
<h4 >Linux container<a href="#Linux-container" class="wiki-anchor">¶</a></h4>
<p>Running a dedicated openQA worker in a Linux container is not doable due to apparmor also being applied on such processes (see <a href="https://cloud.google.com/container-optimized-os/docs/how-to/secure-apparmor" class="external">https://cloud.google.com/container-optimized-os/docs/how-to/secure-apparmor</a>). It would require an AppArmor rule in the profile for it. So, using a container is not an option.</p>
<a name="Virtual-machine-in-imagetester"></a>
<h4 >Virtual machine in imagetester<a href="#Virtual-machine-in-imagetester" class="wiki-anchor">¶</a></h4>
<p>imagetester is a machine serving openQA workers on <strong>O3</strong> (see <a href="https://openqa.opensuse.org/admin/workers/44" class="external">https://openqa.opensuse.org/admin/workers/44</a>). A virtual machine running there could be used as a <strong>dedicated openQA worker</strong>.<br>
We need a confirmation if IT policies accept it.</p>
<a name="Raspberry-Pi-3-B"></a>
<h4 >Raspberry Pi 3 B+<a href="#Raspberry-Pi-3-B" class="wiki-anchor">¶</a></h4>
<p>This cost-effective micro computer could be used as a <strong>dedicated openQA worker</strong>.<br>
At least the following packages are necessary:</p>
<ul>
<li>x11-vnc</li>
<li>icewm</li>
<li>xterm-terminal</li>
<li>x3270</li>
</ul>
<p>We need a confirmation if IT policies accept it.</p>
openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=1969552019-03-08T07:06:01ZSLindoMansillaslindomansilla@suse.com
<ul></ul><p>I was able to set up a Raspberry Pi 3 B+ as an openQA-worker for remote z/VM SUT's host.</p>
<p>Internal links:</p>
<ul>
<li>Successful SLE15-SP1 installation test: <a href="http://openqa.slindomansilla-vm.qa.suse.de/tests/1240" class="external">http://openqa.slindomansilla-vm.qa.suse.de/tests/1240</a></li>
<li>Request for adding the Raspberry Pi inside the O3 workers network is issued: <a href="https://infra.nue.suse.com/SelfService/Display.html?id=132506" class="external">https://infra.nue.suse.com/SelfService/Display.html?id=132506</a></li>
<li>In the meantime, trying to get the openSUSE Tumbleweed installation working: <a href="http://openqa.slindomansilla-vm.qa.suse.de/tests/1241" class="external">http://openqa.slindomansilla-vm.qa.suse.de/tests/1241</a></li>
</ul>
openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=2029852019-03-28T13:38:57ZSLindoMansillaslindomansilla@suse.com
<ul></ul><p>After analyzing the situation with R&D admins, the server room that is on the backend for openqa.opensuse.org has a strict policy about only allowing certified machines.<br>
<strong>Raspberry Pi is not a valid machine.</strong></p>
<p>About getting a certified machine for that server room:<br>
After talking to the openSUSE chairman, the existing machines are donated to openSUSE by SUSE, so, I will ask my department if we have the budget for that.</p>
openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=2032012019-03-29T09:08:29ZSLindoMansillaslindomansilla@suse.com
<ul><li><strong>Related to</strong> <i><a class="issue tracker-4 status-6 priority-4 priority-default closed" href="/issues/46919">action #46919</a>: [functional][u][svirt][sporadic] auto_review:"IO::Socket::INET: connect: Connection timed out"</i> added</li></ul> openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=2032132019-03-29T09:12:19ZSLindoMansillaslindomansilla@suse.com
<ul><li><strong>Related to</strong> deleted (<i><a class="issue tracker-4 status-6 priority-4 priority-default closed" href="/issues/46919">action #46919</a>: [functional][u][svirt][sporadic] auto_review:"IO::Socket::INET: connect: Connection timed out"</i>)</li></ul> openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=2032642019-03-29T09:56:25ZSLindoMansillaslindomansilla@suse.com
<ul></ul><p>Machine requirement from R&D admins for server room 1: "serverlike shape, so 19" size 1 or 2 HE 1-2 powerplugs and normally a BMC port"</p>
<p>azouhr suggested this machine: <a href="https://www.ebay.de/itm/Supermicro-SuperServer-502-200-X7SLA-H-Intel-Atom-330-1-60GHz-2GB-RAM-250G-HDD/223216622388?hash=item33f8bf5b34:g:MwMAAOSwa81aEtG9" class="external">https://www.ebay.de/itm/Supermicro-SuperServer-502-200-X7SLA-H-Intel-Atom-330-1-60GHz-2GB-RAM-250G-HDD/223216622388?hash=item33f8bf5b34:g:MwMAAOSwa81aEtG9</a></p>
<p>R&D admins told me that such a machine would be valid.</p>
<p>Waiting for feedback from my department.</p>
openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=2032882019-03-29T10:28:18ZSLindoMansillaslindomansilla@suse.com
<ul></ul><p>For several reasons, it is not allowed that the company buys hardware from ebay.</p>
<p>In this egg-chicken situation, that means that I need to adapt the backend to work with AppArmor enabled before enabling openSUSE tests on s390x.<br>
For this, I need to be provided with a z/VM user that I can use for this purpose. Waiting for feedback from Z system admins.</p>
openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=2033302019-03-29T13:29:24ZSLindoMansillaslindomansilla@suse.com
<ul><li><strong>Status</strong> changed from <i>Workable</i> to <i>Blocked</i></li></ul><p>Blocked by: <a class="issue tracker-4 status-6 priority-3 priority-lowest closed" title="action: [functional][u] Make the svirt backend work with AppArmor enabled and under company policies (Rejected)" href="https://progress.opensuse.org/issues/49820">#49820</a></p>
openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=2033362019-03-29T13:29:41ZSLindoMansillaslindomansilla@suse.com
<ul><li><strong>Blocked by</strong> <i><a class="issue tracker-4 status-6 priority-3 priority-lowest closed" href="/issues/49820">action #49820</a>: [functional][u] Make the svirt backend work with AppArmor enabled and under company policies</i> added</li></ul> openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=2414122019-09-04T16:39:53ZSLindoMansillaslindomansilla@suse.com
<ul><li><strong>Blocked by</strong> <i><a class="issue tracker-4 status-6 priority-5 priority-high3 closed" href="/issues/56045">action #56045</a>: [qe-core][functional][sporadic] command 'dasd_configure 0.0.0150 0' timed out at /var/lib/openqa/cache/openqa.suse.de/tests/sle/tests/installation/bootloader_s390.pm</i> added</li></ul> openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=2414182019-09-04T16:40:06ZSLindoMansillaslindomansilla@suse.com
<ul><li><strong>Blocked by</strong> deleted (<i><a class="issue tracker-4 status-6 priority-3 priority-lowest closed" href="/issues/49820">action #49820</a>: [functional][u] Make the svirt backend work with AppArmor enabled and under company policies</i>)</li></ul> openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=2414212019-09-04T16:40:32ZSLindoMansillaslindomansilla@suse.com
<ul><li><strong>Related to</strong> <i><a class="issue tracker-4 status-6 priority-3 priority-lowest closed" href="/issues/49820">action #49820</a>: [functional][u] Make the svirt backend work with AppArmor enabled and under company policies</i> added</li></ul> openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=2418052019-09-06T15:59:10ZSLindoMansillaslindomansilla@suse.com
<ul><li><strong>Related to</strong> <i><a class="issue tracker-4 status-12 priority-3 priority-lowest" href="/issues/43655">action #43655</a>: [qe-core][functional] Increase robustness of using bootloader parameter with info-file instead of long typing</i> added</li></ul> openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=2492092019-10-11T17:24:09Zokurzokurz@suse.com
<ul></ul><p><a class="user active user-mention" href="https://progress.opensuse.org/users/24132">@SLindoMansilla</a> I think you found a different approach since your last ticket update, haven't you? We have "rebel" as an o3 worker. I am not sure how you want to control it. If you want I think we can include it and try to manage it just like the other o3 workers when you think this is the best approach. dmcvicar asked in <a href="https://chat.suse.de/channel/suse?msg=6H9kDMt4gGxc3tAYF" class="external">https://chat.suse.de/channel/suse?msg=6H9kDMt4gGxc3tAYF</a> about the status of Tumbleweed s390x and dimstar force-pushed a build of openSUSE:Factory:zSystems to o3. The jobs were scheduled but not triggered as there was no openQA worker instance running on rebel, the machine did not properly update since about 120 days. I fixed the update on rebel and rebooted into the new snapshot, the worker started correctly and started the job <a href="https://openqa.opensuse.org/tests/1054455" class="external">https://openqa.opensuse.org/tests/1054455</a> which failed in <a href="https://openqa.opensuse.org/tests/1054455#step/bootloader_s390/35" class="external">https://openqa.opensuse.org/tests/1054455#step/bootloader_s390/35</a> with an Input/output error on DASD device when trying to start installation. Maybe the DASD device previously assigned to the z/VM instance is now used elsewhere as well or needs to be re-initialized?</p>
openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=2829462020-03-04T10:18:02ZSLindoMansillaslindomansilla@suse.com
<ul><li><strong>Blocked by</strong> deleted (<i><a class="issue tracker-4 status-6 priority-5 priority-high3 closed" href="/issues/56045">action #56045</a>: [qe-core][functional][sporadic] command 'dasd_configure 0.0.0150 0' timed out at /var/lib/openqa/cache/openqa.suse.de/tests/sle/tests/installation/bootloader_s390.pm</i>)</li></ul> openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=2829552020-03-04T10:20:00ZSLindoMansillaslindomansilla@suse.com
<ul><li><strong>Status</strong> changed from <i>Blocked</i> to <i>Resolved</i></li></ul><p>Not blocked anymore since we have a workaround <code>hardened_usercopy=off</code></p>
<p>First two tests are already working: <a href="https://openqa.opensuse.org/group_overview/34" class="external">https://openqa.opensuse.org/group_overview/34</a></p>
<p>More test suites will be added, but no need for this ticket anymore. Updates will be announced in ML opensuse-factory and opensuse-zsystems (see <a href="https://lists.opensuse.org/" class="external">https://lists.opensuse.org/</a>)</p>
openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=2830812020-03-04T13:42:25Zpvorelpetr.vorel@suse.com
<ul></ul><p>Nice, congratulations!<br>
Can I add s390x LTP tests into kernel Tumbleweed tests <a href="https://openqa.opensuse.org/group_overview/32" class="external">https://openqa.opensuse.org/group_overview/32</a><br>
I'd start with just 3 most important: install_ltp, ltp_syscalls and ltp_cve</p>
openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=2831322020-03-04T15:38:40ZSLindoMansillaslindomansilla@suse.com
<ul></ul><p>pvorel wrote:</p>
<blockquote>
<p>Nice, congratulations!<br>
Can I add s390x LTP tests into kernel Tumbleweed tests <a href="https://openqa.opensuse.org/group_overview/32" class="external">https://openqa.opensuse.org/group_overview/32</a><br>
I'd start with just 3 most important: install_ltp, ltp_syscalls and ltp_cve</p>
</blockquote>
<p>Thanks!</p>
<p>More coverage is always better, but, could add them first to "Development Tumbleweed" <a href="https://openqa.opensuse.org/group_overview/38" class="external">https://openqa.opensuse.org/group_overview/38</a> ?<br>
Once they are green or orange, no problem to add them to "PROD"</p>
openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=2831352020-03-04T16:01:19Zpvorelpetr.vorel@suse.com
<ul></ul><p>SLindoMansilla wrote:</p>
<blockquote>
<p>More coverage is always better, but, could add them first to "Development Tumbleweed" <a href="https://openqa.opensuse.org/group_overview/38" class="external">https://openqa.opensuse.org/group_overview/38</a> ?<br>
Once they are green or orange, no problem to add them to "PROD"</p>
</blockquote>
<p>Sure, I'll add it first to development. Just a note, syscalls are always read, as that's a big collection of tests, very rarely they're all green even on SLES (very few tests fail, but of course still it's good to run them on both SLES and Tumbleweed).</p>
openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=2831592020-03-04T16:56:17Zokurzokurz@suse.com
<ul></ul><p>pvorel wrote:</p>
<blockquote>
<p>Just a note, syscalls are always read, as that's a big collection of tests, very rarely they're all green even on SLES (very few tests fail, but of course still it's good to run them on both SLES and Tumbleweed).</p>
</blockquote>
<p>Then please don't add them. openQA should be used and is used by many as a validation platform, especially openqa.opensuse.org meaning that tests should only fail when they show new regressions that are also handled accordingly. We have limited ressources, especially on o3 and there are enough tests ignored and wasting ressources in "Development" already.</p>
openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=2831682020-03-04T18:27:59Zpvorelpetr.vorel@suse.com
<ul></ul><p>Oliver, kernel syscalls is the main validation for kernel, used on other the other archs. Failing tests are mostly on all archs. BTW we talk about 5 failing tests of 1304 fails (you know, kernel is never "fixed", there is always some error, thus stop testing because 0.5% of tests does not pass doesn't make sense :)).</p>
openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=2831712020-03-04T18:35:34Zokurzokurz@suse.com
<ul></ul><p>you seem to have a different understanding of what a "test" is. IMHO, especially for openQA tests, every test result on top level is boolean, either it passed or not. If "not" then this means "block the release of the product that is tested" until resolved. Just keep in mind that openSUSE Tumbleweed and openSUSE Leap use a bot that releases when there are no not-ignored, failing test cases left, i.e. needs review of test failures and reliable results. Everything else has simply no place on o3 outside the "Development" job groups. And I hope to arrive at this approach for osd as well to get rid of the tedious very manual approach for test result reviewing.</p>
openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=2831922020-03-04T19:09:03Zpvorelpetr.vorel@suse.com
<ul></ul><p>Regards to failures: we're slowly working on fixing them (ongoing process), much bigger problem than few failures is <a class="issue tracker-4 status-3 priority-5 priority-high3 closed" title="action: [o3][kernel][scheduler][x86_64] Dependent (child) jobs should start after uploading all of parent... (Resolved)" href="https://progress.opensuse.org/issues/63373">#63373</a>, as it breaks all kernel testing on intel. That's what really spoil the validation (and nobody cares).</p>
<p>These tests: we check the results (it's very useful to see bugs on Tumbleweed, which is close to mainline, but not the same). That's the only reason why I'm adding also s390x tests.</p>
<p>Added these 3 tests install_ltp, ltp_cve and ltp_syscalls into <a href="https://openqa.opensuse.org/group_overview/38" class="external">https://openqa.opensuse.org/group_overview/38</a>. If they work ok, I'll move them to kernel (<a href="https://openqa.opensuse.org/group_overview/32" class="external">https://openqa.opensuse.org/group_overview/32</a>) and add some more (just a few, as s390x is probably busy a lot).</p>
openQA Tests - action #48434: [functional][u] test Tumbleweed s390x againhttps://progress.opensuse.org/issues/48434?journal_id=2914732020-04-08T06:02:15Zokurzokurz@suse.com
<ul></ul><p>This is an autogenerated message for openQA integration by the openqa_review script:</p>
<p>This bug is still referenced in a failing openQA test: textmode<br>
<a href="https://openqa.opensuse.org/tests/1227549" class="external">https://openqa.opensuse.org/tests/1227549</a></p>
<p>To prevent further reminder comments one of the following options should be followed:</p>
<ol>
<li>The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted</li>
<li>The openQA job group is moved to "Released"</li>
<li>The label in the openQA scenario is removed</li>
</ol>