Hide Forgot
+++ This bug was initially created as a clone of Bug #972266 +++ Prompted by robatino, I did some testing with a really minimal kickstart. This one, in fact: http://www.happyassassin.net/ks/packages_only.ks . It contains only this: --------------- install %packages @core nano fpaste %end --------------- how I'd expect that to behave is that the package selection specified would be used, but I could specify everything else interactively, just like a non-kickstart install. It kinda works, but there are some quirks. This bug is one of them. The "Installation Destination" bug comes up as "No disk selected". Okay, fine, I'd expect that. If I go through the way I would for a simple interactive install - click in, my disk is selected, click Done, click "Reclaim space" on Installation Options (the disk is full to start with), choose to wipe the disk, and complete - the hub still says "No disk selected". Now if I go back in, click Done, Installation Options comes up in its 'you've got plenty of space' mode. I complete it, and I'm back at the hub and now the spoke is saying "No bootloader configured". Just going through the spoke again doesn't clear it this time, but I can clear it if I go in, go to the bootloader screen (where it claims the disk is selected as the bootloader target, note), set it to install no bootloader, complete the spoke, then go back in, change 'back' to the disk as the bootloader target, and complete the spoke *again*. Finally, at this point, it's happy. It's almost like it does one thing on each run through: first time through it clears the existing disk contents (but doesn't do autopart), second time it does autopart (but doesn't set the bootloader).... What I'd expect is for it to behave just like a non-kickstart install: I go through the spoke just once, set all my choices, and then I'm done.
Bug exists in RHEL 7 Beta exactly as described in Fedora 19 report, see original report for logs. Two of us have confirmed the bug does *not* exist in Fedora 20, so *something* that changed between F19 and F20 fixes this; but it was an incidental fix, the devs didn't specifically intend to patch this bug, so it may take a bit of tracking down.
Unable to reproduce in RHEL 7.0 GA.
did you see https://bugzilla.redhat.com/show_bug.cgi?id=972265 when you tested?