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. Will attach bugs. Note that before hitting this, I hit https://bugzilla.redhat.com/show_bug.cgi?id=972265 , so there's stuff from that bug in there too.
Created attachment 758426 [details] anaconda.log
Created attachment 758427 [details] ifcfg.log
Created attachment 758428 [details] packaging.log
Created attachment 758431 [details] program.log
Created attachment 758441 [details] storage.log
Created attachment 758442 [details] syslog
Proposing as Final FE at least (there's an argument for blocker, I guess...)
Discussed at 2013-06-10 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-10/f19final-blocker-review-4.2013-06-10-16.01.log.txt . Accepted as a freeze exception issue: this is obviously unintended and unexpected behaviour, and while it can be worked around, the workaround is quite hard to discover and to do, and looks really bad.
Note, this bug affects text mode too, only there it's worse: I haven't found a way to actually make the spoke happy. You just get stuck looping through it, making some choices, and then it complains that you haven't created a / partition and leaves the spoke at [!] (No disks selected).
Similar behavior with a single-line kickstart file specifying the timezone: timezone America/New_York --isUtc I'd like this to work so I can tell the installer to set the hardware clock to UTC even if Windows is detected (see bug 981793). BTW, I'm not sure if the correct syntax is --utc or --isUtc - I see --utc in the documentation, but --isUtc in an automatically generated kickstart file. BTW, in the minimal packages ks file, "install" at the top apparently isn't necessary, the behavior is the same even if it's omitted.
Same result with a 1-byte ks file (the installer wouldn't start at all with a 0-byte file).
For me this issue seems to be quite a bit worse then what seems to be indicated here. The workaround in the install destination spoke allows the install to proceed but the installed system has no grub and will not boot. Basically, after install I click reboot and after the machine boots I get a blank black screen with a blinking cursor in the top right corner. After booting into rescue mode I can see that /boot/grub2 is virtually empty. Also, after reviewing anaconda.program.log I can see grub2 was never executed. Here is the broken kickstart (which seems to match this BZ): url --url=http://home01/Fedora-19-x86_64 keyboard --vckeymap=us --xlayouts='us' lang en_US.UTF-8 timezone America/Chicago --isUtc rootpw --iscrypted $6$salt$8crtag4b3gU8LiNlhWfrHq8LF1g2TrNZo4lDEnbhR8iM71D2KnISNuLSsPuFWdfBlQDd5T2a8qv4bVvNSPrra. %packages @core %end And here is the working one (exact same but we specify the disk/part info): url --url=http://home01/Fedora-19-x86_64 keyboard --vckeymap=us --xlayouts='us' lang en_US.UTF-8 timezone America/Chicago --isUtc rootpw --iscrypted $6$salt$8crtag4b3gU8LiNlhWfrHq8LF1g2TrNZo4lDEnbhR8iM71D2KnISNuLSsPuFWdfBlQDd5T2a8qv4bVvNSPrra. bootloader --location=mbr --boot-drive=sda autopart --type=lvm clearpart --all --initlabel --drives=sda %packages @core %end And both installed systems produce the exact same final anaconda-ks.cfg: #version=DEVEL # Use network installation url --url="http://home01/Fedora-19-x86_64" ignoredisk --only-use=sda # Keyboard layouts keyboard --vckeymap=us --xlayouts='us' # System language lang en_US.UTF-8 # Network information network --bootproto=dhcp --device=p2p1 --noipv6 --activate network --hostname=pinky-vm01.oleary.home # Root password rootpw --iscrypted $6$salt$8crtag4b3gU8LiNlhWfrHq8LF1g2TrNZo4lDEnbhR8iM71D2KnISNuLSsPuFWdfBlQDd5T2a8qv4bVvNSPrra. # System services services --enabled="chronyd" # System timezone timezone America/Chicago --isUtc # System bootloader configuration bootloader --location=mbr --boot-drive=sda autopart --type=lvm # Partition clearing information clearpart --all --initlabel --drives=sda %packages @core chrony %end So, it appears that the only workaround for this issue is to specify all the disk parameters. I have tried variations to see if anything would make things better such as using bootloader only and/or autopart but nothing seemed to change the end result. Without those disk/part options in the kickstart file, no bootable system. Please note that I can use the broken kickstart file and then boot into rescue mode and run the grub2 commands myself to get the system to boot: chroot /mnt/sysimage grub2-install --no-floppy /dev/sda grub2-set-default "Fedora Linux, with Linux 3.9.5-301.fc19.x86_64" grub2-mkconfig -o /boot/grub2/grub.cfg
(In reply to Larry O'Leary from comment #12) ... > bootloader --location=mbr --boot-drive=sda ... Thanks for your report. Did you try adding just the bootloader option?
Larry: I don't recall whether I actually completed the install and verified the bootloader was present in my tests, at this point...
Discussed in 2013-11-14 Blocker Review Meeting [1]. This was voted a AcceptedFreezeException. This is obviously unintended and unexpected behaviour, and while it can be worked around, the workaround is quite hard to discover and to do, and looks really bad. We would accept a patch after freeze if self-contained and safe. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-14/
I've tried it with TC3 & the packages-only kickstart: install %packages @core nano fpaste %end And it seems to work fine - I've entered the installation destination spoke, clicked reclaim, delete all and everything went fine. No repeated entries or explicit bootloader installation was necessary. So I would say it is fixed. On the other hand, the related bug 972265 seems to be still going strong.
oh hey, that's a nice bonus. i'll see if I can confirm.
confirmed, this looks to be fixed in F20 final tc5, 972265 is still valid.