Description of problem: Simply crashes on start. Version-Release number of selected component (if applicable): rpm -q gnome-boxes gnome-boxes-3.24.0-1.fc26.x86_64 How reproducible: Always Steps to Reproduce: 1. Run boxes 2. 3. Actual results: New window comes up and immediately crashes Expected results: Should not crash Additional info: On running from the terminal, this is the output: [asinha@cs-as14aho-2-herts-ac-uk ~]$ gnome-boxes (gnome-boxes:28419): Tracker-WARNING **: tracker-backend.vala:211: Falling back to bus backend, the direct backend failed to initialize: Locale change detected (DB:unknown, User/App:en_GB.utf8) (gnome-boxes:28419): Boxes-WARNING **: media-manager.vala:156: Failed to fetch list of ISOs from Tracker: GDBus.Error:org.freedesktop.Tracker1.SparqlError.Internal: Error opening database. (gnome-boxes:28419): Libvirt.GObject-CRITICAL **: gvir_storage_vol_get_info: assertion 'GVIR_IS_STORAGE_VOL(vol)' failed Segmentation fault (core dumped) -- This is what the journal log had: May 08 14:39:14 cs-as14aho-2-herts-ac-uk systemd-coredump[28610]: Process 28419 (gnome-boxes) of user 1000 dumped core. Stack trace of thread 28419: #0 0x0000556dad338790 boxes_vm_creator_on_machine_state_changed.isra.17 (gnome-boxes) #1 0x0000556dad338e13 boxes_vm_creator_real_continue_installation_co (gnome-boxes) #2 0x00007f03d07ae384 g_task_return_now (libgio-2.0.so.0) #3 0x00007f03d07ae3b9 complete_in_idle_cb (libgio-2.0.so.0) #4 0x00007f03d0206bf7 g_idle_dispatch (libglib-2.0.so.0) #5 0x00007f03d020a207 g_main_context_dispatch (libglib-2.0.so.0) #6 0x00007f03d020a5a8 g_main_context_iterate.isra.24 (libglib-2.0.so.0) #7 0x00007f03d020a63c g_main_context_iteration (libglib-2.0.so.0) #8 0x00007f03d07c3d0d g_application_run (libgio-2.0.so.0) #9 0x0000556dad30b8f9 _vala_main (gnome-boxes) #10 0x00007f03cf8895fe __libc_start_main (libc.so.6) #11 0x0000556dad2cef6a _start (gnome-boxes) Stack trace of thread 28423: #0 0x00007f03cf9747a9 syscall (libc.so.6) #1 0x00007f03d024f76a g_cond_wait_until (libglib-2.0.so.0) #2 0x00007f03d01deb31 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0) #3 0x00007f03d0231e64 g_thread_pool_thread_proxy (libglib-2.0.so.0) #4 0x00007f03d02314c6 g_thread_proxy (libglib-2.0.so.0) #5 0x00007f03cfc4136d start_thread (libpthread.so.0) #6 0x00007f03cf979e0f __clone (libc.so.6) Stack trace of thread 28420: #0 0x00007f03cf96dced poll (libc.so.6) #1 0x00007f03d020a529 g_main_context_iterate.isra.24 (libglib-2.0.so.0) #2 0x00007f03d020a63c g_main_context_iteration (libglib-2.0.so.0) #3 0x00007f03d020a681 glib_worker_main (libglib-2.0.so.0) #4 0x00007f03d02314c6 g_thread_proxy (libglib-2.0.so.0) #5 0x00007f03cfc4136d start_thread (libpthread.so.0) #6 0x00007f03cf979e0f __clone (libc.so.6) Stack trace of thread 28422: #0 0x00007f03cf9747a9 syscall (libc.so.6) #1 0x00007f03d024f76a g_cond_wait_until (libglib-2.0.so.0) #2 0x00007f03d01deb31 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0) #3 0x00007f03d0231e64 g_thread_pool_thread_proxy (libglib-2.0.so.0) #4 0x00007f03d02314c6 g_thread_proxy (libglib-2.0.so.0) #5 0x00007f03cfc4136d start_thread (libpthread.so.0) #6 0x00007f03cf979e0f __clone (libc.so.6) Stack trace of thread 28431: #0 0x00007f03cf9747a9 syscall (libc.so.6) #1 0x00007f03d024f76a g_cond_wait_until (libglib-2.0.so.0) #2 0x00007f03d01deb31 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0) #3 0x00007f03d0231e64 g_thread_pool_thread_proxy (libglib-2.0.so.0) #4 0x00007f03d02314c6 g_thread_proxy (libglib-2.0.so.0) #5 0x00007f03cfc4136d start_thread (libpthread.so.0) #6 0x00007f03cf979e0f __clone (libc.so.6) Stack trace of thread 28430: #0 0x00007f03cf9747a9 syscall (libc.so.6) #1 0x00007f03d024f76a g_cond_wait_until (libglib-2.0.so.0) #2 0x00007f03d01deb31 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0) #3 0x00007f03d0231e64 g_thread_pool_thread_proxy (libglib-2.0.so.0) #4 0x00007f03d02314c6 g_thread_proxy (libglib-2.0.so.0) #5 0x00007f03cfc4136d start_thread (libpthread.so.0) #6 0x00007f03cf979e0f __clone (libc.so.6) Stack trace of thread 28425: #0 0x00007f03cf96dced poll (libc.so.6) #1 0x00007f03d020a529 g_main_context_iterate.isra.24 (libglib-2.0.so.0) #2 0x00007f03d020a63c g_main_context_iteration (libglib-2.0.so.0) #3 0x00007f03a8ecbf3d dconf_gdbus_worker_thread (libdconfsettings.so) #4 0x00007f03d02314c6 g_thread_proxy (libglib-2.0.so.0) #5 0x00007f03cfc4136d start_thread (libpthread.so.0) #6 0x00007f03cf979e0f __clone (libc.so.6) Stack trace of thread 28421: #0 0x00007f03cf96dced poll (libc.so.6) #1 0x00007f03d020a529 g_main_context_iterate.isra.24 (libglib-2.0.so.0) #2 0x00007f03d020a8c2 g_main_loop_run (libglib-2.0.so.0) #3 0x00007f03d07efb16 gdbus_shared_thread_func (libgio-2.0.so.0) #4 0x00007f03d02314c6 g_thread_proxy (libglib-2.0.so.0) #5 0x00007f03cfc4136d start_thread (libpthread.so.0) #6 0x00007f03cf979e0f __clone (libc.so.6) Stack trace of thread 28435: #0 0x00007f03cf9747a9 syscall (libc.so.6) #1 0x00007f03d024f76a g_cond_wait_until (libglib-2.0.so.0) #2 0x00007f03d01deb31 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0) #3 0x00007f03d0231e64 g_thread_pool_thread_proxy (libglib-2.0.so.0) #4 0x00007f03d02314c6 g_thread_proxy (libglib-2.0.so.0) #5 0x00007f03cfc4136d start_thread (libpthread.so.0) #6 0x00007f03cf979e0f __clone (libc.so.6) May 08 14:39:14 cs-as14aho-2-herts-ac-uk audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@6-28609-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr May 08 14:39:15 cs-as14aho-2-herts-ac-uk abrt-server[28618]: Deleting problem directory ccpp-2017-05-08-14:39:14.458723-771 (dup of ccpp-2017-05-08-14:09:14.232098-784) May 08 14:39:15 cs-as14aho-2-herts-ac-uk abrt-notification[28680]: Process 11929 (gnome-boxes) crashed in boxes_vm_creator_on_machine_state_changed.isra.17() -- Cheers, Ankur
Also occuring to me on a freshly installed F26. Only gives this error message, seen in the original reporters error log as well : (gnome-boxes:7009): Libvirt.GObject-CRITICAL **: gvir_storage_vol_get_info: assertion 'GVIR_IS_STORAGE_VOL(vol)' failed Segmentation fault (core dumped)
Upstream bugs: https://bugzilla.gnome.org/show_bug.cgi?id=781051 https://bugzilla.gnome.org/show_bug.cgi?id=782142
Proposed as a Blocker for 26-final by Fedora user jonha using the blocker tracking app because: All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test.
Sorry, disregard my previous comment! I made a fresh F26 Install but forgot to mention I kept the /home partition, and the same username. I just created a new user, and Boxes launches correctly with it.
I can't reproduce this bug locally either, but it looks like something was wrong with tracker on the OP's system (changed locale? why?).
(In reply to Paul W. Frields from comment #5) > I can't reproduce this bug locally either, but it looks like something was > wrong with tracker on the OP's system (changed locale? why?). The Tracker bit of the log shouldn't cause the crash. The crash looks related to a inconsistent state of the VM files.
Discussed at 2017-06-26 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-06-26/f26-blocker-review.2017-06-26-16.03.html . As per #c6 and our experience, it seems this is not a general failure of Boxes to start up in any situation, but rather a bug which causes it to fail to start up in some specific situation (probably a VM disk file being missing or inaccessible somehow). As it seems this will not affect most F26 installs, it is rejected as a blocker. If it becomes apparent that the bug will have a wide impact, it can be re-proposed by clearing the 'RejectedBlocker' text from the whiteboard and marking the bug as blocking the bug 'F26FinalBlocker' again.
Encountering the exact same issue, gnome-boxes is segfaulting.
Something with one of my images glitched when I was using Boxes and Boxes crashed and would not restart. Launching gnome-boxes under terminal returned the output "Libvirt.GObject-CRITICAL **: gvir_storage_vol_get_info: assertion 'GVIR_IS_STORAGE_VOL(vol)' failed" I could never find the image to remove it, the folder was blank. I had a thought that some configuration was corrupted or something so I started renaming folders hoping to find it. When I renamed the folder /home/[user_name]/.config/libvirt Boxes started up perfectly. I didn't want to remove them, just rename them to have it recreate them. By the way, Boxes recreates that folder upon start up if its not there. I have NO information how that may affect any images stored in Boxes, I did not have any saved I cared about. Maybe this can help.
Addendum: Strangely, returning the name of the old folder does not cause Boxes to stop booting. The error did not return when I did that, but I kept the new one instead.
Created attachment 1347410 [details] gnome boxes core dump This happened to me after rebooting during a guest installation, which obviously never completed. I believe the first time gnome-boxes started up properly and I attempted to delete the half installed box. It appeared to be successful, but after that gnome-boxes refused to start. I should have saved the .config/libvirt directory, but I deleted it.
Same issue here : $ gnome-boxes (gnome-boxes:16012): Libvirt.GObject-CRITICAL **: gvir_storage_vol_get_info: assertion 'GVIR_IS_STORAGE_VOL(vol)' failed Erreur de segmentation (core dumped) Comment #9 saved my day. If I revert to the old libvirt folder, gnome-boxes does crash. I'll attach my libvirt folder. I've only tested an ISO linux image (Primtux3)
Created attachment 1351245 [details] libvirt folder that causes a core dump The iso (primtux3) is present on my hard drive.
After a restart it crashed again. I removed ~/.cache/libvirt and ~/.cache/gnome-boxes but it crashed. I renamed the iso it was using : $ gnome-boxes (gnome-boxes:5978): Boxes-WARNING **: vm-creator.vala:99: Source installer media '/home/yannick/Téléchargements/PrimTux3-2017-11-02-i386.hybrid.iso' no longer exists. Deleting machine 'PrimTux3-2017-11-02-i386'.. (gnome-boxes:5978): Boxes-CRITICAL **: libvirt-machine.vala:145: Failed to fetch configuration for domain 'boxes-unknown': Unable to get domain XML config: Domain not found: no domain with matching uuid '453faf31-8749-4e58-b85e-c3f72429a0fe' (boxes-unknown) And now it works. I suspect it not only use .cache, it should store config somewhere else too (dconf maybe?). Maybe a mismatch somewhere between all those config storages is the culprit? $ gnome-boxes --version 3.24.0
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.