Description of problem: With libvirt-6.1.0-2.fc32, I created a new VM in Boxes and booted F32 Workstation Beta. Once booted, I click on the back arrow, to get back to the Boxes overview. There I chose to delete the machine. A popup appeared that the machine was deleted (with available Undo button). I immediately closed the main Boxes window. In terminal, I saw this message: (gnome-boxes:15832): Boxes-WARNING **: 13:37:03.908: libvirt-machine.vala:521: Unable to delete domain: Requested operation is not valid: cannot undefine domain with nvram Since that, I can no longer run Boxes as all. Every time I try, a core dump is generated: $ gnome-boxes (gnome-boxes:16457): Gtk-WARNING **: 13:37:07.871: GtkFlowBox with a model will ignore sort and filter functions (gnome-boxes:16457): Gtk-WARNING **: 13:37:07.872: GtkListBox with a model will ignore sort and filter functions (gnome-boxes:16457): Libvirt.GObject-CRITICAL **: 13:37:08.363: gvir_storage_vol_get_info: assertion 'GVIR_IS_STORAGE_VOL(vol)' failed Segmentation fault (core dumped) I'll try whether a reboot fixes the issue. Version-Release number of selected component: gnome-boxes-3.36.1-1.fc32 Additional info: reporter: libreport-2.12.0 backtrace_rating: 3 cgroup: 0::/user.slice/user-1000.slice/user/apps.slice/apps-org.gnome.Terminal.slice/vte-spawn-e08b677f-5ea2-4900-90f3-039e88cfed8a.scope cmdline: gnome-boxes crash_function: boxes_vm_creator_guest_installed_os executable: /usr/bin/gnome-boxes journald_cursor: s=f089bd4038d445cbbf26e4af9358f890;i=149fad;b=a6d7c917997f46fdb983f65ce1376184;m=469cae0d1;t=5a1ad207604d3;x=90fc09c4e6df74bb kernel: 5.6.0-0.rc7.git0.2.fc32.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #0 boxes_vm_creator_guest_installed_os at src/25a6634 #1 boxes_vm_creator_on_machine_state_changed at src/25a6634 #2 boxes_vm_creator_real_continue_installation_co at src/25a6634 #3 g_task_return_now at ../gio/gtask.c:1214 #4 g_task_return at ../gio/gtask.c:1283 #6 g_task_return_pointer at ../gio/gtask.c:1691 #7 ?? #8 annobin_boxes_media_manager_create_installer_media_from_config_ready.start at src/25a6634 #9 ?? #10 g_task_return_now at ../gio/gtask.c:1214 Potential duplicate: bug 1483668
Created attachment 1673407 [details] File: backtrace
Created attachment 1673408 [details] File: core_backtrace
Created attachment 1673409 [details] File: cpuinfo
Created attachment 1673410 [details] File: dso_list
Created attachment 1673411 [details] File: environ
Created attachment 1673412 [details] File: exploitable
Created attachment 1673413 [details] File: limits
Created attachment 1673414 [details] File: maps
Created attachment 1673415 [details] File: mountinfo
Created attachment 1673416 [details] File: open_fds
Created attachment 1673417 [details] File: proc_pid_status
I see. I will propose some changes in libvirt-glib for it to always pass VIR_DOMAIN_UNDEFINE_NVRAM to virDomainUndefineFlags, which seems to be the behavior that virt-manager also has.
A system reboot doesn't fix this. After a long time of removing random directories and rebooting [1], I managed to get to a state where I could start gnome-boxes again. But even when I could, there were still some remnant config files *somewhere*, so my new VM wasn't called Fedora but Fedora 2, etc. If I should debug this properly or test some fix, I need Boxes devs to tell me how to reset the system into a _pristine_ state where no Boxes remnants are present. With my not-completely-reverted system, I was able to verify that the same problem occurs again, same reproducer steps. This time, I waited until the "VM deleted [Undo]" popup disappeared, so this is not related to the user closing the window too fast. It probably occurs every time. Proposing as a blocker, you can't start the app again once you delete a VM. [1] I tried stop stop libvirtd, and then remove ~/.config/gnome-boxes, ~/.cache/gnome-boxes, ~/.local/share/gnome-boxes, ~/.config/libvirt and ~/.local/share/libvirt, then rebooted.
Actually, this seems to get you back to the pristine state: $ sudo systemctl stop libvirtd $ rm ~/.config/gnome-boxes ~/.cache/gnome-boxes ~/.local/share/gnome-boxes ~/.config/libvirt ~/.local/share/libvirt -rf $ systemctl reboot At the expense of losing all your local VMs, not just Boxes VMs. The reboot is necessary, I have on idea why.
You should be able to use $ virsh undefine --nvram <domain-name> the --nvram argument is the culprit of this issue.
(In reply to Felipe Borges from comment #15) > You should be able to use $ virsh undefine --nvram <domain-name> Great, thanks. I can confirm this allows me to get back to a working state (without purging everything): $ LIBVIRT_DEFAULT_URI=qemu:///session virsh list --all # figure out the VM name $ LIBVIRT_DEFAULT_URI=qemu:///session virsh undefine --nvram fedora-unkno (The variable is only needed if you changed the default value (as I do in .bashrc).)
https://bodhi.fedoraproject.org/updates/FEDORA-2020-72780a053a
FEDORA-2020-72780a053a has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-72780a053a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-72780a053a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Fedora Update System from comment #18) > https://bodhi.fedoraproject.org/updates/FEDORA-2020-72780a053a With this I can now delete a machine and start Boxes again. Thanks Felipe.
FEDORA-2020-72780a053a has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.