=app-emulation/qemu-kvm-1.1.0 might not build due to missing checks in ebuild wrt "virtfs" feature and needs a new $USE for "virtfs" Reproducible: Always To enable the "virtfs"-feature, a simple $(use_enable xattr virtfs) was added to src_configure() This is not enough and needs to be an additional USE-flag. See http://wiki.qemu.org/Documentation/9psetup for things to check: - >=sys-kernel/*-sources-2.6.36 - CONFIG_NET_9P=y && CONFIG_NET_9P_VIRTIO=y && CONFIG_9P_FS=y && CONFIG_9P_FS_POSIX_ACL=y - USE=xattr Personally, I've left out the Plan9 things in the Kernel and the build failed with: * Building the following user targets: i386-linux-user x86_64-linux-user ERROR ERROR: User requested feature virtfs ERROR: configure was not able to find it ERROR * ERROR: app-emulation/qemu-kvm-1.1.0 failed (configure phase):
The kernel options shouldn't be required for compilation but I've hidden this behind a USE flag for now and added the check for the kernel options. Thanks for the report.
Hey, I wanna put some input on this bug. I know it's closed but I just noticed the new warn messages in the ebuild.. and I don't think they are entirely accurrate. Before the virtfs use flag I had virtfs working fine (with libvirt) and dont' have any 9P options set on the kernel on the host. The 9P options do need to be set on the guest, however. This has been working fine for me for a while now, however with the new virtfs USE flag I get the following warnings on my host: --- * Checking for suitable kernel configuration options... * If you have an AMD CPU, you must enable KVM_AMD in your kernel configuration. * CONFIG_NET_9P: is not set when it should be. * CONFIG_NET_9P_VIRTIO: is not set when it should be. * CONFIG_9P_FS: is not set when it should be. * CONFIG_9P_FS_POSIX_ACL: is not set when it should be. --- Again, this shouldn't be needed for the host: $ zgrep 9P /proc/config.gz # CONFIG_NET_9P is not set Has worked just fine for me for a good while now. All the 9P stuff on the host side seems to be handled entirely in userspace by qemu-kvm without any need for kernel support. The *guest* however, does need 9P kernel options $ zgrep 9P /proc/config.gz CONFIG_NET_9P=y CONFIG_NET_9P_VIRTIO=y # CONFIG_NET_9P_DEBUG is not set CONFIG_9P_FS=y CONFIG_9P_FS_POSIX_ACL=y $ mount|grep 9p /dev/portage on /var/portage type 9p (rw,trans=virtio) Anyway, I'm not sure why the person who submitted the bug got a build error, but I don't think it was because of lack of 9P on the host. So this new warning I think is erroneous.
Ok - tried to reproduce the build error: (I've reduced some settings from my make.conf to some minimum through command line override) hzn2 ~ # QEMU_SOFTMMU_TARGETS="x86_64" QEMU_USER_TARGETS="x86_64" LC_ALL=C FEATURES= MAKEOPTS= ACCEPT_KEYWORDS=~amd64 USE="virtfs" emerge -1v =app-emulation/qemu-kvm-1.1.0 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] app-emulation/qemu-kvm-1.1.0 [1.0.1] USE="aio curl ncurses sasl vde vhost-net xattr -alsa -bluetooth -brltty -debug -doc% -fdt -opengl -pulseaudio -python% (-rbd) -sdl -smartcard -spice -static -tci% -tls -usbredir -xen -xfs% (-qemu-ifup%) (-test%) (-threads%*)" QEMU_SOFTMMU_TARGETS="x86_64 -alpha% -arm -cris -i386* -m68k -microblaze -microblazeel% -mips -mips64 -mips64el -mipsel -ppc -ppc64 -ppcemb -s390x% -sh4 -sh4eb -sparc -sparc64 -xtensa% -xtensaeb%" QEMU_USER_TARGETS="x86_64 -alpha -arm -armeb -cris -i386* -m68k -microblaze -microblazeel% -mips -mipsel -ppc -ppc64 -ppc64abi32 -s390x% -sh4 -sh4eb -sparc -sparc32plus -sparc64 -unicore32%" 0 kB Total: 1 package (1 upgrade), Size of downloads: 0 kB >>> Verifying ebuild manifests >>> Running pre-merge checks for app-emulation/qemu-kvm-1.1.0 * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found sources for kernel version: * 3.4.4-vs2.3.3.5 * Checking for suitable kernel configuration options... * If you have an Intel CPU, you must enable KVM_INTEL in your kernel configuration. * Please check to make sure these options are set correctly. * Failure to do so may cause unexpected problems. >>> Emerging (1 of 1) app-emulation/qemu-kvm-1.1.0 * qemu-kvm-1.1.0.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * qemu-kvm-1.1.0-bp-1.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking qemu-kvm-1.1.0.tar.gz to /var/tmp/portage/app-emulation/qemu-kvm-1.1.0/work >>> Unpacking qemu-kvm-1.1.0-bp-1.tar.xz to /var/tmp/portage/app-emulation/qemu-kvm-1.1.0/work >>> Source unpacked in /var/tmp/portage/app-emulation/qemu-kvm-1.1.0/work >>> Preparing source in /var/tmp/portage/app-emulation/qemu-kvm-1.1.0/work/qemu-kvm-1.1.0 ... * Converting shebang in '/var/tmp/portage/app-emulation/qemu-kvm-1.1.0/work/qemu-kvm-1.1.0/scripts/kvm/kvm_stat' * Applying various patches (bugfixes/updates) ... * 0001-Add-query-events-command-to-QMP-to-query-async-event.patch ... [ ok ] * 0002-qemu-kvm-Add-missing-default-machine-options.patch ... [ ok ] * 0003-qemu-kvm-virtio-Do-not-register-mask-notifiers-witho.patch ... [ ok ] * Done with patching >>> Source prepared. >>> Configuring source in /var/tmp/portage/app-emulation/qemu-kvm-1.1.0/work/qemu-kvm-1.1.0 ... * Building the following softmmu targets: x86_64-softmmu * Building the following user targets: x86_64-linux-user ERROR ERROR: User requested feature virtfs ERROR: configure was not able to find it ERROR * ERROR: app-emulation/qemu-kvm-1.1.0 failed (configure phase): * configure failed * * Call stack: * ebuild.sh, line 85: Called src_configure * environment, line 5815: Called die * The specific snippet of code: * ./configure --prefix=/usr --sysconfdir=/etc --disable-bsd-user --disable-libiscsi --disable-strip --disable-werror --enable-guest-agent --enable-pie --enable-vnc-jpeg --enable-vnc-png --enable-vnc-thread --python=python2 $(use_enable aio linux-aio) $(use_enable bluetooth bluez) $(use_enable brltty brlapi) $(use_enable curl) $(use_enable debug debug-info) $(use_enable debug debug-mon) $(use_enable debug debug-tcg) $(use_enable doc docs) $(use_enable fdt) $(use_enable kernel_linux kvm) $(use_enable kernel_linux kvm-device-assignment) $(use_enable kernel_linux nptl) $(use_enable kernel_linux uuid) $(use_enable ncurses curses) $(use_enable opengl) $(use_enable rbd) $(use_enable sasl vnc-sasl) $(use_enable sdl) $(use_enable smartcard smartcard) $(use_enable smartcard smartcard-nss) $(use_enable spice) $(use_enable tci tcg-interpreter) $(use_enable tls vnc-tls) $(use_enable usbredir usb-redir) $(use_enable vde) $(use_enable vhost-net) $(use_enable xattr attr) $(use_enable xattr virtfs) $(use_enable xen) $(use_enable xfs xfsctl) --audio-drv-list="${audio_opts}" --target-list="${softmmu_targets} ${user_targets}" --cc="$(tc-getCC)" --host-cc="$(tc-getBUILD_CC)" ${conf_opts} || die "configure failed"; * * If you need support, post the output of `emerge --info '=app-emulation/qemu-kvm-1.1.0'`, * the complete build log and the output of `emerge -pqv '=app-emulation/qemu-kvm-1.1.0'`. * The complete build log is located at '/var/tmp/portage/app-emulation/qemu-kvm-1.1.0/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/app-emulation/qemu-kvm-1.1.0/temp/environment'. * Working directory: '/var/tmp/portage/app-emulation/qemu-kvm-1.1.0/work/qemu-kvm-1.1.0' * S: '/var/tmp/portage/app-emulation/qemu-kvm-1.1.0/work/qemu-kvm-1.1.0' >>> Failed to emerge app-emulation/qemu-kvm-1.1.0, Log file: >>> '/var/tmp/portage/app-emulation/qemu-kvm-1.1.0/temp/build.log' I'll attach the config.log as the build.log does not show more information than above.
Created attachment 317870 [details] Log from failing ./configure while looking through the Log, I see two error lines stating "sys/capability.h" (and another "sys/endian.h" not found) which really are not anywhere on the system... a quick "equery belongs /usr/include/sys/capability.h" on another system revealed "sys-libs/libcap-2.22". After I emerged sys-libs/libcap on this system the configure went through w/o any failure!! So there's a missing dependency to sys-libs/libcap with "virtfs" enabled!
I see what the issue is. Its related to libcap which is apparently always used for virtfs, even when you tell the system to use libcap-ng over libcap.
Alright the whole thing should be fixed once and for all in CVS now. We're not checking the host for Plan 9 support and we're supporting both libcap and libcap-ng correctly now.
(In reply to comment #6) > Alright the whole thing should be fixed once and for all in CVS now. We're > not checking the host for Plan 9 support and we're supporting both libcap > and libcap-ng correctly now. Awesome, thanks! -a
