I just tested the latest F18 alpha RC3 and while the installation did complete, it took over 30 mins maxing out the CPU. I used the x86_64, live desktop image as source, and installed into a VM which had a single CPU, backed with a 2.1GHz i3-2310M. While the "installing software" message was displayed, I verified that CPU was the bottleneck using top, which should no idle and CPU shared between: anaconda + rsync*3 + loop3 + loop2 + kswapd Anaconda averaged about 30%, and the loop3 + rsync processes took the majority of the rest. I booted into the installed VM after and confirmed that access to the (virtual) disk performed at the full of the backing disk.
Yes, live installation is using rsync now instead of just dd. This has the distinct advantage of letting you pick which filesystem you want / to be on instead of using whatever the live image was made from, but the disadvantage of being slower. The spinner is supposed to spin but that's busted in gtk, and we're working on a better progress bar for live installs overall.
Thanks for the info. Is the CPU overhead due to compression? Could the compression scheme/level be adjusted to being faster? Why is anaconda taking so much CPU during this time? cheers, Pádraig.
The cpu thing is probably fixed by 43bcd9df591d9da6e4291a85f0e9b4eff1afbaba, which changes how progress reporting happens.
So http://git.fedorahosted.org/cgit/anaconda.git/commit/?id=43bcd9d stops the spinner spinning the CPU :) Excellent, thanks.