Description of problem:
I tried to install latest snapshot of F20 (2013-11-25)
via local PXE as a VM using virt-manager on F19 (not only).
After entering the anaconda installation GUI and configuring
the disk space (also using RECLAIM DISK SPACE dialog) the environment
starts lagging and the VM consumes 100% CPU.
From what I observed the trigger is to enter the disk space
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Try to install latest F20 snapshot using PXE
2. switch to shell in anaconda
3. run 'top'
The GUI is horribly slow and CPU consumption is 100% by 'loop1' process
The GUI works OK, CPU usage is reasonable and F20 can
be installed without problems.
The most greedy process is all the time "loop1" which
should be a kernel thread.
I discussed this issue with vpodzime [at] redhat.com
from anaconda team before creating this bug...
Unfortunately without luck.
Proposed as a Blocker for 20-final by Fedora user thozza using the blocker tracking app because:
The Fedora 20 (snapshot from 2013-11-25) cannot be installed via PXE at the moment. Probably kernel process 'loop1' consumed 100% after entering the "disk space management dialog" in Anaconda and as a result making the anaconda GUI unusable.
Note that I tested installation only via PXE. The issue might be happening
also if installing via other means.
Can you please test on your affected system with a different method (not PXE) and see if it happens there too, and can you please attach the various anaconda log files from /tmp after reproducing the issue? (you can get to a console on ctrl-alt-f2 to help with this). thanks!
I was not able to reproduce the issue with downloaded latest TC3 iso,
nor with using Network install from the Internet.
I'll try to collect those logs you asked for tomorrow.
Discussed at 2013-11-27 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-27/f20-blocker-review-3.2013-11-27-17.01.log.txt . As others have run PXE install tests and could not reproduce the bug, and the reporter suggests in c#4 that he could not reproduce with TC3, this is rejected as a blocker. If it turns out to be still a valid and consistently reproducible bug, we could re-consider it.
I tried today to reproduce the issue with PXE installation.
I'm still able to reproduce it with F20 snapshot from 2013-11-25 we have
on the local PXE server in the office.
However I'm not able to reproduce it using F20-TC3 , so I guess the
problem is caused by the local server/local snapshot.
Sorry for the noise...