Red Hat Bugzilla – Bug 864981
BootLoaderError: bootloader install failed
Last modified: 2014-02-05 07:32:13 EST
Description of problem:
I was installing F18 Beta TC3, DVD install, on normal, automatically parted disk (using qemu), when during "installing bootloader" it showed this traceback.
Version-Release number of selected component:
libreport version: 2.0.14
cmdline: /usr/bin/python /sbin/anaconda
:The following was filed automatically by anaconda:
:anaconda 18.14 exception report
:Traceback (most recent call first):
: File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1531, in install
: raise BootLoaderError("bootloader install failed")
: File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 1542, in write
: File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 2205, in writeBootLoader
: File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 122, in doInstall
: writeBootLoader(storage, payload, instClass)
: File "/usr/lib64/python2.7/threading.py", line 504, in run
: self.__target(*self.__args, **self.__kwargs)
: File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 87, in run
: threading.Thread.run(self, *args, **kwargs)
:BootLoaderError: bootloader install failed
Created attachment 624926 [details]
Created attachment 624927 [details]
Created attachment 624928 [details]
Created attachment 624929 [details]
Created attachment 624930 [details]
Created attachment 624931 [details]
Created attachment 624932 [details]
Created attachment 624933 [details]
Created attachment 624934 [details]
Created attachment 624935 [details]
Created attachment 624936 [details]
Created attachment 624937 [details]
Created attachment 624938 [details]
Created attachment 624939 [details]
16:41:15,605 ERR program: /usr/sbin/grub2-bios-setup: warning: Attempting to install GRUB to a disk with multiple partition labels. This is not supported yet..
16:41:15,617 ERR program: /usr/sbin/grub2-bios-setup: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
16:41:15,617 ERR program: /usr/sbin/grub2-bios-setup: error: will not proceed with blocklists.
Now I've seen everything.
Proposing as Beta blocker:
The installer must be able to complete an installation using automatic partitioning to any sufficiently large target disk, whether unformatted, empty, or containing any kind of existing data
Discussed at 2012-10-15 QA meeting acting as a blocker review meeting: http://meetbot.fedoraproject.org/fedora-meeting/2012-10-15/fedora-qa.2012-10-15-15.00.log.txt . Agreed that we need more details on the exact reproducer here; it sounds like the disk label on the affected disk is odd / corrupted somehow, given that the errors come direct from grub and are atypical. It might help if bcl or pjones could take a look, too.
Also seen on http://comments.gmane.org/gmane.comp.boot-loaders.grub.user/1335 .
Grub was honestly and correctly confused by ambiguity in the partitioning.
Anaconda was told(?) to reuse a slightly bad disk partitioning. The "containing any kind of existing data" criteria can obviously only apply if Anaconda is permitted to (re)partition. I assume it would have worked if Anaconda had been told/allowed to run wipefs and parted?
I don't know what could be done to improve the situation. Grub could perhaps have more 'dryrun' options that could be used for early testing, or the checks could be done in grub2-probe too.
Tentative conclusion: The system was slightly broken in subtle way and everything worked as expected and Grub detected the small problem and prevented a bigger problem.
(In reply to comment #18)
> Anaconda was told(?) to reuse a slightly bad disk partitioning.
Mads, what does "slightly bad disk partitioning" mean? Does it mean that the disk had both msdos and gpt labels (a hybrid MBR or what it is called) and they didn't match? Or what was the source of the confusion?
I don't think it is related to hybrid.
I got the impression that it could be more like a disk that both looks like a msdos partitioning table and like a unpartitioned filesystem.
The code is not easy to grok - it seems like the actual condition is different from what the message indicates:
As far as the criteria go:
"The "containing any kind of existing data" criteria can obviously only apply if Anaconda is permitted to (re)partition."
well, not entirely, the idea is to cover installation into free space on an existing, partitioned disk too. But we should probably except a case such as this, where there's an error in the partition table (assuming that turns out to actually be the issue), yes. I'll think about that in my ongoing thoughts about re-doing the partitioning criteria...
Discussed at 2012-10-17 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-17/f18beta-blocker-review-4.2012-10-17-16.00.log.txt .
This issue is still not entirely clear, but on balance it looks like the problem here is some kind of messed-up partition table causing grub2 problems. On that basis, it's rejected as a Beta blocker on the basis that we don't intend to cover invalid disk layouts with the criterion in question. It can be re-proposed if it turns out the layout is messed-up and this is just a bug in grub2.
It would probably help if Jan could provide a dd dump of the start of the disk in question (containing the partition table), or even if we could get someone from the install team in the same room with the offending disk.
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '18'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 18's end of life.
Thank you for reporting this issue and we are sorry that we may not be
able to fix it before Fedora 18 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior to Fedora 18's end of life.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.