flathub / org.gnome.Boxes

https://flathub.org/apps/details/org.gnome.Boxes
13 stars 10 forks source link

Can't launch VM because of "util-app.vala:442: Failed to execute: virsh capabilities" error #85

Open N0rbert opened 1 year ago

N0rbert commented 1 year ago

Steps to reproduce:

  1. Have Debian 11 installed with Flatpak
  2. Install GNOME Boxes with flatpak install flathub org.gnome.Boxes
  3. Run GNOME Boxes with flatpak run org.gnome.Boxes
  4. Try to install some OS - click "+", select OS (Debian 11 netinst in my example), wait for download, wait for New Virtual Machine window to appear, try to click Create

Expected results - VM is created and runs well.

Actual results - unable to create VM, terminal shows the following text:

$ flatpak run org.gnome.Boxes
Gtk-Message: 20:24:47.931: Failed to load module "appmenu-gtk-module"
Gtk-Message: 20:24:47.931: Failed to load module "canberra-gtk-module"

(gnome-boxes:2): GLib-CRITICAL **: 20:24:53.461: g_variant_new_string: assertion 'string != NULL' failed
Ignoring /app/share/osinfo/.ref with missing '.xml' extension
Ignoring /app/share/osinfo/manifest.json with missing '.xml' extension

(gnome-boxes:2): Boxes-WARNING **: 20:25:00.164: util-app.vala:442: Failed to execute: virsh capabilities
Ignoring /app/share/osinfo/.ref with missing '.xml' extension
Ignoring /app/share/osinfo/manifest.json with missing '.xml' extension

(gnome-boxes:2): Boxes-WARNING **: 20:28:47.039: util-app.vala:442: Failed to execute: virsh capabilities

Note: I can run both VirtualBox 6.1 and QEMU/KVM on this machine with Intel CPU.

rowbawts commented 1 year ago

Same issue here on Fedora 37 Silverblue.

vahirua commented 1 year ago

Same here on pop os.


Ignoring /app/share/osinfo/.ref with missing '.xml' extension
Ignoring /app/share/osinfo/manifest.json with missing '.xml' extension

(gnome-boxes:2): Boxes-WARNING **: 00:07:03.836: util-app.vala:442: Failed to execute: virsh capabilities`
subpop commented 1 year ago

I think this can be isolated to socket permissions. I can get a similar failure when running virsh capabilities within the Flatpak runtime.

[link@thelio ~]$ flatpak run --command=virsh org.gnome.Boxes capabilities
error: failed to connect to the hypervisor
error: Failed to connect socket to '/app/var/run/libvirt/virtqemud-sock': No such file or directory
KeithHanson commented 1 year ago

+1 This is also happening in Vanilla OS, even after installing the required libs/modules in abroot.

Everything works, create button grayed out, same error in shell.

drzero42 commented 1 year ago

Not an expert here, but could this be related to version differences for libvirt? In this flatpak, libvirt 9.0.0 is a dependency, but on Ubuntu 22.04 (which is what I am running), I have libvirt 8.0.0. I don't know what version of libvirt the other distros mentioned here are on, but I guess libvirt 9.0 could expect different sockets than 8.0? When I run virsh capabilities just on my system, it works fine, but when I run it in the Boxes flatpak, it gives the error about the socket not existing.

subpop commented 1 year ago

I like this theory, but my setup has the same version of libvirt (Fedora 38 has libvirt 9.0.0), and the virsh client version inside the flatpak reports 9.0.0 also.

subpop commented 1 year ago

I created a crazy workaround to continue to use the Create button. Set up this override.

[link@localhost ~]$ flatpak --user override --show org.gnome.Boxes 
[Environment]
GTK_DEBUG=interactive

Then I use the GTK UI debugger to change the sensitive property of the Create button to TRUE. It actually works! You have to live with the debugger window hanging around when Boxes is running, but it works around this bug, so I'm happy.

subpop commented 1 year ago

I think I fixed it for me. I personally set the environment variable LIBVIRT_DEFAULT_URI to qemu:///system in order to interact with the system libvirt daemon when I run virsh. When I added an environment variable to my org.gnome.Boxes override, setting LIBVIRT_DEFAULT_URI=qemu:///session, my Create button is no longer disabled, and my --checks output is full of "yes" instead of "no".

[link@thelio ~]$ flatpak --user override --show org.gnome.Boxes
[Environment]
LIBVIRT_DEFAULT_URI=qemu:///session
[link@thelio ~]$ flatpak run org.gnome.Boxes --checks

** (process:11839): WARNING **: 11:06:09.570: Error writing credentials to socket: Error sending message: Broken pipe

(gnome-boxes:2): Boxes-WARNING **: 11:06:09.594: util-app.vala:422: 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

Report bugs to <http://gitlab.gnome.org/gnome/gnome-boxes/issues>.
Boxes home page: <https://wiki.gnome.org/Apps/Boxes>.
hansingt commented 1 year ago

As already mentioned in https://gitlab.gnome.org/GNOME/gnome-boxes/-/issues/1001#note_1778741 the problem might be that the flatpak inherits the LIBVIRT_DEFAULT_URI from the host system. Explicitly overwriting it fixes this issue for me:

> export LIBVIRT_DEFAULT_URI=qemu:///system
> flatpak run --command=virsh org.gnome.Boxes uri
error: failed to connect to the hypervisor
error: Failed to connect socket to '/app/var/run/libvirt/virtqemud-sock': No such file or directory
>
> unset LIBVIRT_DEFAULT_DIR
>flatpak run --command=virsh org.gnome.Boxes uri
qemu:///session
> flatpak run org.gnome.Boxes --checks

(gnome-boxes:2): Boxes-WARNING **: 10:20:37.552: util-app.vala:422: 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

Report bugs to <http://gitlab.gnome.org/gnome/gnome-boxes/issues>.
Boxes home page: <https://wiki.gnome.org/Apps/Boxes>.

The Problem araises especially on Ubuntu Systems as canonical seems to explicitly set this environment variable to qemu:///system via /etc/profile.d/libvirt-uri.sh:

#!/bin/sh
#    libvirt-uri.sh - Automatically switch default libvirt URI for user
#    Copyright (C) 2015 Canonical Ltd.
#
#    Authors: Stefan Bader <stefan.bader@canonical.com>
#
#    This program is free software: you can redistribute it and/or modify
#    it under the terms of the GNU General Public License as published by
#    the Free Software Foundation, version 3 of the License.
#
#    This program is distributed in the hope that it will be useful,
#    but WITHOUT ANY WARRANTY; without even the implied warranty of
#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#    GNU General Public License for more details.
#
#    You should have received a copy of the GNU General Public License
#    along with this program.  If not, see <http://www.gnu.org/licenses/>.

LIBVIRT_DEFAULT_URI="qemu:///system"
if [ -f /proc/xen/capabilities ]; then
    if [ "$(cat /proc/xen/capabilities)" = "control_d" ]; then
        LIBVIRT_DEFAULT_URI="xen:///"
    fi
fi

export LIBVIRT_DEFAULT_URI

If I explicitly overwrite the environment variable in the flatpak (setting it to qemu:///session), it works for me.