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: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:
runlevel: N 5
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
#8 annobin_boxes_media_manager_create_installer_media_from_config_ready.start at src/25a6634
#10 g_task_return_now at ../gio/gtask.c:1214
Potential duplicate: Confidentialbug 1483668
Created attachment 1673407 [details]
Created attachment 1673408 [details]
Created attachment 1673409 [details]
Created attachment 1673410 [details]
Created attachment 1673411 [details]
Created attachment 1673412 [details]
Created attachment 1673413 [details]
Created attachment 1673414 [details]
Created attachment 1673415 [details]
Created attachment 1673416 [details]
Created attachment 1673417 [details]
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 , 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.
 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).)
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)
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.