Created attachment 1507717 [details] The xml file for hung install from /etc/libvirt/qemu directory Description of problem: Cannot use virt-manager to install a fedora 29 virtual machine when hosted on fedora 29. The virt-manager hosted on fedora 28 worked fine installing the exact same fedora 29 x86_64 workstation live iso file. It always hangs somewhere in the configuring storage vicinity. Weirdly, the i386 fedora 29 workstation iso does not have this problem, only the x86_64 iso fails. Version-Release number of selected component (if applicable): virt-manager-1.6.0-1.3.git3bc7ff24c.fc29.noarch libvirt-4.7.0-1.fc29.x86_64 qemu-3.0.0-1.fc29.x86_64 How reproducible: 100% Steps to Reproduce: 1. Run virt-manager, click the new machine button 2. Tell it local iso image 3. Pick the Fedora-Workstation-Live-x86_64-29-1.2.iso file. 4. Create a 20G qcow2 image file to install to. 5. When it boots, tell it install to disk 6. Click on installation location 7. Pick vda1 (the only disk) and select [x] Custom partitioning 8. In the partitioning screen, select standard partition 9. Create the / partition at 18G 10. Create the swap partition at 3G (really 2 is all that's left) 11. Accept that partitioning 12. Begin installation 13. Watch it start doing disk operations, then see the spinning arrow stop Actual results: Hangs forever during install Expected results: Finishes installing Additional info: I also see this same problem trying to install the same f29 iso on a CentOS 7.5 host machine.
Created attachment 1507718 [details] processes running in hung virtual machine The virtual machine isn't frozen, just the install process. I was able to Ctrl-Alt-f3 and get a ps listing of all the processes which I've attached here.
Running "top" in the virtual machine shows everything idle.
Just tried again using the Advanced Custom partitioning blivet tool to create what should be the exact same two partitions, and the installing is going fine, it did the partitioning and is now installing software.
When I installed an f29 VM back on fedora 28, I may not have created a swap partition, but I definitely used the custom (rather than advanced custom) install, so maybe this is just a problem inside the f29 image that I just encountered with this specific partitioning.
And when I try the advanced partitioning on the CentOS 7.5 host, it also works, which really does point at the iso image as the one common factor, so maybe this should be an anaconda bug.
Please, attach files /tmp/*log with Anaconda logs.
Mysteries never cease. I can't count the number of times I tried to install and got a failure when I initially submitted this bug, but now an equal number of attempts fails to reproduce the installer hang. Perhaps it actually depends on phase of the moon. If I get it to fail again, I'll be sure to dig up the log files, but it doesn't look as if I can reproduce the failure any more at this point.
Created attachment 1508632 [details] anaconda.log file from VM where install hung I did finally manager to reproduce the hang by going back to the CentOS 7.5 host machine. The spinning arrow stopped spinning in front of the message "Creating disklabel on /dev/vda" blivet-gui-utils.log, and packaging.log were zero bytes so I'm not attaching them.
Created attachment 1508633 [details] dbus.log from hung install
Created attachment 1508634 [details] ifcfg.log from hung install
Created attachment 1508635 [details] program.log from hung install
Created attachment 1508636 [details] sensitive-info.log from hung install
Created attachment 1508637 [details] storage.log from hung install
On the off chance it was just the GUI that hung, not the install, I tried rebooting the virtual machine after it showed as idle for a long time, but that gave me a boot screen that showed a very slowing moving bright dot across three dots and never seemed to do any more than that. In case it matters, I installed very remotely using an x2go session from home to connect to my desktop at work which then ran virt-manager with a ssh connection to the CentOS 7.5 host machine.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-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 '29'. 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 29 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 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 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.