openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842017-05-05T13:25:35ZopenSUSE Project Management Tool
Redmine openQA Project - action #18980 (Resolved): [ltp][openqa][virtio][ppc64le] It appears agetty is no...https://progress.opensuse.org/issues/189802017-05-05T13:25:35Zrpalethorperichard.palethorpe@suse.com
<p>Neither os-autoinst or QEMU throw an error when creating a virtio console device, connecting to its socket or sending data. However no I/O is recorded in QEMU's chardev log, nor is anything received from the SUT through the socket. It is a bit strange that not even data sent by os-autoinst is recorded in the log, although it might never log input data, but appears to under normal operation because echo is enabled on the TTY.</p>
<p>Unlike x86, ppc64le already uses /dev/hvc0 (on the SUT) for the regular serial port whereas virtio console would usually be on this device. However this should probably just mean that it uses /dev/hvc1 instead, os-autoinst would have no problem with this. Maybe SLE's systemd is not configured to start agetty on this device or the virtio_console driver works differently on ppc64le. Both seem quite strange.</p>
<p>This might be a product bug, but I need more information from the SUT to decide. It should just work.</p>
<p>UPDATE: for those who are searching here for <strong>OFW</strong>: it's ppc detectioni<br>
<a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/4477" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/4477</a><br>
(Replace check_var ARCH ppc64le by get_var OFW)</p>
openQA Tests - action #16424 (Rejected): [openqa] main.pm is too oldhttps://progress.opensuse.org/issues/164242017-02-02T16:13:07Zrpalethorperichard.palethorpe@suse.com
<p>If main.pm is not updated then some tests are not scheduled correctly and may fail or run the wrong test.</p>
openQA Project - action #16320 (Resolved): Random timeouts while waiting for serial output when u...https://progress.opensuse.org/issues/163202017-01-30T11:00:19Zrpalethorperichard.palethorpe@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>Tests timeout while waiting for output from an LTP test: <a href="https://openqa.suse.de/tests/743383" class="external">https://openqa.suse.de/tests/743383</a>.</p>
<p>It appears that the command text is sent to the SUT, but no response is received. In the serial log[1] for the above test it shows that the last test ran and returned a result. However nothing is read by the virtio console backend.</p>
<p>In this test: <a href="https://openqa.opensuse.org/tests/342884" class="external">https://openqa.opensuse.org/tests/342884</a> [2], one call to <code>wait_serial</code> fails, but then the next succeeds and then it fails again. The calls which pass do not use regular expressions to do the matching.</p>
<p>As a rough estimate this bug occurs in 1%-5% of tests.</p>
<a name="Problem"></a>
<h2 >Problem<a href="#Problem" class="wiki-anchor">¶</a></h2>
<ul>
<li>H1, QEMU is writing bytes to the log, but not the socket</li>
<li>H2, The virtio backend function <code>read_until</code> is not reading bytes from the socket correctly</li>
<li>H3, One or more of the read buffers in <code>read_until</code> are being dropped.</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>A0, Inspect more test failures.</li>
<li>A1, Run the virtio terminal unit tests repeatedly.</li>
<li>A2, Modify the virtio test module to perform a stress test.</li>
<li>A3, Investigate how QEMU passes the data.</li>
</ul>
<p>I am currently waiting for a crash dump of the SUT to be attempted after a freeze.</p>
<a name="workaround"></a>
<h2 >workaround<a href="#workaround" class="wiki-anchor">¶</a></h2>
<ul>
<li>W0, Retrigger the job manually.</li>
<li>W1, Retrigger the job automatically after a timeout.</li>
</ul>
<p>[1] The serial log is written by QEMU.<br>
[2] There is no virtio serial log for this test, possibly O3 needs updating.</p>
openQA Tests - action #15678 (Resolved): [LTP][OpenQA] misc: acpi_test_dev_callback failshttps://progress.opensuse.org/issues/156782016-12-29T09:16:53Zrpalethorperichard.palethorpe@suse.com
<p>The ltp_acpi tests fails when running a test inside the ltp_acpi_cmds kernel module called acpi_test_dev_callback.</p>
<p><a href="https://openqa.suse.de/tests/686455#step/run_ltp/45" class="external">https://openqa.suse.de/tests/686455#step/run_ltp/45</a></p>
openQA Tests - action #15652 (Closed): [LTP][OpenQA] commands: mkfs.ntfs missinghttps://progress.opensuse.org/issues/156522016-12-27T11:26:45Zrpalethorperichard.palethorpe@suse.com
<p>The ntfsprogs package appears to be missing in SLES 12 onwards. It exists in OpenSUSE, so we could at least run the tests there, but then we start on the path of installing different sets of packages in SLES and OpenSUSE. Furthermore I am not sure that we care about NTFS support.</p>
openQA Tests - action #15626 (Resolved): [LTP][OpenQA] commands: du -a test failshttps://progress.opensuse.org/issues/156262016-12-22T12:46:21Zrpalethorperichard.palethorpe@suse.com
<p><a href="https://openqa.suse.de/tests/686450#step/run_ltp/111" class="external">https://openqa.suse.de/tests/686450#step/run_ltp/111</a></p>
openQA Tests - action #15624 (Resolved): [LTP][OpenQA] sssd: sss_* commands not foundhttps://progress.opensuse.org/issues/156242016-12-22T12:42:05Zrpalethorperichard.palethorpe@suse.com
<p>It seems that SUSE does not have commands (they are not in sssd-tools) such as sss_useradd. We probably just use regular <code>useradd</code> with the correct PAM modules configured.</p>
openQA Tests - action #15622 (Resolved): [LTP][OpenQA] commands: mail test claims mail fail is no...https://progress.opensuse.org/issues/156222016-12-22T12:36:35Zrpalethorperichard.palethorpe@suse.com
<p><a href="https://openqa.suse.de/tests/686450#step/run_ltp/56" class="external">https://openqa.suse.de/tests/686450#step/run_ltp/56</a></p>
<p><a href="https://openqa.suse.de/tests/latest?flavor=Server-DVD&distri=sle&machine=64bit&test=ltp_commands&version=12-SP3&arch=x86_64" class="external">latest</a></p>
openQA Tests - action #15620 (Rejected): [LTP][OpenQA] Crontab activity not foundhttps://progress.opensuse.org/issues/156202016-12-22T12:17:18Zrpalethorperichard.palethorpe@suse.com
<p>cron_tests.sh checks /var/log/messages and /var/log/cron for crontab activity, but neither file exists on newer systems. The test should probably try using <code>journalctl</code> as well.</p>
openQA Tests - action #15592 (Resolved): [LTP][OpenQA][kernel] LTP Native test runner minor issueshttps://progress.opensuse.org/issues/155922016-12-20T16:06:45Zrpalethorperichard.palethorpe@suse.com
<p>This is an unsorted and unverified list of issues I have identified from running most of the LTP tests on openqa.suse.de</p>
<ul>
<li>[ ] aiodio no junkfile</li>
<li>[ ] cap bounds; fail to exec check_pe</li>
<li>[ ] commands; no crontab activity</li>
<li>[ ] commands; no fail mail</li>
<li>[ ] commands: sssd-lib.sh missing</li>
<li>[ ] commands: du -a failed</li>
<li>[ ] commands; ntfs not found</li>
<li>[ ] controllers; cgroup fail</li>
<li>[ ] controllers; mem+swap not enabled</li>
<li>[ ] controllers; memcg fail</li>
<li>[ ] controllers; subsystem debug not supported</li>
<li>[ ] controllers; 'controllers' test broken</li>
<li>[ ] cpuhotplug support</li>
<li>[ ] random timeouts where serial terminal I/O appears to cease with no error</li>
<li>[ ] ext4, readonly; need big block device</li>
<li>[ ] hyperthreading; supported?</li>
<li>[ ] ima; broken?</li>
<li>[ ] misc; need kernel modules</li>
<li>[ ] misc; acpi broken?</li>
<li>[ ] lvm; unable to make ~/test/growfiles/msdos~ directory</li>
<li>[ ] mm; need more swap space</li>
<li>[ ] numa; broken test?</li>
<li>[ ] rpc; broken tests?</li>
<li>[ ] smack; needs ~/smack~</li>
<li>[ ] syscalls; movepages needs NUMA</li>
<li>[ ] syscalls_ipc; duplicates syscalls?</li>
<li>[ ] msgctl10; fork failed (too ambitious?)</li>
<li>[ ] tirpc; tests broken?</li>
<li>[ ] tpm_tools; commands are missing</li>
<li>[ ] tpm_tools; virtual or physical TPM required</li>
<li>[ ] ensure all non-duplicate, non-networking runtest files are being used</li>
<li>[ ] transfer test configurations to openSUSE</li>
</ul>
<p>Some issues are probably upstream problems and others may be large or hard enough to deserve their own issue entry and proper scrutiny. I will try to fix the easiest ones first and get a better idea of what is required.</p>
openQA Tests - action #15492 (Resolved): Upgrade ppc64le workers to QEMU 2.6.*, i.e. current Leap...https://progress.opensuse.org/issues/154922016-12-14T11:06:38Zrpalethorperichard.palethorpe@suse.com
<a name="observation"></a>
<h2 >observation<a href="#observation" class="wiki-anchor">¶</a></h2>
<p>This job (<a href="https://openqa.suse.de/tests/668033/file/autoinst-log.txt" class="external">https://openqa.suse.de/tests/668033/file/autoinst-log.txt</a>) fails because the logfile parameter is not available in the installed version of QEMU on the worker.</p>
<a name="problem"></a>
<h2 >problem<a href="#problem" class="wiki-anchor">¶</a></h2>
<p>Upgrading the QEMU version on the worker will fix this. But for this we would need to update e.g. malbec.arch from SLES 12 SP1 to a more recent version which no one did, maybe for good reasons.</p>
<a name="workaround"></a>
<h2 >workaround<a href="#workaround" class="wiki-anchor">¶</a></h2>
<p>The virtio-console is optional in os-autoinst and is only enabled if the job states 'VIRTIO_CONSOLE=1'. As a workaround disable this setting.</p>
openQA Project - action #14690 (Resolved): Live stream for serial terminalhttps://progress.opensuse.org/issues/146902016-11-08T14:32:21Zrpalethorperichard.palethorpe@suse.com
<p>Replace the live SUT video feed in the OpenQA UI with a scrolling text display when a serial terminal is set as the active console.</p>
<p>Currently when the user selects a serial console a stale screen shot of the last used VNC console is shown. The live log below still updates, but the user experience is significantly degraded.</p>
openQA Project - action #14582 (Resolved): Add virtio serial console backend and APIhttps://progress.opensuse.org/issues/145822016-10-31T10:40:37Zrpalethorperichard.palethorpe@suse.com
<p>I have written a new console backend which allows IO through a serial terminal, in particular the virtio console with QEMU, but I am currently thinking about how to generalise it. I started out mostly interested in how virtio could be used to speed up testing, but actually it has turned out to be mostly irrelevant. The most important thing is that communication is done as if a user is typing text into a serial terminal. For platforms which can be controlled entirely (or only) over UART (or UART over USB/Bluetooth/whatever) this opens up quite a few possibilities.</p>
<p>From <a href="https://github.com/os-autoinst/os-autoinst/pull/637:">https://github.com/os-autoinst/os-autoinst/pull/637:</a></p>
<pre><code>This allows the test writer to log into and interact with a serial
terminal directly. Initially this is just for the virtio_console under
QEMU, but can be extended to any serial console.
Presently the only way of sending text to a tty running on a SUT is to
send the keystrokes via VNC. Output from the SUT can be redirected to
and read from, a serial port, however the test writer can not send text
directly to the serial port without circumventing the test API.
This patch introduces a new console backend which can be selected in the
same manner that the existing console backends are, but is limited to
text input and output. This means that there is no video feed, but
entering commands is orders of magnitude faster because the commands are
sent and interpreted as text rather than simulated keystrokes.
This adds the is_serial_terminal subroutine to the testapi which is
exported on request. Otherwise the API should be unchanged and fully
backwards compatible.
</code></pre>
<p>Currently the virtio serial terminal must be requested by the test case. I think this is fine for now, because it is primarily needed for the LTP native runner I am also working on. However after further testing and modifications to the UI to display a text feed rather than a video, I think it can be automatically used when 'root-console' (or similar) is requested. Further improvements and features may include:</p>
<a name="Display-serial-log-in-OpenQA-UI"></a>
<h3 >Display serial log in OpenQA UI<a href="#Display-serial-log-in-OpenQA-UI" class="wiki-anchor">¶</a></h3>
<p>Currently a bitmap feed is displayed, which is nice, and using a serial terminal breaks that. The user can still see, to some extent, what is happening in the virtual machine from the os-autoinst log feed. However it would be nice if they could see the tty log in real time. All that needs to happen is that either os-autoinst relays IO from the serial socket to the UI or the UI reads a log file containing the serial terminal output (e.g. QEMU produces such a file). There is probably a javascript library for handling terminal escape codes, but otherwise the raw text can just be displayed. Alternatively an image could be generated of the text terminal, but that will increase network and processor load.</p>
<a name="Use-serial-terminal-whenever-possible"></a>
<h3 >Use serial terminal whenever possible<a href="#Use-serial-terminal-whenever-possible" class="wiki-anchor">¶</a></h3>
<p>This should be easy to enable, but there are two issues. One is user experience, which I have discussed above. The second is the possibility of bugs caused by subtle differences in the testapi behaviour when switching to a serial terminal. If we explicitly switch a few different tests over to using serial, then we can probably catch most problems without exposing the entire test suite to them at once.</p>
<a name="Implement-it-for-other-platforms"></a>
<h3 >Implement it for other platforms<a href="#Implement-it-for-other-platforms" class="wiki-anchor">¶</a></h3>
<p>To my knowledge, all the backends have some ability to read input from a serial port. Ideally we will want to open a second serial port which OpenQA is not already using, but it should also be possible to use the existing one. It is then a case of generalising the existing code for virtio_console to read from a different socket. If a backend only has one serial port then we perhaps have to come up with a mechanism for ignoring kernel log messages which are usually sent to the serial port.</p>
openQA Tests - action #13140 (Resolved): Job template organizationhttps://progress.opensuse.org/issues/131402016-08-10T13:59:43Zrpalethorperichard.palethorpe@suse.com
<p>I find the products/opensuse/templates file to big and painful to deal with. Perhaps a templates sub-directory should be created, which we then insert template files into just containing test suits, machines, job groups etc. which are tightly related.</p>
<p>That way someone can view all the information relating to these tests on one or two pages and import the tests without worrying if anything unexpected is going to be added. If someone needs to add all the templates at once then they can write something like ./load_templates templates/*.</p>
<p>Templates provide a way of recording how a machine or test suit should be used, in a transportable and human readable format, but one huge monolithic file is only useful for automated export-import. I used this template during my local installation by following the instructions, but the number of tests it has added was counter productive when trying to learn the system. If new users want to see a complex setup they can look no further than openqa.suse.de.</p>
openQA Project - action #12848 (Resolved): os-autoinst: CDROM assumed to be on SCSI controllerhttps://progress.opensuse.org/issues/128482016-07-25T10:18:24Zrpalethorperichard.palethorpe@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>When running os-autoinst separately from OpenQA. If <code>CDMODEL</code> in <code>vars.json</code> is not set to something beginning with <code>virtio-scsi</code> then it will fail to start the virtual machine.</p>
<pre><code>QEMU: qemu-system-x86_64: -device scsi-cdrom,drive=cd0,bus=scsi0.0: 'scsi-cdrom' is not a valid device model name
</code></pre>
<a name="Reproduction"></a>
<h2 >Reproduction<a href="#Reproduction" class="wiki-anchor">¶</a></h2>
<p>Create a vars.json similar to this</p>
<pre><code>{
"ARCH" : "x86_64",
"BACKEND" : "qemu",
"CASEDIR" : "/home/richie/qa/os-autoinst-distri-opensuse",
"CDMODEL" : "scsi-cdrom",
"DISTRI" : "opensuse",
"ISO" : "/var/lib/openqa/factory/iso/openSUSE-Tumbleweed-DVD-x86_64-Snapshot20160715-Media.iso",
"PRODUCTDIR" : "/home/richie/qa/os-autoinst-distri-opensuse/products/opensuse",
"VNC" : 90,
}
</code></pre>
<p>and run <code>isotovideo</code>. Changing CDROM to <code>virtio-scsi-pci</code> allows isotovideo to run succesfully, however it overwrites the value with <code>scsi-cdrom</code> meaning that it will fail on the next run.</p>
<a name="Discussion"></a>
<h2 >Discussion<a href="#Discussion" class="wiki-anchor">¶</a></h2>
<p>In the file qemu.pm on line 305 it decides whether or not to create a SCSI controller based on the type of drives being used. It looks for drives beginning with <code>virtio-scsi</code>, if none are present then no scsi controller is created. Then on line 548 it assumes the CDROM has the bus address <code>scsi0.0</code>.</p>
<p>It is not clear to me where the value <code>scsi-cdrom</code> comes from. The default for <code>CDMODEL</code> in <code>qemu.pm</code> is <code>virtio-scsi-pci</code>.</p>