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.

Sign up for GitHub

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

Jump to bottom

gnome-boxes: can't start vms created in different versions #57931

Closed
worldofpeace opened this issue Mar 20, 2019 · 2 comments · Fixed by #64728 or #193161
Closed

gnome-boxes: can't start vms created in different versions #57931

worldofpeace opened this issue Mar 20, 2019 · 2 comments · Fixed by #64728 or #193161
Labels
0.kind: bug 6.topic: GNOME GNOME desktop environment and its underlying platform
Projects
GNOME

Comments

@worldofpeace
Copy link
Contributor

worldofpeace commented Mar 20, 2019 •
edited

GNOME Boxes can't start vms created in different versions

Different versions of gnome-boxes cannot start vms created in other versions.
Specifically when the path to qemu in its wrapper changes.

Steps to reproduce

  1. Start gnome-boxes
  2. Create a vm
  3. Close gnome-boxes
  4. Start a different version of gnome boxes that changes the path to qemu in it's wrapper
  5. Try to start vm
  6. Fails with error
libvirt-broker.vala:66: Failed to update domain 'boxes-unknown': Failed to set domain configuration: Cannot check QEMU binary /nix/store/ian3p070vi59ikljv6a1pb8sa8k75dz8-qemu-3.1.0/bin/qemu-system-x86_64: No such file or directory

Notes

I think this sounds more like a bug in gnome-boxes if anything.
@worldofpeace worldofpeace added 6.topic: GNOME GNOME desktop environment and its underlying platform 0.kind: bug labels Mar 20, 2019
@worldofpeace worldofpeace added this to To Do in GNOME Mar 23, 2019
@romildo
Copy link
Contributor

romildo commented Mar 25, 2019 •
edited

It writes the full path of qemu-system-x86_64 in the configuration file (for instance /nix/store/5a2gv548h6wlsb96w2w07h69z0gjccbj-qemu-3.1.0/bin/qemu-system-x86_64) and obviously that stops working when qemu is rebuilt and stored in a different sub directory in /nix/store.

Every time this happens I edit the configuration files to update the path. It is a nuisance.

worldofpeace added a commit to worldofpeace/nixpkgs that referenced this issue Jul 14, 2019
@worldofpeace
gnome3.gnome-boxes: fix hardcoded emulator path
1203370 
To avoid this you must install the qemu binaries globally in some
manner.

Fixes NixOS#57931
@worldofpeace worldofpeace mentioned this issue Jul 14, 2019
Merged
10 tasks
GNOME automation moved this from To Do to Done Jul 15, 2019
@sersorrel
Copy link
Contributor

This is a problem again since #136789 added qemu back into $PATH.

libvirt appears to require that the path in <emulator> is absolute:

The contents of the emulator element specify the fully qualified path to the device model emulator binary. The capabilities XML specifies the recommended default emulator to use for each particular domain type / architecture combination.

so just putting qemu in there is unfortunately probably not going to work (if anyone can even work out which bit of software is responsible for generating that path; I couldn't find anything relevant in Boxes, but I was also relying entirely on grep so it's very possible I missed it).

I can't see a way of fixing this apart from removing qemu from $PATH again and requiring that qemu be installed alongside Boxes.

@sersorrel sersorrel reopened this Aug 18, 2022
jtojnar added a commit that referenced this issue Sep 27, 2022
@jtojnar
Revert "gnome.gnome-boxes: add qemu to path"
60158d3 
Boxes insert the absolute path of `qemu-system-x86_64` program
as found on `PATH` into the `<emulator>` element of the libvirt
config. But if we add qemu to `PATH` using a wrapper, the saved
path will point directly to a store path, which will break when
the store path is garbage collected.

Let’s drop it again so that qemu can be picked up from the environment
using a more stable path such as `/run/libvirt/nix-emulators/qemu-system-x86_64`
introduced by the `virtualisation.libvirtd.enable = true;` NixOS option.

This reverts commit ba1ecbe,
essentially re-applying 1203370.

Fixes: #57931
@jtojnar jtojnar mentioned this issue Sep 27, 2022
Merged
jtojnar added a commit that referenced this issue Sep 29, 2022
@jtojnar
Revert "gnome.gnome-boxes: add qemu to path"
7ccc6ab 
Boxes insert the absolute path of `qemu-system-x86_64` program
as found on `PATH` into the `<emulator>` element of the libvirt
config. But if we add qemu to `PATH` using a wrapper, the saved
path will point directly to a store path, which will break when
the store path is garbage collected.

Let’s drop it again so that qemu can be picked up from the environment
using a more stable path such as `/run/libvirt/nix-emulators/qemu-system-x86_64`
introduced by the `virtualisation.libvirtd.enable = true;` NixOS option.

This reverts commit ba1ecbe,
essentially re-applying 1203370.

Fixes: #57931
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
0.kind: bug 6.topic: GNOME GNOME desktop environment and its underlying platform
Projects
GNOME
  
Done
Milestone
No milestone
3 participants
@romildo @sersorrel @worldofpeace