Bug 1817031

Summary: Deleting a VM breaks gnome-boxes forever, can no longer start
Product: [Fedora] Fedora Reporter: Kamil Páral <kparal>
Component: gnome-boxesAssignee: Felipe Borges <feborges>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 32CC: cfergeau, feborges, fidencio, gnome-sig, marcandre.lureau, nobody+zeenix, robatino
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/d2120310f5294baba8f9e456e2351ab7cee8f3af
Whiteboard: abrt_hash:ac235c11dead19c5868108fcd37429eb4d66fc71;VARIANT_ID=workstation;
Fixed In Version: gnome-boxes-3.36.1-2.fc32 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-27 08:02:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1705305    
Attachments:
Description Flags
File: backtrace
none
File: core_backtrace
none
File: cpuinfo
none
File: dso_list
none
File: environ
none
File: exploitable
none
File: limits
none
File: maps
none
File: mountinfo
none
File: open_fds
none
File: proc_pid_status none

Description Kamil Páral 2020-03-25 12:58:33 UTC
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

Comment 1 Kamil Páral 2020-03-25 12:58:42 UTC
Created attachment 1673407 [details]
File: backtrace

Comment 2 Kamil Páral 2020-03-25 12:58:45 UTC
Created attachment 1673408 [details]
File: core_backtrace

Comment 3 Kamil Páral 2020-03-25 12:58:46 UTC
Created attachment 1673409 [details]
File: cpuinfo

Comment 4 Kamil Páral 2020-03-25 12:58:49 UTC
Created attachment 1673410 [details]
File: dso_list

Comment 5 Kamil Páral 2020-03-25 12:58:56 UTC
Created attachment 1673411 [details]
File: environ

Comment 6 Kamil Páral 2020-03-25 12:59:01 UTC
Created attachment 1673412 [details]
File: exploitable

Comment 7 Kamil Páral 2020-03-25 12:59:03 UTC
Created attachment 1673413 [details]
File: limits

Comment 8 Kamil Páral 2020-03-25 12:59:09 UTC
Created attachment 1673414 [details]
File: maps

Comment 9 Kamil Páral 2020-03-25 12:59:15 UTC
Created attachment 1673415 [details]
File: mountinfo

Comment 10 Kamil Páral 2020-03-25 12:59:22 UTC
Created attachment 1673416 [details]
File: open_fds

Comment 11 Kamil Páral 2020-03-25 12:59:24 UTC
Created attachment 1673417 [details]
File: proc_pid_status

Comment 12 Felipe Borges 2020-03-25 13:30:38 UTC
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.

Comment 13 Kamil Páral 2020-03-25 13:33:01 UTC
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.

Comment 14 Kamil Páral 2020-03-25 13:40:59 UTC
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.

Comment 15 Felipe Borges 2020-03-25 13:42:59 UTC
You should be able to use $ virsh undefine --nvram <domain-name>

the --nvram argument is the culprit of this issue.

Comment 16 Kamil Páral 2020-03-25 13:53:01 UTC
(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).)

Comment 18 Fedora Update System 2020-03-25 21:07:24 UTC
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.

Comment 19 Kamil Páral 2020-03-26 09:42:24 UTC
(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.

Comment 20 Fedora Update System 2020-03-27 08:02:01 UTC
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.