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: anaconda-18.14 Additional info: libreport version: 2.0.14 cmdline: /usr/bin/python /sbin/anaconda kernel: 3.6.1-1.fc18.x86_64 description: :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 : self.install() : File "/usr/lib64/python2.7/site-packages/pyanaconda/bootloader.py", line 2205, in writeBootLoader : storage.bootloader.write() : 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] File: anaconda-tb
Created attachment 624927 [details] File: product
Created attachment 624928 [details] File: type
Created attachment 624929 [details] File: ifcfg.log
Created attachment 624930 [details] File: storage.log
Created attachment 624931 [details] File: version
Created attachment 624932 [details] File: environ
Created attachment 624933 [details] File: anaconda.log
Created attachment 624934 [details] File: syslog
Created attachment 624935 [details] File: hashmarkername
Created attachment 624936 [details] File: packaging.log
Created attachment 624937 [details] File: cmdline_file
Created attachment 624938 [details] File: release
Created attachment 624939 [details] File: program.log
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 https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
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 . AFAICS: 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: http://bzr.savannah.gnu.org/lh/grub/trunk/grub/annotate/head:/util/grub-setup.c#L378
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 bug. Thank you for reporting this bug and we are sorry it could not be fixed.