Bug 1817031
Summary: | Deleting a VM breaks gnome-boxes forever, can no longer start | ||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Kamil Páral <kparal> | ||||||||||||||||||||||||
Component: | gnome-boxes | Assignee: | Felipe Borges <feborges> | ||||||||||||||||||||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||||||||||
Severity: | unspecified | Docs Contact: | |||||||||||||||||||||||||
Priority: | unspecified | ||||||||||||||||||||||||||
Version: | 32 | CC: | 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
Kamil Páral
2020-03-25 12:58:33 UTC
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).) 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. |