Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
N0rbert opened this issue Mar 29, 2023 · 9 comments

Comments

@N0rbert
Copy link

N0rbert commented Mar 29, 2023

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
Copy link

Same issue here on Fedora 37 Silverblue.

@vahirua
Copy link

vahirua commented May 18, 2023

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
Copy link

subpop commented May 26, 2023

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
Copy link

+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
Copy link

drzero42 commented Jun 9, 2023

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
Copy link

subpop commented Jun 9, 2023

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
Copy link

subpop commented Jun 9, 2023

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
Copy link

subpop commented Jun 27, 2023

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants