GNOME Boxes won't run any virtual machines
Closed, ResolvedPublic


I cannot open any virtual machines in GNOME Boxes. I have tried both a Windows 7 one, and a Parabola one. I can create them, but when I actually try to open them, I get the message that it failed to open it. I also tried running it in the command line, but the program never opens (even though the process starts in the background, and takes up 25-30% of my CPU). All my packages are up-to-date, using sudo apt update && sudo apt upgrade, and I have tried in both the Wayland and Xorg sessions. I have also rebooted the Librem 13v2 several times. GNOME Boxes is currently at version 3.26.2.

ezs777 created this task.Jan 11 2018, 10:24 AM
jwolf added a subscriber: jwolf.EditedFeb 7 2018, 2:52 PM

Also experiencing this issue - can't start any VM from a known good ISO. Running PureOS OEM image, gnome-boxes is 3.26.2 - issue persists across multiple DEs and reboots.

When invoked from the terminal, failure to start VM outputs:

(gnome-boxes:4756): Boxes-WARNING **: machine.vala:611: Failed to start Ubuntu 16.04: Unable to start domain: unsupported configuration: CPU mode 'custom' for x86_64 kvm domain on x86_64 host is not supported by hypervisor

Invoking "gnome-boxes --checks" outputs:

(gnome-boxes:4696): Boxes-WARNING **: util-app.vala:250: Failed to execute child process ?restorecon? (No such file or directory)
• The CPU is capable of virtualization: yes
• The KVM module is loaded: yes
• Libvirt KVM guest available: yes
• Boxes storage pool available: yes
• The SELinux context is default: no

Possibly related to T320.

EDIT: I can create and run VMs fine in virt-manager, as well as import them into gnome-boxes. Boxes fails to start the known good VM, same errors. virsh dumpxml for the imported VM:

<domain type='kvm'>
    <boxes:gnome-boxes xmlns:boxes="">
  <memory unit='KiB'>1048576</memory>
  <currentMemory unit='KiB'>1048576</currentMemory>
  <vcpu placement='static'>1</vcpu>
    <type arch='x86_64' machine='pc-i440fx-2.11'>hvm</type>
    <vmport state='off'/>
  <clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='writeback'/>
      <source file='/home/jwolf/.local/share/gnome-boxes/images/generic'/>
      <target dev='hda' bus='ide'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <target dev='hdb' bus='ide'/>
      <boot order='1'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/>
    <controller type='pci' index='0' model='pci-root'/>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    <interface type='user'>
      <mac address='52:54:00:6d:80:04'/>
      <model type='rtl8139'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    <serial type='pty'>
      <target type='isa-serial' port='0'>
        <model name='isa-serial'/>
    <console type='pty'>
      <target type='serial' port='0'/>
    <channel type='spicevmc'>
      <target type='virtio' name='com.redhat.spice.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    <channel type='spiceport'>
      <source channel='org.spice-space.webdav.0'/>
      <target type='virtio' name='org.spice-space.webdav.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='2'/>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='spice'>
      <listen type='none'/>
      <image compression='off'/>
    <sound model='ich6'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
      <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='1'/>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='2'/>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
jenda added a subscriber: jenda.Feb 7 2018, 3:44 PM

same problem from a n00b - i can upload the same output info as above if helpful. have tried 3 different distros with the same result. help!

@chris.lamb I can reproduce this bug on both my Librem 13 and 15 both running PureOS pointing to green with the latest updates.

My version of Boxes is 3.27.92

Adding my user to the kvm group worked (after reboot)

sudo adduser <youruser> kvm
chris.lamb added a subscriber: mak.Mar 18 2018, 2:51 AM

I think we could do two things here:

  1. Patch gnome-boxes to show a brief warning if the current users is not part of the kvm group (at some point, probably startup) and show them the "sudo adduser $(whoami)" and then ask them to log out and log back in (reboot not required). We should not run it and it wouldn't work even if we did due to the logging-out requirement.
  1. (optional) Ensure that new installations of PureOS have. I think this is the defaultGroups setting in calamares, so pinging @mak here.

