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
Bug 871143 - kickstart bootloader --location=none ignored by installer
Summary: kickstart bootloader --location=none ignored by installer
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 18
Hardware: arm
OS: Linux
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: ARMTracker F18-accepted, F18FinalFreezeExcept
TreeView+ depends on / blocked
Reported: 2012-10-29 18:05 UTC by D. Marlin
Modified: 2012-11-30 05:32 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-11-29 23:41:40 UTC
Type: Bug

Attachments (Terms of Use)
F18 Calxeda Highbank kickstart config file. (2.18 KB, application/octet-stream)
2012-10-29 18:05 UTC, D. Marlin
no flags Details

Description D. Marlin 2012-10-29 18:05:35 UTC
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:

  bootloader --location=none

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


How reproducible:


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

Actual results:

Starting package installation process
Traceback (most recent call last):
  File "/tmp/updates/pyanaconda/", line 91, in run, *args, **kwargs)
  File "/usr/lib/python2.7/", line 504, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/tmp/updates/pyanaconda/", line 117, in doInstall
    payload.preInstall(packages=packages, groups=payload.languageGroups(ksdata.lang.lang))
  File "/tmp/updates/pyanaconda/packaging/", line 1193, in preInstall
  File "/tmp/updates/pyanaconda/packaging/", line 1114, in checkSoftwareSelection
  File "/tmp/updates/pyanaconda/packaging/", line 1101, in _applyYumSelections
  File "/tmp/updates/pyanaconda/packaging/", line 1176, in selectRequiredPackages
    map(self._selectYumPackage, self._requiredPackages)
  File "/tmp/updates/pyanaconda/packaging/", line 1002, in _selectYumPackage
    raise NoSuchPackage(pkgid)
pyanaconda.packaging.NoSuchPackage: grub2

Expected results:

  installation completes

Additional info:

  The kickstart config used is attached for reference.

Comment 1 Chris Lumens 2012-10-30 14:37:49 UTC
This might be entirely too simplistic of an updates image, but can you try updates=  Maybe I'll get lucky.

Comment 2 D. Marlin 2012-11-02 19:10:44 UTC
I tried this update, but I still get the same error:

  errorpyanaconda.packaging.NoSuchPackage: grub2

Comment 3 Chris Lumens 2012-11-03 19:02:31 UTC
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.

Comment 4 D. Marlin 2012-11-05 09:59:27 UTC
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?

Comment 5 D. Marlin 2012-11-08 15:40:55 UTC
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:

  bootloader --location=none

It shows:

  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:

  bootloader --location=partition

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.

Comment 6 Fedora Update System 2012-11-10 00:55:53 UTC
anaconda-18.28-1.fc18 has been submitted as an update for Fedora 18.

Comment 7 Fedora Update System 2012-11-10 19:38:24 UTC
Package anaconda-18.28-1.fc18:
* 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).

Comment 8 Adam Williamson 2012-11-23 06:10:10 UTC
D. Marlin: 18.28 is stable now and in TC9 and RC1, can you double-check this is fixed and close the bug? Thanks!

Comment 9 Ken Dreyer 2012-11-27 08:16:15 UTC
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.

Comment 10 Adam Williamson 2012-11-28 09:33:33 UTC
Ken: can you please file a new bug report for that? It should probably be tracked separately. Thanks!

Comment 11 Adam Williamson 2012-11-29 23:41:40 UTC
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?

Comment 12 Ken Dreyer 2012-11-30 04:47:21 UTC
I have not filed one yet, but the action is on me to do so. Thanks!

Comment 13 D. Marlin 2012-11-30 05:32:34 UTC
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.

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