New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
can qemu be used from the container? #11
Comments
Hi Yannick, I'm assuming you are getting an error saying it can't create a tap device? There are a couple of ways around this if you're on Linux. But assuming you are using a new enough version of poky/oe-core, runqemu should support "slirp" which would even work if using MacOS or Windows. And it is the simplest to try. Try the command below and see if it works:
The slirp argument says to use usermode networking which doesn't need a tap device. The nographic will prevent an error from SDL saying it can't connect to the display, and cause the output to just go to your console. If this works, let us know. And if you have more issues please ask. Because these kind of questions we'll try to answer in the wiki as well. |
ykoehler@yk-z620 ~/HPE-Aruba-ap-unified/poky $ build.sh "TEMPLATECONF=meta-uap/conf source oe-init-build-env && runqemu qemux86 ramfs slirp nographic" Shell environment set up for builds.You can now run 'bitbake ' runqemu - INFO - Assuming MACHINE = qemux86 It seems that runqemu call "check_tun" even if I specify the slirp option. |
Hi,
I just did
runqemu qemux86 qemux86-64 slirp nographic
and it worked.
I was using the following poky commitish on master:
7e0985bab68547f946163828a16beab7542fca2e
…----
I had to add no graphic as the change to enable vnc graphics on the poky
containers has not made it in yet, though the necessary infrastructure is
there.
-b
an intel employee
On Fri, Mar 17, 2017 at 12:14 PM, Yannick Koehler ***@***.***> wrote:
***@***.*** ~/HPE-Aruba-ap-unified/poky $ build.sh
"TEMPLATECONF=meta-uap/conf source oe-init-build-env && runqemu qemux86
ramfs slirp nographic"
latest: Pulling from hpe-aruba-ap-unified/poky-container
Digest: sha256:d5198553c2efa98c4fa1f94d74258b
dacc6e17973c2b9af9938d0d4771183562
Status: Image is up to date for hub.docker.hpecorp.net/hpe-
aruba-ap-unified/poky-container:latest
Shell environment set up for builds.
You can now run 'bitbake '
runqemu - INFO - Assuming MACHINE = qemux86
runqemu - INFO - Running MACHINE=qemux86 bitbake -e...
runqemu - INFO - MACHINE: qemux86
runqemu - INFO - DEPLOY_DIR_IMAGE: /workdir/build/tmp/deploy/
images/qemux86
runqemu - INFO - Running ls -t /workdir/build/tmp/deploy/
images/qemux86/*.qemuboot.conf...
runqemu - INFO - CONFFILE: /workdir/build/tmp/deploy/
images/qemux86/core-image-minimal-qemux86-20170317182653.qemuboot.conf
Traceback (most recent call last):
File "/workdir/scripts/runqemu", line 1019, in
ret = main()
File "/workdir/scripts/runqemu", line 1007, in main
config.check_and_set()
File "/workdir/scripts/runqemu", line 545, in check_and_set
check_tun()
File "/workdir/scripts/runqemu", line 102, in check_tun
raise Exception("TUN control device %s is unavailable; you may need to
enable TUN (e.g. sudo modprobe tun)" % dev_tun)
Exception: TUN control device /dev/net/tun is unavailable; you may need to
enable TUN (e.g. sudo modprobe tun)
It seems that runqemu call "check_tun" even if I specify the slirp option.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#11 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACkxjZJXnR-lOgUBVKSJUNZQq_gU1E2Sks5rmtuqgaJpZM4Mg5-6>
.
|
Yannick, Which version of poky are you based on? There are ways we could get it to work, but before I suggest something, I want to make sure I can try and verify it works. |
So, did some small digging, it works for you because you probably have the tun module loaded on your host. I do not, as such, whenever I try to launch qemu it says that the /dev/net/tun device is missing, because the runqemu script calls check_tun even if you specify to use slirp. I edited the script to comment out this sanity check_tun function and now I am able to get this working within docker. |
Using morty at this time.
…On Mon, Mar 20, 2017 at 3:55 PM Randy Witt ***@***.***> wrote:
Yannick,
Which version of poky are you based on? There are ways we could get it to
work, but before I suggest something, I want to make sure I can try and
verify it works.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#11 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACnOj-IEV81Y54Fh3ntinf1jYQ-SN9zIks5rntmcgaJpZM4Mg5-6>
.
|
I see.
Yes, in master it now has:
if not self.slirp_enabled:
check_tun()
But morty doesn't have the conditional.
Thanks for the targeted feedback!!
…-Brian
an Intel employee
On Mon, Mar 20, 2017 at 4:54 PM, Yannick Koehler <notifications@github.com>
wrote:
Using morty at this time.
On Mon, Mar 20, 2017 at 3:55 PM Randy Witt ***@***.***>
wrote:
> Yannick,
>
> Which version of poky are you based on? There are ways we could get it to
> work, but before I suggest something, I want to make sure I can try and
> verify it works.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#11#
issuecomment-287878474>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ACnOj-
IEV81Y54Fh3ntinf1jYQ-SN9zIks5rntmcgaJpZM4Mg5-6>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#11 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACkxjbFSLcnqEE_R0y5Tc0J60f-Z7Kw9ks5rnxGZgaJpZM4Mg5-6>
.
|
Note if you add |
I think it's Also, setting up the tap interface requires root access in the container, via sudo, but |
I am having the same issue at @DavidAntliff , I get prompted for the password for
|
I was unable to get the command "runqemu qemux86 ramfs" to work.
Is there a way to get it supported?
The text was updated successfully, but these errors were encountered: