Bug 871143

Summary: kickstart bootloader --location=none ignored by installer
Product: [Fedora] Fedora Reporter: D. Marlin <dmarlin>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: anaconda-maint-list, awilliam, g.kaviyarasu, jonathan, ktdreyer, pbrobinson, stephent98, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: arm   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-11-29 18:41:40 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 245418, 752665    
Description Flags
F18 Calxeda Highbank kickstart config file. none

Description D. Marlin 2012-10-29 14:05:35 EDT
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/threads.py", line 91, in run
    threading.Thread.run(self, *args, **kwargs)
  File "/usr/lib/python2.7/threading.py", line 504, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/tmp/updates/pyanaconda/install.py", line 117, in doInstall
    payload.preInstall(packages=packages, groups=payload.languageGroups(ksdata.lang.lang))
  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
    map(self._selectYumPackage, self._requiredPackages)
  File "/tmp/updates/pyanaconda/packaging/yumpayload.py", 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 10:37:49 EDT
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.
Comment 2 D. Marlin 2012-11-02 15:10:44 EDT
I tried this update, but I still get the same error:

  errorpyanaconda.packaging.NoSuchPackage: grub2
Comment 3 Chris Lumens 2012-11-03 15:02:31 EDT
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 04:59:27 EST
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 10:40:55 EST
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-09 19:55:53 EST
anaconda-18.28-1.fc18 has been submitted as an update for Fedora 18.
Comment 7 Fedora Update System 2012-11-10 14:38:24 EST
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 01:10:10 EST
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 03:16:15 EST
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 04:33:33 EST
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 18:41:40 EST
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-29 23:47:21 EST
I have not filed one yet, but the action is on me to do so. Thanks!
Comment 13 D. Marlin 2012-11-30 00:32:34 EST
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.