Description of problem: After all packages complete installing, receive a message "There was an error installing the bootloader. The system may not be bootable." Version-Release number of selected component (if applicable): Fedora-17-TC2-x86_64-DVD.iso anaconda 17.23 How reproducible: 1 for 1 Steps to Reproduce: 1. Burn ISO to DVD. DVD verified to checksum. 2. Boot from DVD. Run "Use All Space" 3. Pared down some packages...then executed. Actual results: error installing bootloader Expected results: to not get this error Regression: This does NOT occur with the LiveCD either burned to DVD media or dd'd to a stick. 1 for 1 for those as well. Additional info:
Created attachment 580936 [details] anaconda.log
Created attachment 580937 [details] program.log
Created attachment 580938 [details] storage.log
Hardware: Apple MacbookPro4,1 This is EFI boot, not CSM.
it seems like program.log just suddenly stops halfway through the bootloader process with no obvious error. The last thing it tries, I believe, is removing the existing 'Fedora' entry in the EFI boot manager. So could the bug in fact be that attempting to remove an existing 'Fedora' entry has problems with this firmware? Does the install succeed if you start in a state where there's no entry named 'Fedora' in the EFI boot manager? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This is probably user confusion. If I do a default DVD "Graphical Desktop" with "Customize Later" selected, the problem is NOT reproducible. I can reproduce the previous failure by choosing Customize Now and: Uncheck Gnome. Check Xfce Uncheck all Applications Uncheck Printing Support Uncheck everything in Base System except X Window System So probably my own doing, but I'd propose it shouldn't be possible for the user to customize packages and end up with an unbootable system. *shrug*
(In reply to comment #5) >Does the install succeed if you start in a state where there's no > entry named 'Fedora' in the EFI boot manager? No idea what you mean by "EFI boot manager".
When you're using EFI, the firmware itself handles booting different operating systems. Instead of there being a 'master' bootloader in the MBR of whatever disk you're booting, OSes basically are supposed to set up a bootloader just for booting themselves, in a standardized way (this is what grub-efi is) and then tell the EFI firmware where this bootloader is; then the firmware constructs a boot menu that lets you pick which OS to boot. When you pick to boot OS X or 'other OS' (or whatever the choices are, I forget) at boot time on a Mac, you're actually interacting with Apple's (idiotic) take on an 'EFI boot manager'. It seems weird that you can trigger this by de-selecting packages for installation to the target system, as I thought all the setup steps happen from the anaconda environment, not from the installed environment, but the anaconda guys might have some idea... -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Going back to comment five, (In reply to comment #5) >Does the install succeed if you start in a state where there's no > entry named 'Fedora' in the EFI boot manager? This question I don't understand so I can't answer it. a.) When I startup with option key, with DVD inserted, I see only two options: Windows and EFI Boot. There is no Fedora option. b.) If there were a Fedora option, the UI doesn't present a way for me to remove it.
I just got this doing a koan --replace-self install on an existing Fedora 17 i386 physical machine. Did not see it doing the same on a F17 x86_64 VM. System was indeed not bootable with: error: unknown filesystem Entering rescue mode... grub rescue> non-EFI so if this needs to be a separate bug I can do that. I'm afraid I neglected to copy the logs before reboot. There was a grub warning message about not setting GRUB_DEFAULT correctly or some such.
My problem turned out to be bug 818378, which is unlikely to be related to this report. Sorry for the noise.
chris: you can see and manipulate all the entries in the EFI boot manager by booting Fedora via EFI - any old way, a live image, the rescue mode of the installer, whatever - and using the 'efibootmgr' tool. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
The problem does not occur if efibootmgr reports: BootCurrent: 0000 BootFFFF* The problem does occur when efibootmgr reports: BootCurrent: 0000 BootOrder: 0000 Boot0000* Fedora BootFFFF* After the bootloader error, efibootmgr reports: BootCurrent: 0000 BootOrder: 0000 BootFFFF* Also, the problem when it occurs is reproducible with the Minimal Install option, not only as in comment #6.
So to summarize, what we have is that *if* there's an existing 'Fedora' EFI boot manager entry and _also_ you: Uncheck Gnome. Check Xfce Uncheck all Applications Uncheck Printing Support Uncheck everything in Base System except X Window System then you hit this bug? Okay. Well, um, that's...odd. Any ideas, anaconda folks? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Also occurs with the "Minimal" option + "Customize Later" if efibootmgr reports, prior to the installation attempt: BootCurrent: 0000 BootOrder: 0000 Boot0000* Fedora BootFFFF* However, here's a case where "Minimal" option + "Customize Later does NOT reproduce the problem: BootCurrent: 0000 BootOrder: 0000,0080 Boot0000* Fedora Boot0080* Mac OS X BootFFFF* I'm confused and don't really understand what's causing the failure. What I can say is that: a.) So far, every time NVRAM is clear of a Fedora entry in advance of running anaconda, no matter the packages chosen for install, the error does not occur. b.) Most of the time, NVRAM containing a Fedora entry, causes the failure to occur either as described in comment 6 (manually parred packages) or the Minimal installation option. The one exception so far is if NVRAM also contains a Mac OS X entry, which I've tried twice and neither time did the error occur.
OK so here is part of the confusion, it fails every other time. I think this is because when the error occurs it removes the Fedora entry, so the next attempt works, which then sets a Fedora entry and then the next attempt fails. I've reproduced this even with the default Graphical install, no changes, Customize Later. I have no other EFI hardware to try this on, so it may not be a Mac EFI specific bug.
I don't recall ever seeing it in my EFI tests, FWIW. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
dmesg has a curious entry at the time of this error: efivars: DataSize & Attributes must be valid! I will attach dmesg and new logs. This is 100% reproducible, every other time.
Created attachment 583424 [details] anaconda.log (new)
Created attachment 583425 [details] program.log (new)
Created attachment 583426 [details] storage.log (new)
Created attachment 583427 [details] dmesg entry of interest occurs at 1617
Can this still be reproduced with F17 final?
It is reproducible on every other (re)installation attempt with F17 final.
Reproducible on MacbookPro 4,1, EFI boot. And the installation type, Graphical Desktop, or Minimal, or Customize Now (and choosing packages) doesn't matter - there is always failure on every other attempt with the message: "There was an error installing the bootloader. The system may not be bootable." The resulting installed system is not bootable, I'm dropped to a grub> prompt.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. 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 '17'. 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 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 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 17'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 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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. Thank you for reporting this bug and we are sorry it could not be fixed.