Bug 1652092 - Installing fedora 29 iso in virt-manager hangs
Summary: Installing fedora 29 iso in virt-manager hangs
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 29
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2018-11-21 14:59 UTC by Tom Horsley
Modified: 2019-11-27 20:01 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-11-27 20:01:25 UTC
Type: Bug

Attachments (Terms of Use)
The xml file for hung install from /etc/libvirt/qemu directory (4.51 KB, text/html)
2018-11-21 14:59 UTC, Tom Horsley
no flags Details
processes running in hung virtual machine (12.13 KB, text/plain)
2018-11-21 15:05 UTC, Tom Horsley
no flags Details
anaconda.log file from VM where install hung (30.13 KB, text/plain)
2018-11-26 18:23 UTC, Tom Horsley
no flags Details
dbus.log from hung install (3.10 KB, text/plain)
2018-11-26 18:23 UTC, Tom Horsley
no flags Details
ifcfg.log from hung install (2.13 KB, text/plain)
2018-11-26 18:24 UTC, Tom Horsley
no flags Details
program.log from hung install (41.22 KB, text/plain)
2018-11-26 18:25 UTC, Tom Horsley
no flags Details
sensitive-info.log from hung install (117 bytes, text/plain)
2018-11-26 18:25 UTC, Tom Horsley
no flags Details
storage.log from hung install (114.30 KB, text/plain)
2018-11-26 18:26 UTC, Tom Horsley
no flags Details

Description Tom Horsley 2018-11-21 14:59:00 UTC
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):

How reproducible:

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.

Comment 1 Tom Horsley 2018-11-21 15:05:01 UTC
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.

Comment 2 Tom Horsley 2018-11-21 15:10:24 UTC
Running "top" in the virtual machine shows everything idle.

Comment 3 Tom Horsley 2018-11-21 15:25:26 UTC
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.

Comment 4 Tom Horsley 2018-11-21 15:30:19 UTC
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.

Comment 5 Tom Horsley 2018-11-21 15:45:20 UTC
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.

Comment 6 Vendula Poncova 2018-11-26 16:18:06 UTC
Please, attach files /tmp/*log with Anaconda logs.

Comment 7 Tom Horsley 2018-11-26 17:53:54 UTC
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.

Comment 8 Tom Horsley 2018-11-26 18:23:13 UTC
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.

Comment 9 Tom Horsley 2018-11-26 18:23:50 UTC
Created attachment 1508633 [details]
dbus.log from hung install

Comment 10 Tom Horsley 2018-11-26 18:24:30 UTC
Created attachment 1508634 [details]
ifcfg.log from hung install

Comment 11 Tom Horsley 2018-11-26 18:25:15 UTC
Created attachment 1508635 [details]
program.log from hung install

Comment 12 Tom Horsley 2018-11-26 18:25:56 UTC
Created attachment 1508636 [details]
sensitive-info.log from hung install

Comment 13 Tom Horsley 2018-11-26 18:26:37 UTC
Created attachment 1508637 [details]
storage.log from hung install

Comment 14 Tom Horsley 2018-11-26 18:36:51 UTC
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.

Comment 15 Ben Cotton 2019-10-31 20:27:42 UTC
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.

Comment 16 Ben Cotton 2019-11-27 20:01:25 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.