Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
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...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 20
Hardware: All
OS: All
unspecified
high
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
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:
Clone Of:
: 1042716 (view as bug list)
Environment:
Last Closed: 2013-12-10 23:28:28 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
anaconda.log (deleted)
2013-06-08 04:32 UTC, Adam Williamson 		no flags Details
ifcfg.log (deleted)
2013-06-08 04:33 UTC, Adam Williamson 		no flags Details
packaging.log (deleted)
2013-06-08 04:33 UTC, Adam Williamson 		no flags Details
program.log (deleted)
2013-06-08 04:33 UTC, Adam Williamson 		no flags Details
storage.log (deleted)
2013-06-08 04:34 UTC, Adam Williamson 		no flags Details
syslog (deleted)
2013-06-08 04:34 UTC, Adam Williamson 		no flags Details
View All

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:

---------------

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.
Comment 1 Adam Williamson 2013-06-08 04:32:45 UTC 
Created attachment 758426 [details]
anaconda.log
Comment 2 Adam Williamson 2013-06-08 04:33:12 UTC 
Created attachment 758427 [details]
ifcfg.log
Comment 3 Adam Williamson 2013-06-08 04:33:37 UTC 
Created attachment 758428 [details]
packaging.log
Comment 4 Adam Williamson 2013-06-08 04:33:58 UTC 
Created attachment 758431 [details]
program.log
Comment 5 Adam Williamson 2013-06-08 04:34:28 UTC 
Created attachment 758441 [details]
storage.log
Comment 6 Adam Williamson 2013-06-08 04:34:59 UTC 
Created attachment 758442 [details]
syslog
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.

%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
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:

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.
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.