sys.exit will cause finally statements and other code to run at exit. Since
we're using os.fork() here, os._exit() is apprioriate in this codepath.
(From OE-Core rev: a99e23c403abd8e520079e2e216d87e713559682)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit ec08498ff29de9ccd23be88b9d7af3dab6bbb81e)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When running a shutdown command, the serial port can close without the
command returning. This is seen as the socket being readable but having
no data. Change the way this case is handled in the code to avoid
tracebacks.
(From OE-Core rev: a72572532b976a4c3e8fa68fe63f63e39399ee88)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 396a3ba884820d040c91f7592daf20ac28c49b5d)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The recent logging changes for qemurunner showed up as errors on the
autobuilder where decode couldn't be called on the returned string.
Since the code returns binary data, return b'' instead of '' to match
to avoid tracebacks.
One of these cases was newly added, copied from the other which has
been there for a long time, always broken.
(From OE-Core rev: 000feb98ff99e74d6118fc3f53330b8e975923d9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit b8995b27db265b0a0b2d2ca595915f70f9f96e07)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rather than totally disabling the logging, inform it we're about to exit
so we can log messages over the exit cleanly too. This aids debugging. It
also avoids a race where the logging handler could still error whilst
shutting down.
Also remove a race window by notificing the handler of the shutdown
first, before triggering it. This removes a race window I watched in
local testing.
(From OE-Core rev: 7f931dce4484a2740b419b2d25830fc453748a0c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 0e19f31a1005f94105e1cef252abfffcef2aafad)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have a working theory that IO queues on the autobuilder are impacting
runtime testing under qemu, particularly async writes which inice does not
influence. We already pass the snapshot option to qemu which copies the
image and runs out of the copy. Add in the ability to copy the image to
a specificed location which can be a tmpfs. This means that writes to the
image would no longer be blocked by other writes to disk in the system.
Preliminary tests show that this does improve the qemu errors at the expense
of sometimes showing qemu startup timeouts as on a loaded system with a large
test image, it can take longer than 120s to copy the image to tmpfs. Having
a most consistent failure mode for loaded tests is probably desireable though.
(From OE-Core rev: fd1c26ab426c3699ffd8082b83d65a84c8eb8bff)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some platforms do not use ttyS* for their serial consoles (e.g., qemuarm
and qemuarm64). The hardcoding of this can cause issues. Modify
runqemu to use the serial consoles defined in SERIAL_CONSOLES instead of
hardcoding.
(From OE-Core rev: 9dea4cd2f9f46ab3a75562639a22d8f56b4d26af)
Signed-off-by: Jon Mason <jon.mason@arm.com>
Change-Id: I746d56de5669c955c5e29d3ded70c0a4d3171f17
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Increase the serial login timeout from 60 to 120s. This seems like a
long time, however for a qemumips image with systemd+PAM and openssh,
(e.g. core-image-sato-sdk + DISTRO=poky-altcfg), the getty connects
to systemd's pam module which waits on logind and 45s for all this
to happen at the same time as things like ssh key generation happens
is not unknown.
Increase the timeout to match the longer times we know these things
can take in the worst case scenarios since we're tired of intermittent
issues related to the serial login affecting the autobuilder.
(From OE-Core rev: d8b4292db741de660f756dfb766210814d587b7a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We're seeing failures due to system load. In theory we've set process
nice levels which should compensate for this. Add debugging so we can
find out if they're being correctly applied.
(From OE-Core rev: 1e4e345bba8216b9b5623682206a7dae7cad261c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
One element of the error message guarded against None as a value
but I missed the other, fix this.
(From OE-Core rev: dbce6baec68d7658453b8c44159e1d1fef746151)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When qemu fails to start we're struggling to work out why. Add more debug
info which can at least confirm/rule out various things.
This code is only on the error handling path and more info shoudl help
us debug issues.
(From OE-Core rev: 3001d0d8f3429e5ff0c37ea7192e85e7001cdb32)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The pid location could vary due to changes in cwd as only a filename
is specified, not a full path. This in theory could be resulting in
some of our autobuilder failures. Whilst its difficult to know if this
is causing a problem, Using a full path removes any question of such an
issue.
(From OE-Core rev: 55c186ff410c99570242478b99ac24ebc40aa6bd)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When falling back from detecting ip from /proc/./cmdline the
output of runqemu is acutally
'Network configuration: ip=192.168.7.2::192.168.7.1::255.255.255.0'
which doesn't match the given regex and leading to run failure, although
IP is detectable.
Fix regex by inserting an optional 'ip=' prefix to first IP
(From OE-Core rev: 75f2471d15fab024775c59cb70c54e3f25f9ae72)
Signed-off-by: Konrad Weihmann <kweihmann@outlook.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you fail to setup the tap devices, runqemu will error quickly
however stdout/stderr are not shown to the user, instead a SystemExit
traceback is shown. This could explain some long since unexplained
failures on the autobuilder.
Rework the error handling so SystemExit isn't used and the
standard log failure messages can be shown. The code could
likely ultimatley need some restructuring to work effectively.
(From OE-Core rev: 57ccf1e3bb320bd28a2d106c98f4706434c3075a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add support for running wic images with EFI as testimage.
Introduces a variable called QEMU_USE_OVMF for configuration.
(From OE-Core rev: 3af8aaff68ed332d812ea7dc184d392700ad7882)
Signed-off-by: Konrad Weihmann <kweihmann@outlook.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Printing a warning for something which is harmless just causes the
people monitoring the autobuilder more work. Silently ignore this race.
(From OE-Core rev: 2246c8d2466d3876fd1b27fd1943aa4bbf28e14e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current runtime infrastructure contains hardcoded values which Ill refer to
as patterns, these patterns are either searched through or sent via the serial
terminal to communicate between HOST and TARGET.
These patterns are required since they allow us to check when a device has
finished booting, to log in, and to check whether a command sent from our tests
has returned, this way we are able to check both the status of the commands that
were sent along with its output.
The testing process goes somewhat as follows:
1. Launch QEMU and start booting.
2. Check when the device has booted by looking for the pattern login:.
3. Log in as the root user (default for our images).
4. Check that we were able to log in succesfully.
5. Start running the runtime test cases defined by TEST_SUITES.
6. One of such test cases could send a command to the QEMU target.
7. Check whether that command returned.
8. Check its output and status, return whether the test case passed or failed.
This patch allows this set of patterns to be defined instead of being hardcoded,
but it also automatically sets the defaults that we have been using in the past
if they have not been manually defined, for this reason, the patch is less
invasive and should not affect in any way how tests are currently being run.
Cases that can be enabled with this patch:
- A customized image that does not use the root user (or maybe we want to check
what happens if we dont use the root user).
- An image where the PS1 env variable has been modified, and the prompt pattern
wouldnt match the default.
- Baremetal applications, which do not follow the conventional way of booting
Linux and would probably not show a prompt for a user to log in, same applies
for testing bootloaders.
- poky-tiny: Using DISTRO=poky-tiny and an image such as the core-image-tiny
from meta-intel, which boots directly to RAM, and does not show a log in prompt
since it does not contain a conventional init process.
The code itself contains comments that should be self explanatory but here is an
example on how these patterns can be defined in a hypothetical case where we
want to run test cases as the webserver user instead:
TESTIMAGE_BOOT_PATTERNS = "send_login_user search_login_succeeded"
TESTIMAGE_BOOT_PATTERNS[send_login_user] = "webserver\n"
TESTIMAGE_BOOT_PATTERNS[search_login_succeeded] = "webserver@[a-zA-Z0-9\-]+:~#"
The variable TESTIMAGE_BOOT_PATTERNS defines which patterns to override when
used to communicate with the target when booting, anyone familiar with the
PACKAGECONFIG syntax should have no trouble setting these.
Other patterns would still be set up as default, e.g.
search_reached_prompt would still be login:
The accepted flags for TESTIMAGE_BOOT_PATTERNS are the following:
search_reached_prompt, send_login_user, search_login_succeeded,
search_cmd_finished.
They are prefixed with either search/send, to differentiate if the pattern is
meant to be sent or searched to/from the target terminal.
A working example of this code that falls under the baremetal case mentioned
above along with a test case is present on the meta-freertos layer, which tests
an RTOS image built with OpenEmbedded and automatically runs a test case on it
after booting such image:
As usual, INHERIT += "testimage" needs to be present on local.conf
$ bitbake freertos-demo -c testimage
RESULTS:
RESULTS - freertos_echo.FreeRTOSTest.test_freertos_echo: PASSED (2.00s)
SUMMARY:
freertos-demo () - Ran 1 test in 2.006s
freertos-demo - OK - All required tests passed (successes=1, skipped=0,
failures=0, errors=0)
(From OE-Core rev: 3ab2cbfeff371e8791b031a2852eeef80101a831)
Signed-off-by: Alejandro Hernandez Samaniego <aehs29@gmail.com>
Signed-off-by: Alejandro Hernandez Samaniego <alejandro@enedino.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In some instances, attempts to remove the qemu pidfile within the
stop() method fail despite the os.path.exists() call immediately
before implying that the file is present. Add a try/except block
to log a warning if this occurs, rather than failing outright,
since the process simply appears to be exiting at an inconvenient
time.
[YOCTO #13675]
(From OE-Core rev: eadb899e23b18eb9eaff145c3bf5b20fb417c3e8)
Signed-off-by: Trevor Gamblin <trevor.gamblin@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we get here in the code it's because runqemu has failed, this is not
a debug situation - we need to see the output, so print it as an error.
Fixes [YOCTO #13681].
(From OE-Core rev: c1def38c680d64c992839166bbf9bec51eb0788a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This avoids some tracebacks we've seen on failed autobuilder builds which would
allow the real error to be seen.
(From OE-Core rev: a4031935a7b8ea4f61b9020c1aa5598e186e7ad7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Not all QEMU machines are capable of having more than one serial port,
this is due to the machine emulating a physical device/board.
Rework QemuRunner to handle machines that only have 1 serial port, where
the serial port shares output of the kernel log buffer and a login
console. In this case the output is mixed but enables the machine to
boot and have QemuRunner detect the login prompt.
QemuTarget uses SERIAL_CONSOLES to determine the number of available
serial ports.
(From OE-Core rev: 333897c4a00b41681ffe34312a08cae09274327e)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously, 'nographic' was set first, and was overriding anything set via runqemuparams.
Particularly, egl-headless from the virgl headless selftest was overriden,
which broke the test in non-X environments.
(From OE-Core rev: 344c55a58042ecd6ffed8b20add41b6b335c51bf)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of hiding problems in the debug log let's print them as warnings
instead.
(From OE-Core rev: 088f5d97001bd4b573f00cfca93b8d24e814fd64)
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When handling pid file, qemu would first create the file, stat it,
lock it and then write actually contents to it.
So it's possbile that when reading the pid file, the content is empty.
[YOCTO #13390]
(From OE-Core rev: 170e59b203a02f8438b9aeab3a45f6fcd6608b1f)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While hacking on this I got an Exception. It's better to define
variables also in python.
Signe:-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
(From OE-Core rev: 1ea225a86cdee4ed932ede509d3351d5aecae497)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After the commit ad522ea6a6 ("runqemu: Let qemuparams override default
settings"), the order of the two "-serial" parameters when running the
qemu have been switched. The effect of this is that the logging thread
will use ttyS1 (of course can't capture the kernel boot message anymore),
and the test command will run on the ttyS0. So the output of the test
command may be mangled by the kernel message (such as call trace), and
let the test command produce a fake timeout error message. We can't fix
it by just adjusting the order of the threadport and serverport, since
it will break some machines such as qemuarm64 which use the virtio
serial. So using the tcpserial to setup both the threadport and
serverport.
[YOCTO Bug 13309]
(From OE-Core rev: 9f2005dee41b1ef5a0d1f7b69bcd6c8352dac016)
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This adds SPDX license headers in place of the wide assortment of things
currently in our script headers. We default to GPL-2.0-only except for the
oeqa code where it was clearly submitted and marked as MIT on the most part
or some scripts which had the "or later" GPL versioning.
The patch also drops other obsolete bits of file headers where they were
encoountered such as editor modelines, obsolete maintainer information or
the phrase "All rights reserved" which is now obsolete and not required in
copyright headers (in this case its actually confusing for licensing as all
rights were not reserved).
More work is needed for OE-Core but this takes care of the bulk of the scripts
and meta/lib directories.
The top level LICENSE files are tweaked to match the new structure and the
SPDX naming.
(From OE-Core rev: f8c9c511b5f1b7dbd45b77f345cb6c048ae6763e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
self.msg is a str(), bootlog is b'' so this code clearly doesn't work. Add
in a decode since its being used as a string.
(From OE-Core rev: e7546759d3102b576974bbab52594796f084721e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The 5s timeout for non-kvm is too short, especially when the load is high,
which leads to unexpected errors, so set timeout to 60s by default.
(From OE-Core rev: 8197d0f638a760fc03062c7a9009117d083d7ead)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Reorder the shutdown/teardown to avoid:
File "/home/pokybuild/yocto-worker/oe-selftest-ubuntu/build/meta/lib/oeqa/utils/qemurunner.py", line 224, in launch
op = self.getOutput(output)
File "/home/pokybuild/yocto-worker/oe-selftest-ubuntu/build/meta/lib/oeqa/utils/qemurunner.py", line 90, in getOutput
fl = fcntl.fcntl(o, fcntl.F_GETFL)
ValueError: I/O operation on closed file
(From OE-Core rev: 8e7d756862d2a8d62f3c87497d6d65ddb3c1b962)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If runqemu fails it would leak an unclosed socket and file. Ensure we
close these in all cases to remove the resource warning.
(From OE-Core rev: ed80e46ccbc8fe8e9148d80723152066fa00ba28)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enable qemurunner for slirp. Retrieved the ip & port from host machine
to connect to qemu from host machine.
[YOCTO#10713]
(From OE-Core rev: 1db6a6fc9cde28d0a29bcf6d24a8bfbe51d120b1)
Signed-off-by: Yeoh Ee Peng <ee.peng.yeoh@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The qemu shutdown can race with the signal handler removal leading to
confusing tracebacks on slower/loaded systems.
Remove the signal handler first before shutting down.
(From OE-Core rev: 1b63ce7bb83134f84bf07d1075d5ca0d5466ed3d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #12493]
Fixed:
- qemu started with pid 10000
- qemu exited unexpectedly
- The pid 10000 is re-used by another different process.
The is_alive() returned True in such a case because both qemu_pidfile and
/proc/10000 exist, but it's another process, this patch fixed the problem.
(From OE-Core rev: 78033af85698b4e112ae78e3140b241b1b3c06a3)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The warn method is deprecated. We should use the documented warning instead.
Quoting from the python's official doc:
"""
Note: There is an obsolete method warn which is functionally identical to warning.
As warn is deprecated, please do not use it - use warning instead.
"""
(From OE-Core rev: f467fd277eb77336097cfc0f5f329bdc8d0f70cb)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Minor grammar correction along with making the term 'login banner'
consistent throughout to make searching logs easier.
(From OE-Core rev: 54e739485faba8d80f5af15407905aaeda4767f4)
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current logging always assumes the boot timeout has expired yet
there is a second reason we might have ended up in a position where no
login banner was found, that being a socket disconnect. Add logging
for the disconnect case and make the timeout expiration conditional on
the timeout being exhausted.
(From OE-Core rev: 49403368ccf3e469ac111afa259a38cc11e0b688)
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When debugging issues when timeouts are involved it is always best to
have wall clock times included. This helps give confidence that the
timeout is in fact run down at the right rate and that no unexpected
events were the true cause of a premature running down of the
timeout. Having these times in old logs also helps when debugging
issues as we have a historic record as to what is a 'typical' time to
complete an action.
In addition to adding the wall clock times the time to 'login' is now
printed making it consistent with the time to 'qemu pid'.
(From OE-Core rev: 4a6364309547d77d1d7a94c48f7c51ceee2b5d1a)
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I have concerns that bad timing of the flow of data from the logger
might corrupt the output due to the way binary strings are handled
in qemurunner.
This simplifies the code to do the same thing it did before but much
more safely.
(From OE-Core rev: 1e87283e92a2765bb5d54d17138b208bc395953b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The logger handling in oeqa was confused at best. This patch:
a) Passes in a logger through various qemu runner pieces
b) Uses that logger consistently in the code
c) Creates a logger for QemuRunner outside the bitbake namespace
meaning we don't conflict with the tinfoil logging changes
The result of this is more consistency. For runtime tests in testimage,
the logs always contain the debug info, nothing is shwon on the console.
For the oe-selftests, logs are intercepted and only shown if the test
fails.
(From OE-Core rev: 4ff678137a55b93c9ba2cbffda34335ba859f704)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bitbake logs info messages to the console. These messages are really
there as debugging information. At the debug level, they will be shown
in failure logs and in the task logs but not on the console which
is what we want in this case.
(From OE-Core rev: e05b14ad5a3c5ac1656b6fffdcf7e58250638e96)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we don't remove the handler we end up with duplicate log messages
which is undesireable.
(From OE-Core rev: 4155a58aebe9c730be9ff1f68150f34d1cd472e5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are cases where the 'while loop' waiting for login prompt fails
and the bootlog variable does not get populated, thus use the the new
qemurunner member (self.msg) which stores all output coming from the qemu
process.
[YOCTO #12113]
(From OE-Core rev: 39ffa0f3779305c5e8ef86fe4572e961c5912021)
Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need QEMU PID in order to access "/proc/<qemupid>/cmdline"
Having a valid QEMU PID does not mean we can access the proc entry
immediately, we need to wait for the /proc/<qemupid> to appear
before we can access it.
(From OE-Core rev: d2d069fa9910d1c7a94c898355a63fca03ec5ad8)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ask QEMU to store the QEMU process PID in a file, this way we don't
have to parse running processes and analyze descendents.
This is done via QEMU command line argument "-pidfile".
[YOCTO #12001]
(From OE-Core rev: 67612dcd2a8a1aa1d683dddb0bd2f592886ff020)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Python unittest intercepts stdout and stderr however qemurunner sets
up a streamhandler before that interception occurs, hence the messages
spam the unittest output.
By moving the logging init to the class init time, we use the unittest
stdout/stderr and this means unittest can only show the log output upon
failure. This cleans up the selftest and testimage output whilst still
showing logging upon failure.
(From OE-Core rev: 9099cecc727fe0ae5f1559582426d30ba7a9f4d3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
