On Tue, 17 Mar 2015, Guido Günther wrote: > This is a special setup that fails to parse the capabilities using a > qemu wrapper on x32 to run in a x86_64 chroot (as far as I understand
It also fails to parse them *without* the chroot, with… <emulator>/usr/bin/kvm</emulator> … which is what virt-manager creates. But that’s probably a bug in the qemu-kvm package (plus one in virt-manager if /usr/bin/kvm is not supposed to be used). Changing it to… <emulator>/usr/bin/qemu-system-x86_64</emulator> … and changing <domain type='kvm'> to <domain type='qemu'> makes this succeed, so that’s unrelated. (Mentioning this because I mentioned it earlier in this bugreport, so we know this is not the problem.) > case if somebody else wants to step in having your schroot and vm > configuration would help. OK. A small reproducer is here: <domain type='kvm'> <name>d-i-amd64</name> <uuid>2affcd84-73f4-bbb2-2fd5-fd920b9806b7</uuid> <memory unit='KiB'>524288</memory> <currentMemory unit='KiB'>524288</currentMemory> <vcpu placement='static'>1</vcpu> <os> <type arch='x86_64' machine='pc-1.1'>hvm</type> <boot dev='network'/> </os> <features> <acpi/> <apic/> <pae/> </features> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/local/bin/qemu-in-chroot</emulator> <controller type='usb' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> <controller type='pci' index='0' model='pci-root'/> <interface type='bridge'> <mac address='52:54:00:02:9c:44'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <input type='tablet' bus='usb'/> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <graphics type='vnc' port='-1' autoport='yes'/> <video> <model type='cirrus' vram='9216' heads='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </memballoon> </devices> </domain> The other files (hopefully all relevant ones) are: /etc/schroot/schroot.conf: [sid-amd64] description=Debian sid/amd64 (unstable) type=directory directory=/home/AMD64 root-users=libvirt-qemu,tglase,root #personality=linux64 command-prefix=linux64,eatmydata setup.fstab=fstab.qemu sed 's/^X//' >etc/schroot/fstab.qemu << 'END-of-etc/schroot/fstab.qemu' X# fstab: static file system information for chroots. X# Note that the mount point will be prefixed by the chroot path X# (CHROOT_PATH) X# X# <file system> <mount point> <type> <options> <dump> <pass> X/proc /proc none rw,bind 0 0 X/sys /sys none rw,bind 0 0 X/dev /dev none rw,bind 0 0 X/dev/pts /dev/pts none rw,bind 0 0 X/home /home none rw,bind 0 0 X/tmp /tmp none rw,bind 0 0 X X# It may be desirable to have access to /run, especially if you wish X# to run additional services in the chroot. However, note that this X# may potentially cause undesirable behaviour on upgrades, such as X# killing services on the host. X#/run /run none rw,bind 0 0 X#/run/lock /run/lock none rw,bind 0 0 X#/dev/shm /dev/shm none rw,bind 0 0 X/run/shm /run/shm none rw,bind 0 0 X X/var/lib/libvirt /var/lib/libvirt none rw,bind 0 0 X/var/cache/pbuilder /var/cache/pbuilder none rw,bind 0 0 END-of-etc/schroot/fstab.qemu > I'd be also good to have the requested logs at debug level. There > might already be the solution in there. I’d sent them to you already, in separate direct eMail, due to size. > > In the meantime, I downgraded libvirt0 (and the three dependants > > libvirt-clients libvirt-daemon libvirt-daemon-system) to 1.2.9-8 > > from 1.2.9-9, and my VMs start up again. > > > > So, whatever you did in 1.2.9-9, it introduced a severe regression. > > It fixed a severe regression on since it didn't fall back to broken > help parsing preventing VMs to start on fresh installations. Let’s meet in the middle and say it swapped a severe regression with another severe regression. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org