How to run runqemu with KAS?

[Jörg Sommer]

Hello,

I'm making my first steps with KAS and Yocto and struggeling with running runqemu. So far, the qemu image gets built and I can start it with runqemu, but I have to pass some special options to kas-container to make networking work. At first, I have to pass `--runtime-args '--cap-add=NET_ADMIN --device /dev/net/tun'` to get the TUN device inside of the container. Without it, runqemu fails with

```text

runqemu - INFO - Running bitbake -e ...

runqemu - INFO - Overriding conf file setting of STAGING_DIR_NATIVE to /build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native from Bitbake environment

runqemu - ERROR - TUN control device /dev/net/tun is unavailable; you may need to enable TUN (e.g. sudo modprobe tun)

runqemu - INFO - Cleaning up

runqemu - INFO - Host uptime: 624489.99

```

And then I have to inject iptables with `--runtime-args '-v /sbin/iptables:/sbin/iptables:ro'` otherwise it fails with

```text

runqemu - INFO - Running bitbake -e ...

runqemu - INFO - Overriding conf file setting of STAGING_DIR_NATIVE to /build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native from Bitbake environment

runqemu - INFO - Continuing with the following parameters:

KERNEL: [/build/tmp/deploy/images/qemux86-64/bzImage--5.15.68+git0+1128d7bcdc_0e51e57170-r0-qemux86-64-20230512084234.bin]

MACHINE: [qemux86-64]

FSTYPE: [ext4]

ROOTFS: [/build/tmp/deploy/images/qemux86-64/ctn-base-image-qemux86-64-20230512114437.rootfs.ext4]

CONFFILE: [/build/tmp/deploy/images/qemux86-64/ctn-base-image-qemux86-64-20230512114437.qemuboot.conf]

runqemu - INFO - Setting up tap interface under sudo

runqemu - ERROR - Setting up tap device failed:

Command '('sudo', '/work/layers-3rdparty/poky/scripts/runqemu-ifup', '1001', '1001', '/build/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin')' returned non-zero exit status 1.

Run runqemu-gen-tapdevs to manually create one.

runqemu - INFO - Cleaning up

runqemu - INFO - Host uptime: 624714.73

```

What's the right way of doing this, esp. getting iptables in the container?

Kind regards

Jörg Sommer Software Developer / Programmierer
Navimatix GmbH Tatzendpromenade 2 07745 Jena	T: 03641 - 327 99 0 F: 03641 - 526 306 M: max.muste...@navimatix.de www.navimatix.de
Geschäftsführer: Steffen Späthe, Jan Rommeley Registergericht: Amtsgericht Jena, HRB 501480 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

[Jan Kiszka]

I would rather use userspace networking with runqemu because that needs
no tun devices and related privileges.

But note that the kas containers are build containers, not test
environments per se. If some tests happen to work, that is more by
chance than by design. If we added all dependencies needed for the
various test frameworks out there, the build containers would only
become larger and also harder to maintain.

If you want to have such a container, you could
- derive a locally built one from the kas base container
- lobby for a generic, kas-provided one here, collecting opinions from
others that may have a similar demand

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux

[Jörg Sommer]

On May 15, 2023 8:30 AM, Jan Kiszka wrote:

> On 12.05.23 15:37, 'Jörg Sommer' via kas-devel wrote:

> > What's the right way of doing this, esp. getting iptables in the container?

>

> I would rather use userspace networking with runqemu because that needs

> no tun devices and related privileges.

>

> But note that the kas containers are build containers, not test

> environments per se.

So, just for my understanding: it's not intended to run runqemu in the container, right?

I've tries to use runqemu from outside, but `bitbake -e` fails, because bblayers.conf is set up for the environment (direcotries ../work, ../repo) in the container. It looks a bit like a dead-lock.

With kind regards,

[Jan Kiszka]

On 15.05.23 10:56, Jörg Sommer wrote:
> On May 15, 2023 8:30 AM, Jan Kiszka wrote:
>> On 12.05.23 15:37, 'Jörg Sommer' via kas-devel wrote:
>> > What's the right way of doing this, esp. getting iptables in the
> container?
>>
>> I would rather use userspace networking with runqemu because that needs
>> no tun devices and related privileges.
>>
>> But note that the kas containers are build containers, not test
>> environments per se.
>
> So, just for my understanding: it's not intended to run runqemu in the
> container, right?

Yes. We can address simple missing deps in the build container if they
help simple tests, but we can't pull in a large set of extra packages
because of the mentioned implications.

BTW, did you build qemu as host tool via yocto, or where was it coming
from? Did userspace networking help, or do you depend on bridged networking?

>
> I've tries to use runqemu from outside, but `bitbake -e` fails, because
> bblayers.conf is set up for the environment (direcotries ../work,
> ../repo) in the container. It looks a bit like a dead-lock.
>

Right, the directory layout inside the container is generally different
from the calling environment. In addition, the purpose of the kas
container is that you do not need the bitbake deps on the host. So,
either do not use the container, live with the limitation of the build
container, or derive a custom one that overcomes them.