openembedded-core.git/scripts/runqemu, branch uninative-1.5

scripts/runqemu: avoid overridden user input for bootparams

2017-03-04T10:42:33+00:00

Currently runqemu hardcodes the "ip=" kernel boot parameter
when configuring QEMU to use tap or slirp networking. This makes
the guest system to have a network interface pre-configured
by kernel and causes systemd to fail renaming the interface
to whatever pleases it:

  Feb 21 10:10:20 intel-corei7-64 systemd-udevd[201]: Error changing
      net interface name 'eth0' to 'enp0s3': Device or resource busy,

Always append user input for kernel boot params after the ones
added by the script. This way user input has priority over runqemu's
default params.

Signed-off-by: Dmitry Rozhkov 
Signed-off-by: Ross Burton

scripts/runqemu: Add always ttyS1 when no serial options are specified

2017-03-04T10:42:33+00:00

We always wants ttyS0 and ttyS1 in qemu machines (see SERIAL_CONSOLES),
if not serial or serialtcp options was specified only ttyS0 is created
and sysvinit shows an error trying to enable ttyS1:

     INIT: Id "S1" respawning too fast: disabled for 5 minutes

[YOCTO #10491]

(From OE-Core rev: 3a0efbbe6bb5a7f0fb3df0f6052b11e56788405f)

Signed-off-by: Aníbal Limón 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie

runqemu: support UEFI with OVMF firmware

2017-02-28T11:26:32+00:00

In the simplest case, "runqemu qemux86  qcow2 ovmf" for an
EFI-enabled image in the qcow2 format will locate the ovmf.qcow2
firmware file deployed by the ovmf recipe in the image deploy
directory, override the graphics hardware with "-vga std" because that
is all that OVMF supports, and boot with UEFI enabled.

ovmf is not built by default. Either do it explicitly ("bitbake ovmf")
or make it a part of the normal build
("MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append = ' ovmf'").

The firmware file is activated as a flash drive instead of using the
qemu BIOS parameters, because that is the recommended method
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764918#47) as it
allows storing UEFI variables in the file.

Instead of just "ovmf", a full path to an existing file can also be
used, just as with the rootfs. That may be useful when making a
permanent copy of the virtual machine data files.

It is possible to specify "ovmf*" parameters more than once, then
each parameter creates a separate flash drive. This way it is possible
to use separate flash drives for firmware code and variables:
$ runqemu qemux86  qcow2 ovmf.code ovmf.vars"

Note that rebuilding ovmf will overwrite the ovmf.vars.qcow2 file in
the image deploy directory. So when the goal is to update the firmware
while keeping variables, make a copy of the variable file and use
that:
$ mkdir my-machine
$ cp tmp/deploy/images/qemux86/ovmf.vars.qcow2 my-machine/
$ runqemu qemux86  qcow2 ovmf.code my-machine/ovmf.vars.qcow2

When Secure Boot was enabled in ovmf, one can pick that instead of
the non-Secure-Boot enabled ovmf.code:
$ runqemu qemux86  qcow2 ovmf.secboot.code my-machine/ovmf.vars.qcow2

Signed-off-by: Patrick Ohly

runqemu: also accept -image suffix for rootfs parameter

2017-02-28T11:26:32+00:00

The magic detection of the rootfs parameter only worked for image
recipes which embedd the "image" string in the middle, as in
"core-image-minimal".

Sometimes it is more natural to call an image "something-image". To
get such an image detected by runqemu, "-image" at the end of a
parameter must also cause that parameter to be treated as the rootfs
parameter.

Inside the image directory, "something-image" has an - suffix
and thus no change is needed for those usages of
re.search('-image-'). However, while at it also enhance those string
searches a bit (no need for re; any()+map() a bit closer to the
intended logic).

Signed-off-by: Patrick Ohly

runqemu: fix undefined variable reference in check_arg_path()

2017-02-28T11:26:32+00:00

'arg' isn't defined, the right name there is 'p'.

This fixes a rather obscure error message when that code path
ends up being taken:

$ runqemu some/existing-file-name
runqemu - ERROR - name 'arg' is not defined
runqemu - ERROR - Try 'runqemu help' on how to use it

Signed-off-by: Patrick Ohly

scripts/runqemu: fix a typo

2017-02-02T17:37:36+00:00

Signed-off-by: Ming Liu 
Signed-off-by: Ross Burton

runqemu: allow bypassing of network setup

2017-01-31T14:40:18+00:00

At present it is silently assumed all QEMU machines support networking.
As a consequence, one cannot run QEMUs without network emulation
using "runqemu".
This patch allows bypassing any network setup providing the qemuboot.conf
file contains:

    qb_net = none

[YOCTO#10661]

Signed-off-by: Juro Bystricky 
Signed-off-by: Ross Burton

runqemu: more verbose error message about missing qemuboot.conf

2017-01-26T10:41:10+00:00

When invoking "runqemu" with a mistyped image or architecture name,
the resulting error message is about the missing qemuboot.conf,
without any indication about the root cause:

 $ runqemu core-image-mimimal ext4 intel-corei7-64
 runqemu - INFO - Assuming MACHINE = intel-corei7-64
 runqemu - INFO - Running MACHINE=intel-corei7-64 bitbake -e...
 runqemu - INFO - MACHINE: intel-corei7-64
 runqemu - INFO - DEPLOY_DIR_IMAGE: /fast/build/refkit/intel-corei7-64/tmp-glibc/deploy/images/intel-corei7-64
 Traceback (most recent call last):
   File "/work/openembedded-core/scripts/runqemu", line 1095, in 
     ret = main()
   File "/work/openembedded-core/scripts/runqemu", line 1082, in main
     config.read_qemuboot()
   File "/work/openembedded-core/scripts/runqemu", line 643, in read_qemuboot
     raise Exception("Failed to find .qemuboot.conf!")
 Exception: Failed to find .qemuboot.conf!

Including the name of the actual file the scripts expects to find plus
adding some hints what to check for might help. The error now is:

 $ runqemu core-image-mimimal ext4 intel-corei7-64
 ...
 Exception: Failed to find .qemuboot.conf = .../tmp-glibc/deploy/images/intel-corei7-64/core-image-mimimal-intel-corei7-64.qemuboot.conf (wrong image name or BSP does not support running under qemu?).

The comment about the BSP is included because that would be the real
reason why the file might be missing.

Signed-off-by: Patrick Ohly 
Signed-off-by: Richard Purdie

runqemu: fixes for slirp, network device and hostfwd

2017-01-23T12:04:00+00:00

Fixed:
- Add QB_NETWORK_DEVICE to set network device, it will be used by both
  slirp and tap.
- Set QB_NETWORK_DEVICE to "-device virtio-net-pci" in qemuboot.bbclass
  but runqemu will default to "-device e1000" when QB_NETWORK_DEVICE is
  not set, this is because oe-core's qemu targets support
  virtio-net-pci, but the one outside of oe-core may not,
  "-device e1000" is more common.
- Set hostfwd by default: 2222 -> 22, 2323 -> 23, and it will choose a
  usable port when the one like 222 is being used. This can avoid
  conflicts when multilib slirp qemus are running. We can forward more
  ports by default if needed, and bsp.conf can custom it.
- Use different mac sections for slirp and tap to fix conflicts when
  running both of them on the same host.

[YOCTO #7887]

CC: Nathan Rossi 
CC: Randy Witt 
Signed-off-by: Robert Yang

runqemu: support multiple qemus running when nfs

2017-01-23T12:04:00+00:00

Fixed:
* In build1:
  $ runqemu nfs qemux86-64
  In build2:
  $ runqemu nfs qemux86-64

  It would fail before since the port numerbs and conf files are
  conflicted, now make runqemu-export-rootfs work together with runqemu to
  fix the problem.

* And we don't need export PSEUDO_LOCALSTATEDIR in runqemu, the
  runqemu-export-rootfs can handle it well based on NFS_EXPORT_DIR.

* Remove "async" option from unfsd to fix warning in syslog:
  Warning: unknown exports option `async' ignored

* Fixed typos

Both slirp and tap can work.

Signed-off-by: Robert Yang