Bug 972266 - Installation Destination spoke behaves strangely when installing from a minimal (packages only) kickstart
Summary: Installation Destination spoke behaves strangely when installing from a minim...
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda   
(Show other bugs)
Version: 20
Hardware: All All
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
Whiteboard: https://fedoraproject.org/wiki/Common...
Keywords: CommonBugs
Depends On:
Blocks: F20FinalFreezeException 1042716
TreeView+ depends on / blocked
Reported: 2013-06-08 04:31 UTC by Adam Williamson
Modified: 2013-12-13 08:03 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1042716 (view as bug list)
Last Closed: 2013-12-10 23:28:28 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
anaconda.log (20.78 KB, text/plain)
2013-06-08 04:32 UTC, Adam Williamson
no flags Details
ifcfg.log (573 bytes, text/plain)
2013-06-08 04:33 UTC, Adam Williamson
no flags Details
packaging.log (232.54 KB, text/plain)
2013-06-08 04:33 UTC, Adam Williamson
no flags Details
program.log (45.17 KB, text/plain)
2013-06-08 04:33 UTC, Adam Williamson
no flags Details
storage.log (214.46 KB, text/plain)
2013-06-08 04:34 UTC, Adam Williamson
no flags Details
syslog (120.87 KB, text/plain)
2013-06-08 04:34 UTC, Adam Williamson
no flags Details

Description Adam Williamson 2013-06-08 04:31:50 UTC
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:





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.

Comment 1 Adam Williamson 2013-06-08 04:32:45 UTC
Created attachment 758426 [details]

Comment 2 Adam Williamson 2013-06-08 04:33:12 UTC
Created attachment 758427 [details]

Comment 3 Adam Williamson 2013-06-08 04:33:37 UTC
Created attachment 758428 [details]

Comment 4 Adam Williamson 2013-06-08 04:33:58 UTC
Created attachment 758431 [details]

Comment 5 Adam Williamson 2013-06-08 04:34:28 UTC
Created attachment 758441 [details]

Comment 6 Adam Williamson 2013-06-08 04:34:59 UTC
Created attachment 758442 [details]

Comment 7 Adam Williamson 2013-06-08 04:46:02 UTC
Proposing as Final FE at least (there's an argument for blocker, I guess...)

Comment 8 Adam Williamson 2013-06-10 17:59:38 UTC
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.

Comment 9 Adam Williamson 2013-06-27 15:16:56 UTC
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).

Comment 10 Andre Robatino 2013-07-16 04:33:18 UTC
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.

Comment 11 Andre Robatino 2013-07-16 06:53:05 UTC
Same result with a 1-byte ks file (the installer wouldn't start at all with a 0-byte file).

Comment 12 Larry O'Leary 2013-08-02 03:34:44 UTC
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.



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



And both installed systems produce the exact same final anaconda-ks.cfg:


# 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



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

Comment 13 Steve Tyler 2013-08-02 03:47:17 UTC
(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?

Comment 14 Adam Williamson 2013-08-02 05:14:41 UTC
Larry: I don't recall whether I actually completed the install and verified the bootloader was present in my tests, at this point...

Comment 15 Mike Ruckman 2013-11-14 18:26:39 UTC
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/

Comment 16 Martin Kolman 2013-12-03 14:53:32 UTC
I've tried it with TC3 & the packages-only kickstart:



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.

Comment 17 Adam Williamson 2013-12-03 17:31:44 UTC
oh hey, that's a nice bonus. i'll see if I can confirm.

Comment 18 Adam Williamson 2013-12-10 23:28:28 UTC
confirmed, this looks to be fixed in F20 final tc5, 972265 is still valid.

Note You need to log in before you can comment on or make changes to this bug.