What we can't reliably in PureOS do is add existing users to this group AIUI.

francois added a comment.EditedMar 23 2018, 6:49 PM

An extra thing that we can do is to make sure that new PureOS users are part of the kvm group?

[edit] - Ignore this post, it was actually your second thing to do! :)

d3vid awarded a token.Apr 20 2018, 1:20 PM
d3vid rescinded a token.
d3vid awarded a token.
mak added a comment.May 19 2018, 1:43 PM

@chris.lamb Ah, I missed the first highlight.
Does adding a user to the kvm group imply any "weaker" security? If not, we can add new users created in the installer to the kvm group, but we likely will have to do that globally, so not only users created by Calamares are in the kvm group by default, but also new user created by our OEM setup wizard.

@mak Can you additionally comment on doing that for existing users? There doesn't seem to be a perfect package for this (pureos-minimal is sub-optimal as that's a germinate-based thing, and base-files feels too low-level to me..)

mak added a comment.May 19 2018, 2:08 PM

@chris.lamb Modifying the groups of existing users is evil(tm), and just like writing into $HOME, I don't think we should do that.
Instead, GNOME Boxes could maybe show a nicer error message, so users can add themselves to the group explicitly if they want to.
The groups in which users are is a choice of the administrator who might have intentionally left them out of the kvm group, and we shouldn't change that automatically for every user via a package.

@mak I think I agree. (I wonder though, academically,what _would_ be the package for that?)

mak added a comment.May 19 2018, 6:46 PM

@chris.lamb Obviously IMO no package should do this, but purely academically: The seed packages are inadequate, because they are purely metapackages - their purpose is to pull in other packages that make the actual changes and can be removed individually. We would need a package that is on every system though, and one that actually already influences the behavior of users and groups.
The only package that fits this would be the base-files package, because that one already sets group and path defaults and also is on every system.
Alternatively, the gnome-boxes package could do this, but it would be very unexpected for users to see that the group configuration they have set changes for all users due to installing a package.

In any case, I eally don't think this is something we should do ^^ - we should address this for new installations and/or newly created users though.

@mak Just to avoid confusion I wasn't suggesting we do that (and I think we are agreeing re. the metapackages vs base-files, no?)

mak added a comment.May 19 2018, 7:12 PM

Jup, we are in agreement - and you did say "academically", so I never though you actually wanted to make that change. But I wanted to make absolutely sure that I was just brainstorming here and had no actual intention of modifying user's group settings in a package - sorry for the confusion :-)

chris.lamb closed this task as "Resolved".May 26 2018, 7:31 PM

Fixed in 3.27.92-1pureos2 and filed the default group request in T447.

(Oh, this screenshot is very slightly old - it actually says "reboot" in 3.27.92-1pureos2 as logging in and out of Gnome does not update your UNIX groups…)

I have added my user to the kvm group but when restarting libvirtd, I got the following error :

virFirewallValidateBackend:193 : direct firewall backend requested, but /sbin/ebtables is not available: No such file or directory

So I installed ebtables from apt but now I get the following error :

virGetUserID:1045 : invalid argument: Failed to parse user 'libvirt-qemu'

@guido told me that QEMU was updated on Debian so I will wait for that to get to PureOS and update the issue.

FYI qemu 1:2.12+dfsg-1+b1+pureos1 was just uploaded to green.

just for the record, I guess you mean it was uploadd to landing, @chris.lamb

The problem has now been fixed on my side with the new version of qemu (now on green). I can run a virtual machine without any problem.

Thank you.

@francois Thanks. Shall we close this one up then? :)

Yes, you can close the issue.

Thank you!

I guess Chris' point was that you could close the issue yourself.

...but also, it seems you did so already yourself, @chris.lamb:

OK sorry for the misunderstanding.

Issue about closing issue is now closed! ;)

Add Comment