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):
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
Hangs forever during install
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
Thank you for reporting this bug and we are sorry it could not be fixed.