GNOME Bugzilla – Bug 772087
After a system installation, gnome-boxes points to the iso, not system installed
Last modified: 2016-11-23 20:13:53 UTC
Created attachment 336392 [details] Gnome-boxes output - Installation of Fedora 24 with Gnome-boxes; - Installation went good as Anaconda said it; - Fedora shutdown; - Restart Fedora from Gnome-boxes; Fedora is still like a Live system, as it doesn't ask me my login and password and if I install an app with Fedora, it disappears after a reboot. The iso downloaded is stored in my home/eyome/Distribs/ and if I move or remove this iso, Gnome-boxes doesn't start: see attached file. Thank you. Arch Linux with 3.20.2.
I forget to mention: I use to be on #boxes IRC under the name eyome
See https://bugzilla.gnome.org/show_bug.cgi?id=771917
(In reply to Bjørn Lie from comment #2) > See https://bugzilla.gnome.org/show_bug.cgi?id=771917 yeah it's likely a dup.
I tried to reproduce this on my F24 host yesterday (Boxes 3.22) against F24 live ISO but after installation, the system was correctly recognized as "installed". So you'll need to dig into logs. You can try with reproducing it while running Boxes with debug enabled as `G_MESSAGE_DEBUG=Boxes gnome-boxes` and then copy&pasting what you see from console.
*** Bug 771917 has been marked as a duplicate of this bug. ***
@Zeeshan Ali Here the output of Fedora installation and re-start: https://framabin.org/?11c73ef76ee20756#Bt/HavLmOPzuydKoDZzrUtLffT4+8kiUn2pq2AdIIaw= Thank you.
(In reply to baikalink from comment #6) > @Zeeshan Ali > > Here the output of Fedora installation and re-start: > https://framabin.org/?11c73ef76ee20756#Bt/ > HavLmOPzuydKoDZzrUtLffT4+8kiUn2pq2AdIIaw= Oh sorry, there was a typo. It's G_MESSAGES_DEBUG (i-e MESSAGES in plural).
(In reply to Zeeshan Ali (Khattak) from comment #7) > (In reply to baikalink from comment #6) > > @Zeeshan Ali > > > > Here the output of Fedora installation and re-start: > > https://framabin.org/?11c73ef76ee20756#Bt/ > > HavLmOPzuydKoDZzrUtLffT4+8kiUn2pq2AdIIaw= > > Oh sorry, there was a typo. It's G_MESSAGES_DEBUG (i-e MESSAGES in plural). Nevermind, I think i see the problem in those warnings already. It seems Boxes is unable to update the domain configuration XML probably because of some libvirt and libvirt-glib compatibility. Could you please ensure you have not so old releases and if they are new enough, could you please provide their versions?
And on closer look at other warnings and code, I think you likely have some big libvirt issues on your system in any case.
Here the output with a new fedora installation: https://framabin.org/?2b386d91e1b45843#7QgNX7/bVqHd8OFOPAnZM5CvcoV1nz+//ZO3PnX1t9s= My versions: libvirt 2.3.0 libvirt-glib 0.2.3 Thank you.
Created attachment 337258 [details] openSUSE Tumbleweed "run" If Arch have a issue with spice, we have the same issue over at openSUSE. In this case, I've bumped "all spice" to current upstream releases, before doing a boxes install, and still it fails to "save" Boxes-Message: machine.vala:209: display openSUSE Tumbleweed disconnected (gnome-boxes:6033): Boxes-DEBUG: machine.vala:116: State of 'openSUSE Tumbleweed' changed to BOXES_MACHINE_MACHINE_STATE_STOPPED (gnome-boxes:6033): Boxes-DEBUG: libvirt-machine.vala:378: disable statistics for openSUSE Tumbleweed (gnome-boxes:6033): Boxes-DEBUG: vm-creator.vala:195: Setting post-installation configuration on 'openSUSE Tumbleweed' (gnome-boxes:6033): Boxes-WARNING **: vm-creator.vala:201: Failed to set post-install configuration on 'openSUSE Tumbleweed': Failed to set domain configuration: XML error: there is no hub at port 1 in USB address bus: 0 port: 1.1 (gnome-boxes:6033): Boxes-DEBUG: app.vala:438: Window is focused, no need for system notification
i | libvirt | pakke | 2.2.0-1.1 | x86_64 | Tumbleweed Oss i | libvirt-admin | pakke | 2.2.0-1.1 | x86_64 | Tumbleweed Oss i | libvirt-client | pakke | 2.2.0-1.1 | x86_64 | Tumbleweed Oss i | libvirt-daemon | pakke | 2.2.0-1.1 | x86_64 | Tumbleweed Oss i | libvirt-daemon-config-network | pakke | 2.2.0-1.1 | x86_64 | Tumbleweed Oss i | libvirt-daemon-config-nwfilter | pakke | 2.2.0-1.1 | x86_64 | Tumbleweed Oss i | libvirt-daemon-driver-interface | pakke | 2.2.0-1.1 | x86_64 | Tumbleweed Oss i | libvirt-daemon-driver-libxl | pakke | 2.2.0-1.1 | x86_64 | Tumbleweed Oss i | libvirt-daemon-driver-lxc | pakke | 2.2.0-1.1 | x86_64 | Tumbleweed Oss i | libvirt-daemon-driver-network | pakke | 2.2.0-1.1 | x86_64 | Tumbleweed Oss i | libvirt-daemon-driver-nodedev | pakke | 2.2.0-1.1 | x86_64 | Tumbleweed Oss i | libvirt-daemon-driver-nwfilter | pakke | 2.2.0-1.1 | x86_64 | Tumbleweed Oss i | libvirt-daemon-driver-qemu | pakke | 2.2.0-1.1 | x86_64 | Tumbleweed Oss i | libvirt-daemon-driver-secret | pakke | 2.2.0-1.1 | x86_64 | Tumbleweed Oss i | libvirt-daemon-driver-storage | pakke | 2.2.0-1.1 | x86_64 | Tumbleweed Oss i | libvirt-daemon-driver-uml | pakke | 2.2.0-1.1 | x86_64 | Tumbleweed Oss i | libvirt-daemon-driver-vbox | pakke | 2.2.0-1.1 | x86_64 | Tumbleweed Oss i | libvirt-daemon-lxc | pakke | 2.2.0-1.1 | x86_64 | Tumbleweed Oss i | libvirt-daemon-qemu | pakke | 2.2.0-1.1 | x86_64 | Tumbleweed Oss i | libvirt-devel | pakke | 2.2.0-1.1 | x86_64 | Tumbleweed Oss i | libvirt-doc | pakke | 2.2.0-1.1 | x86_64 | Tumbleweed Oss i | libvirt-glib-1_0-0 | pakke | 0.2.3-71.11 | x86_64 | GNOME Next i | libvirt-libs | pakke | 2.2.0-1.1 | x86_64 | Tumbleweed Oss i | libvirt-nss | pakke | 2.2.0-1.1 | x86_64 | Tumbleweed Oss i | libvirt-sandbox-1_0-5 | pakke | 0.6.0-3.5 | x86_64 | Tumbleweed Oss bjolie@haldis:~>
(In reply to baikalink from comment #10) > Here the output with a new fedora installation: > https://framabin.org/?2b386d91e1b45843#7QgNX7/bVqHd8OFOPAnZM5CvcoV1nz+// > ZO3PnX1t9s= > > My versions: > libvirt 2.3.0 > libvirt-glib 0.2.3 Thanks. Your libvirt is actually much nearer than mine on Fedora 24 host. Wonder if libvirt-glib has some incompatibility with latest libvirt. I'll ask libvirt folks.
Ah, after upgrading to Fedora 25, I can see the same error here: (gnome-boxes:26335): Boxes-WARNING **: libvirt-broker.vala:66: Failed to update domain 'fedora24-wor-3': Failed to set domain configuration: XML error: there is no hub at port 1 in USB address bus: 0 port: 1.1
I filed a bug here, it's very likely a libvirt and/or libvirt-glib issue: https://bugzilla.redhat.com/show_bug.cgi?id=1388091
With new libvirt-glib (1.0.0) things seem to be working again indeed. I guess this bug can be closed as not-gnome ?
(In reply to Bjørn Lie from comment #16) > With new libvirt-glib (1.0.0) things seem to be working again indeed. > I guess this bug can be closed as not-gnome ? yeah.