Bug 3751

Summary:	runqemu doesn't work on Fedora 17
Product:	[Build System, Metadata & Runtime] OE-Core	Reporter:	Tom Zanussi <tom.zanussi>
Component:	virtual machines	Assignee:	Richard Purdie <richard.purdie>
Status:	RESOLVED WORKSFORME	QA Contact:
Severity:	normal
Priority:	Undecided	CC:	Qi.Chen
Version:	unspecified
Target Milestone:	---
Hardware:	x86
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	---

Description Tom Zanussi 2013-01-18 00:33:35 UTC

With a scratch build of qemux86 sato poky/master commit: 64592f76264d8c1e590647a57e9c773edbf782e5

runqemu fails due apparently to some networking problem on Fedora 17, while the same commit works fine on Ubuntu 11.10:

[trz@empanada build]$ runqemu qemux86

Continuing with the following parameters:
KERNEL: [/home/trz/yocto/qemu-test/build/tmp/deploy/images/bzImage-qemux86.bin]
ROOTFS: [/home/trz/yocto/qemu-test/build/tmp/deploy/images/core-image-sato-qemux86.ext3]
FSTYPE: [ext3]
Acquiring lockfile for tap0...
Using preconfigured tap device 'tap0'
WARNING: distccd not present, no distcc support loaded.
Running qemu-system-i386...
/home/trz/yocto/qemu-test/build/tmp/sysroots/x86_64-linux/usr/bin/qemu-system-i386 -kernel /home/trz/yocto/qemu-test/build/tmp/deploy/images/bzImage-qemux86.bin -net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=no,downscript=no -hda /home/trz/yocto/qemu-test/build/tmp/deploy/images/core-image-sato-qemux86.ext3 -show-cursor -usb -usbdevice wacom-tablet -vga vmware -no-reboot -m 128 --append "vga=0 root=/dev/hda rw mem=128M ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 "
qemu-system-i386: -net tap,vlan=0,ifname=tap0,script=no,downscript=no: could not configure /dev/net/tun (tap0): Permission denied
qemu-system-i386: -net tap,vlan=0,ifname=tap0,script=no,downscript=no: Device 'tap' could not be initialized
[sudo] password for trz: 
Releasing lockfile of preconfigured tap device 'tap0'

Comment 1 Chen Qi 2013-01-18 07:12:31 UTC

I once killed the 'runqemu' process by a 'kill -9 xxx' command, and next time I ran 'runqemu xxx', this error was encountered. 
After examining the scripts a little bit, I found that it was because that the cleanup function was not executed if the 'runqemu' process was kill.
So I simply rebooted it, and everything was OK.

Is it the same case with yours?

Maybe we could add a 'clean' option to runqemu to force it do cleanup, something like 'runqemu clean'. 
In this way, we can correctly do some cleanup in case the 'runqemu' process is killed by accident.

Comment 2 Tom Zanussi 2013-01-18 15:44:10 UTC

In my case, the process was never killed - the failures I see always happen are first runs.

Comment 3 Tom Zanussi 2013-01-20 23:26:01 UTC

I'm quite sure I never killed the runqemu process to cause this.  Nonetheless I don't see the problem after a fresh reboot, and Saul can't reproduce it on Fedora18.

So I'm closing this as not reproducible at the moment.