Red Hat Bugzilla – Bug 871143
kickstart bootloader --location=none ignored by installer
Last modified: 2012-11-30 00:32:34 EST
Created attachment 635116 [details]
F18 Calxeda Highbank kickstart config file.
Description of problem:
For ARM (which uses U-Boot) we are using GRUB2 as the bootloader class, but not actually using GRUB2. In the kickstart we have:
Based on an IRC conversation, it looks like something should set bootloader.skip_bootloader if ksdata.bootloader.location is None and then BootLoader.write should exit early if self.skip_bootloader is True.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start a PXE-boot, kickstart install
2. Select the only disk drive (sda) and use all space
3. After Starting package installation, backtrace occurs
Starting package installation process
Traceback (most recent call last):
File "/tmp/updates/pyanaconda/threads.py", line 91, in run
threading.Thread.run(self, *args, **kwargs)
File "/usr/lib/python2.7/threading.py", line 504, in run
File "/tmp/updates/pyanaconda/install.py", line 117, in doInstall
File "/tmp/updates/pyanaconda/packaging/yumpayload.py", line 1193, in preInstall
File "/tmp/updates/pyanaconda/packaging/yumpayload.py", line 1114, in checkSoftwareSelection
File "/tmp/updates/pyanaconda/packaging/yumpayload.py", line 1101, in _applyYumSelections
File "/tmp/updates/pyanaconda/packaging/yumpayload.py", line 1176, in selectRequiredPackages
File "/tmp/updates/pyanaconda/packaging/yumpayload.py", line 1002, in _selectYumPackage
The kickstart config used is attached for reference.
This might be entirely too simplistic of an updates image, but can you try updates=http://clumens.fedorapeople.org/871143.img? Maybe I'll get lucky.
I tried this update, but I still get the same error:
anaconda wanting to install the grub2 package has nothing to do with the bootloader command, though. It's entirely based upon whether the platform class asks for a specific bootloader package. So we'd also need a new platform class that doesn't want grub2.
I have submitted a patch to add a very basic U-Boot bootloader class, and change the ARM platform class to use it instead of GRUB2:
Will this be sufficient to address the issue?
Based on feedback, I have submitted an updated patch:
While this patch removes the need to use GRUB2 as a 'placeholder' to the bootloader, and elimitates the backtrace, it does not perform a kickstart install without user interaction when using:
No disks selected; please select at least one disk to install to.
you have not created a bootloader stage1 target device
and requires input for selecting:
2) [ ] Install Destination
(Error checking storage configuration)
It will, however, perform a kickstart install without user interaction when using:
Does this look correct? We are not actually installing the U-Boot bootloader, but are installing a U-Boot configuration file on the /boot partition.
anaconda-18.28-1.fc18 has been submitted as an update for Fedora 18.
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-18.28-1.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
D. Marlin: 18.28 is stable now and in TC9 and RC1, can you double-check this is fixed and close the bug? Thanks!
Previously I could use Kickstart to set some really basic parameters in an installation, and then do the rest manually (like partitioning and selecting a boot device).
With this change in 18.28, when I'm using Kickstart without any bootloader parameter, Anaconda will skip writing a bootloader with no visible notification in the UI. I can manually select a boot device via the UI, but Anaconda will silently discard my choice. I ended up spinning around for a while in bug 875430 because of this change.
Ken: can you please file a new bug report for that? It should probably be tracked separately. Thanks!
No response from D. Marlin, I'm closing this one provisionally. If it turns out to still be present, it can be re-opened. Ken, did you file yours separately?
I have not filed one yet, but the action is on me to do so. Thanks!
I apologize for not testing this sooner, but we have had some other (unrelated) issues preventing testing. I will test it as soon as possible. If I encounter problems I will open another issue.
Thank you for your prompt response and fix for this issue.