Description of problem: I'm trying to install Fedora 19 ppc64 on qemu. See: http://rwmj.wordpress.com/2013/08/27/booting-fedora-19-ppc64-netinst-under-qemu-on-x86-64/#content This worked once, but now I cannot get anaconda to complete the "spokes". Particularly it's impossible to complete the Installation Source (#1). It just says either: 1) [!] Installation source (Processing ...) which is understandable, or: 1) [!] Installation source (Closest mirror) which is not. If you try to go into 1, it just comes back to the menu, sometimes after pausing for a few minutes (but with no keyboard interaction). Very very occasionally, you'll go into 1 and it will actually offer the menu for installation source, let you select that and so on. However even on these rare occasions, it's still showing [!] afterwards. You cannot continue because it says: Please complete all spokes before continuing Version-Release number of selected component (if applicable): Fedora 19 netinst ppc64 from secondary mirror. How reproducible: Uncertain, but apparently very often. Steps to Reproduce: 1. Try to install. See instructions in blog posting above.
Can you attach the log files from after a failure like this? What is the installation source status message after the failure to set it up?
I've deleted the VM now. If you tell me precisely what file to capture, I will try to run the test again. The Installation Source status message was as described in comment 0.
Is it possible that you have to select the options in numeric order? I just did the install again and selected option 1 first. (Previously, since option 1 said "Processing ...", I was filling in the other options before going back to option 1).
OK I believe I understand now what's going on here. If I tail 'packaging.log' in another window, I can see that yum is doing some sort of depsolving ("TSINFO: Marking <some package> as install for <some other package>"). When that activity finishes (which seems to take many minutes), spokes 1 and 6 are enabled. Also every time you change the settings in spokes 1 or 6, it has to go through this hidden depsolving process again. This is all rather hidden and unexpected. Couldn't it give a bit more information about what's going on? Even saying "go to window 2 and tail -f /tmp/packaging.log" would be a good start.
yum does the same depsolving in graphical installation--it's a bit more apparent there since the spoke status changes dynamically. Unfortunately that kind of dynamic status update is not possible with text mode. We don't allow users to enter the Software Selection or Source Repo spoke in graphical installation if changes are made to either since the actions resultant from both are intertwined, and so downloading the yum metadata + depsolving must be complete if you wish to re-visit either spoke. The same constraints exist in graphical installation. Again, it is just more visible due to the dynamic status updates + being able to shade the icons when they are 'unavailable'. The 'Processing... ' status under spokes in text UI indicates the spoke is unavailable visibly. It probably needs to be made more obvious or documented somewhere--but the 'r' key will redraw the screen, and any changes to the spoke status will be reflected then. The log files can be found living in /tmp. tty2 should give you a shell where you can grab them.
Changing the resolution to indicate that you won't fix this, but it is still a bug.
There is nothing "intertwining" about it. There is absolutely no point to doing component selections until after relevant upstream repositories are selected and enabled.. The older, non-spoke-and-wheel did this in order, and corectly. If there are later steps to add additional repositories, then an instlalation user may have to back *up the ladder*, and repeat steps. But it's another loop, not an interweaving. Please stop with this confusing model. It's a poor way to describe a limited state machine, one described by basic flow charts for the last 50 years of computing, and one that is actively being confused and harmed by the "spoke and wheel" paradigm.