Age | Commit message (Collapse) | Author | Files |
|
The subprocess.run was replaced by subprocess.check_call because
of compatibility support down to python 3.4. But we really don't
care about whether that command succeeds. Some user reports that
in some tmux environment, this command fails and gives some
unpleasant traceback output. So we use 'call' instead of 'check_call'
to avoid such problem.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
It only could be set as the following in the past:
QB_MEM = "-m 256"
Now it also can be set as:
QB_MEM = "-m 256M (or m)"
QB_MEM = "256M (or m)"
[YOCTO #11522]
(From OE-Core rev: ad246f5ce0652bd917d85884176baa746e1379ff)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
Fixed:
In meta/conf/machine/include/qemuboot-x86.inc:
QB_CPU_x86-64 = "-cpu core2duo"
$ runqemu qemux86-64 qemuparams="-cpu coreduo"
Check /proc/cpuinfo, it should use coreduo rather than core2duo since user
specifies it, but it doesn't, append qemuparams to the last can fix the
problem.
[YOCTO #11773]
(From OE-Core rev: a847dd7202a2c493788c45d11eb86866264af7a4)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
Where possible pass lists instead of strings, don't use a subshell, and call
check*() instead of using Popen directly.
(From OE-Core rev: d2374623444752af1ad748ed36b68ea58f629bf6)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
environment
MACHINE=qemux86-64 oe-selftest -r runqemu.RunqemuTests.test_boot_machine_slirp_qcow2
fails yet
oe-selftest -r runqemu.RunqemuTests.test_boot_machine_slirp_qcow2
with MACHINE in local.conf would work.
It turns out that:
runqemu slirp wic.qcow2 qemux86-64
works but:
MACHINE=qemux86-64 runqemu slirp wic.qcow2 qemux86-64
does not.
The reason are the misplaced return statements in runqemu, its skipping a block
of logic when MACHINE is set in the environment when it shouldn't. Fix this.
(From OE-Core rev: 98d113ae52cbbc88773a81a17b0933412a8e463b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
On python versions with close_fds=True (python 3.2 onwards), the tap
device lockfile isn't passed to the child process.
Since this guards against use of an active interface, we really want this
here, so pass it in pass_fds. This means if the parent exits early, the child
still holds the lock, avoiding messages like:
runqemu - ERROR - Failed to run qemu: qemu-system-x86_64: could not configure /dev/net/tun (tap0): Device or resource busy
(From OE-Core rev: 17a0a067d597c445c5892ff9914e91a2187f7e09)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Various tweaks:
- Balance up the aquire/release functions
- Use debug messge for both acquiring and release message for consistency in logs
- Use None instead of an empty string
- Reset the value of the field if we don't have the lock any more
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
subprocess.run() was introduced in Python 3.5. We currently support down to
Python 3.4 so I've replaced it with subprocess.check_call() which is available
in that version.
Signed-off-by: Michael Halstead <mhalstead@linuxfoundation.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The current handling of SIGTERM is incorrect as the process pid returned
by Popen call with shell setting to True is actualy the shell instead of
the qemu process. So use shlex to split cmd so that we can avoid using
shell=True. This ensures the child process is the actual qemu process.
Also, as we install a SIGTERM handler, we need handle the situation of
qemu terminated by SIGTERM, otherwise we will get ERROR message in such
case.
Besides, we have a problem that after running qemu, the terminal's behavior
is incorrect regarding long lines or long commands. Long commands or long
outputs should appear in multiple lines, but they appear in the same line,
overriding previous output. Use `tput smam' to fix this problem.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It solves below error:
-- snip --
return 'qemu-system-%s' % qbsys
UnboundLocalError: local variable 'qbsys' referenced before assignment
-- snip --
[YOCTO #12846]
Signed-off-by: Jagadeesh Krishnanjanappa <jkrishnanjanappa@mvista.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.
"""
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
$ runqemu qemumips64 core-image-minimal nographic qemuparams="-m 512"
...
[ 0.000000] Call Trace:
[ 0.000000] [<ffffffff801268c0>] clear_page+0x0/0x128
[ 0.000000] [<ffffffff80238158>] get_page_from_freelist+0xab8/0xc00
[ 0.000000] [<ffffffff80238964>] __alloc_pages_nodemask+0xdc/0xf68
[ 0.000000] [<ffffffff80239808>] __get_free_pages+0x18/0x70
[ 0.000000] [<ffffffff80122a4c>] setup_zero_pages+0x1c/0xb8
[ 0.000000] [<ffffffff80c7c998>] mem_init+0x54/0xa0
[ 0.000000] [<ffffffff80c74904>] start_kernel+0x204/0x4d8
[ 0.000000] [<ffffffff8091dfb0>] kernel_entry+0x0/0x40
[ 0.000000] Code: 02002025 1000f8d9 8e634d7c <34860f80> cc9e0000
cc9e0020 cc9e0040 cc9e0060 cc9e0080
[ 0.000000]
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task!
...
OE uses qemumips to simulate a Malta board by default.
As upstream qemu introduced:
https://git.qemu.org/?p=qemu.git;a=commit;h=94c2b6aff43cdfcfdfb552773a6b6b973a72ef0b
The Malta board can support up to 2GiB of RAM which should
be able to boot a Linux kernel built with CONFIG_HIGHMEM
enabled and passing "-m 2048" to QEMU and appending the
following kernel parameters:
...
mem=256M@0x0 mem=256M@0x90000000 mem=1536M@0x20000000
...
But the following commit in kernel broke above mem=X@Y setting
which added the memory as reserved memory area.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411
...
commit 73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411
Author: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Date: Wed Nov 23 14:43:49 2016 +0100
MIPS: fix mem=X@Y commandline processing
...
So remove `mem=*' to disable user-defined physical RAM map
which let kernel itself caculates memory ranges.
Author: Hongxu Jia <hongxu.jia@windriver.com>
[ Merge the two fixes for qemumips32 and qemumips64 into one patch,
and make it support all mips cases ]
Signed-off-by: He Zhe <zhe.he@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Add SIGTERM handler so that runqemu could clean things up correctly
when receving such signal.
This problem was originally observed when running testimage. On
some hosts, after running testimage task, the user has to manually
operate on the tap interface (e.g. `sudo ip link del tap0') in order
for the next runqemu command to launch successfully.
The problem is about runqemu, SIGTERM and network manager on the host.
In testimage task, the runqemu process will receive SIGTERM. In such
situation, its cleanup() function is not run, resulting in tap interface
not cleaned up. On some hosts, the network manager will bring down the
tap interface automatically, thus this problem. I saw this problem on
Fedora21.
I think we'd better just clean up the tap interface ourselves.
So this patch adds to runqemu a SIGTERM handler, in which the actual
qemu process is terminated and other things cleaned up.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
On pre 4.15 host kernels, an APIC window emulation bug can cause qemu
to hang. On 64 bit we can use the x2apic, for 32 bit, we just have to
disable the other timer sources and rely on kvm-clock.
[YOCTO #12301]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Update the runqemu script to allow the user to specify a device tree
to boot when calling runqemu.
This involves creating a seperate check_dtb() function incase the user
has specified 'none' for the kernel but still wants a device tree.
Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
Reviewed-by: Ben Levinsky <ben.levinsky@xilinx.com>
Cc: Ben Levinsky <ben.levinsky@xilinx.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Update the runqemu script to allow the user to specify a Kernel to boot
when calling runqemu.
Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
Cc: Ben Levinsky <ben.levinsky@xilinx.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
This makes debug easier.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Similarly to handling "../", handle "." to resovle to the qemuconf
file's current directory.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If a variable starts with "../", its likely its a path and we want to
set it to an absolute path relative to the qemuconf file.
This means we don't have to use bitbake as often to figure out variables.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The regexp in the script misses some tap devices, e.g. we see output like:
runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap25.lock failed: [Errno 11] Resource temporarily unavailable
runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap26.lock failed: [Errno 11] Resource temporarily unavailable
runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap27.lock failed: [Errno 11] Resource temporarily unavailable
runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap28.lock failed: [Errno 11] Resource temporarily unavailable
runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap40.lock failed: [Errno 11] Resource temporarily unavailable
runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap41.lock failed: [Errno 11] Resource temporarily unavailable
What happened to tap29 to tap39?
The issue is was we were missing devices with '0' in the number,
like "10:" and so on in the output from "ip link".
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
vm_drive variable is malformed when the drive type is an ide device.
Signed-off-by: Thomas Perrot <thomas.perrot@tupi.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Errors like:
runqemu - ERROR - Acquiring lockfile /tmp/qemu-tap-locks/tap0.lock failed: [Errno 11] Resource temporarily unavailable
are not really fatal errors. Change these to info messages instead
so people look later in the log for the real errors.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The IDE driver in the kernel is fragile and in 4.12 is causing backtraces.
To unblock 4.12 kernel merging use the virtio CD driver instead to mount
iso images which should be faster and more stable.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The vmdk/vdi/qcow2 IMAGE_FSTYPEs predate wic. As such, they provide
some similar underlying functionality in order to produce a "disk" image
that in turn can be converted into different formats that various
hypervisor types work with. They do not however provide the ability for
other disk image types to be converted into these same output types.
Furthermore, they are less flexible than what wic does provide. This
drops the old style vmdk/vdi/qcow2 types and re-introduces them under
the CONVERSION_CMD framework. The equivalent of vmdk is now wic.vmdk
and so forth for the other types.
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Multi-users may run qemu on the same host, all of them should be able to
create or remove lock in lockdir, so set lockdir's mode to 0o777.
Note, os.mkdir()'s mode is default to 0o777, but the current umask value is
first masked out, so use os.chmod() to set it.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
|
|
Error out ealier if the combos is invalid, e.g.:
$ runqemu tmp/deploy/images/qemux86/bzImage-qemux86.bin tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic
This will fail at kernel panic, no we check and error out early. We can
add other checkings in the future.
[YOCTO #11286]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
|
|
Handle them as nfs, so that cmd like the following can be boot:
$ runqemu tmp/deploy/images/qemux86/core-image-minimal-qemux86.tar.bz2
[YOCTO #11286]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
|
|
If qbconfload (.qemuboot.conf is found) is present, we can get
DEPLOY_DIR_IMAGE from it rather than "bitbake -e".
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
|
|
And move some debug info into logger.debug(), this can make it easy to
read key messages like errors or warnings.
I checked meta/lib/oeqa/ they don't depend on these messages. And I have
run "oe-selftest -a", it doesn't break anything.
[YOCTO #10474]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
|
|
Used check_output instead of Popen as it raises CalledProcessError
exception when command exits with non-zero exit code.
Catched the exception to produce user-friendly output.
[YOCTO #11719]
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Introduced custom RunQemuException that script raises on known
errors. This exception is handled in one place and prints
error output without printing Python traceback. This shoud make
error output less scary for the end user.
Handling of unknown errors has not been changed - both error and
traceback will be printed.
Reimplemented OEPathError exception code to handle it similarly
to RunQemuException.
Moved exception handling code into main() to keep it in one place.
[YOCTO #11719]
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
The following commit has removed rpc ports from runqemu-export-rootfs, so
runqemu should also remove them, otherwise "runqemu nfs" doesn't work. And use
abspath for nfsroot, otherwise it doesn't work when it is a relative path.
commit 6bb9860ef7ba9c84fe9bd3a81aa6555f67ebd38e
Author: Cody P Schafer <dev@codyps.com>
Date: Tue Jun 6 18:30:49 2017 -0400
runqemu-export-rootfs: don't change RPC ports
[YOCTO #11687]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
runqemu uses stty to change terminal settings to give users
better control to qemu. However, stty does not work when
runqemu is run directly or indirectly via oe-selftest in
a Docker container (presumably some problems with Docker's
pseudo-tty implementation).
The error reported is:
stty: 'standard input': Inappropriate ioctl for device
As runqemu recently moved to subprocess.check_call() for
stty calls we now get thrown an error and all runqemu
runs fail.
sys.stdin.isatty() does proper job in detecting if the stty
calls can work so we use that check before running the stty
subprocess operations.
Signed-off-by: Mikko Ylinen <mikko.ylinen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Python function subprocess.call() returns the return value of the
executed process. If return values are not checked, errors may
go unnoticed and bad things can happen.
Change all callers of subprocess.call() which do not check for
the return value to use subprocess.check_call() which raises
CalledProcessError if the subprocess returns with non-zero value.
https://docs.python.org/2/library/subprocess.html#using-the-subprocess-module
All users of the function were found with:
$ git grep "subprocess\.call" | \
egrep -v 'if.*subprocess\.call|=\ +subprocess\.call|return.*subprocess\.call'
Tested similar patch on top of yocto jethro. Only compile tested
core-image-minimal on poky master branch.
Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Included error output from qemu-system into the runqemu error message.
Made error output more visible by printing new line before it.
[YOCTO #11542]
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When booting QEMU with slirp networking we want to use QEMUs TFTP server
to make the images in deploy accessible to the guest.
Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Setting QB_DRIVE_TYPE=/dev/vd selects virtio without triggering any
warnings. Previously, that was only possible by setting an unknown
value and relying on the fallback to virtio, which caused some
warnings to be printed.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
We were specifying a default parameter; the get() function defined here
does not take such a parameter. I appears this code had not been tested.
This fixes runqemu erroring out immediately when used within the eSDK.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Used self.bindir_native to point out to the native sysroot
when running runqemu-ifup and runqemu-ifdown scripts.
[YOCTO #11266]
[YOCTO #11193]
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Isolated logic of getting path to native bin directory in
new bindir_native property method.
This property is going to be used to obtain location of
qemu-sytem and tunctl.
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If rm_work is enabled image native sysroot can be removed.
This makes runqemu to fail trying to find qemu binary.
Used native sysroot of qemu-helper-native to find system qemu
binary.
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We can use self.rootfs as self.nfs_dir when self.fstype is nfs, this can
reduce the code's complexity and we can re-use the code of checking
ROOTFS conflictions.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Fixed when the image is large and not enough memory:
grep: memory exhausted
Aborted
[YOCTO #11073]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Since we can get MACHINE and others from env vars and "bitbake -e",
"runqemu" can work without any arguments.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Use self.env_vars to support get vars from environment explicity. The
MACHINE, ROOTFS and KERNEL was supported by shell based runqemu, and
the help text says support them from env vars, so add them back.
[YOCTO #11141]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The DEPLOY_DIR_IMAGE maybe relative or absolute path since it can be
read from env vars, so use realpath for both imgdir and
DEPLOY_DIR_IMAGE when compare.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* "is it" -> "it is"
* Remove "<image>.qemuboot.conf =" in the error message which looked strange.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
runqemu adds network configuration parameters to the kernel
command line to configure guest networking. This works only
for the images that run with external kernel using qemu -kernel
parameter. It doesn't work for the images that use bootloader
to boot kernel as -kernel parameter is not used and network
configuration is not possible to get.
Added host and guest ip addresses and netmask of tap link
to the runqemu output. This should allow external programs
that execute runqemu to get network configuration.
[YOCTO #10833]
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This can fix a problem:
IMAGE_FSTYPES += "iso"
$ bitbake core-image-minimal
$ runqemu qemux86
It may boot core-image-minimal-initramfs rather than core-image-minimal, this
is not what we want usually. This patch makes it avoid booting ramfs when there
are other choices, or when it is specified, for example, "runqemu qemux86 ramfs"
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|