Created attachment 913591 [details] program.log Description of problem: I get this message at the end of the installation process, before a grub.cfg is created. System is not bootable. Version-Release number of selected component (if applicable): anaconda-21.45-1.fc21.x86_64 How reproducible: If the kernel can't write the target, this bug always happens and the system is always unbootable; and any prior OS is unbootable also. Steps to Reproduce: NA Actual results: Anaconda tries to change the NVRAM entry before creating grub.cfg. Expected results: Anaconda either needs to write the NVRAM entry before modifying the drive (?) to see if the NVRAM modification succeeds; or it needs to do it dead last after the grub.cfg has been created in which case the lack of a NVRAM entry is non-critical because of shim and fallback will still permit the system to boot. But not if we don't have a grub.cfg. Additional info:
Created attachment 913592 [details] anaconda.log
I just now realized there's a No and Yes button to answer the question whether I want to continue with installation anyway. I click yes, and the installation completes. However there is no /etc/default/grub, no /boot/efi/EFI/fedora/grub, and thus the system isn't bootable. Proposing as a Fedora 21 alpha blocker.
Created attachment 913625 [details] program.log (completed) This is the completed install program.log; previous program.log stops at the error message. So this one includes everything that happens after choosing Yes. grub2-mkconfig is not listed, hence no grub.cfg.
so, I'm a bit unclear from the report. are you saying that UEFI installs always fail in Rawhide? that could be an Alpha blocker. if this bug is more "anaconda could do something a bit more elegant in the case that creating the UEFI boot manager entry fails due to some firmware problem", I find it a bit harder to count that as an Alpha blocker. could you provide a clear Alpha blocker justification?
This bug is anaconda's failure to write out a grub.cfg even when I've asked it to continue with the installation. No grub.cfg, no booting of the installed system. Right now, I'm always running into bug 1114775. That's probably a beta or final blocker, but setting an NVRAM entry is a lower priority than creating grub.cfg; and I'm missing a grub.cfg anytime I hit bug 114775. And I'd expect that anyone else who hits that bug or any other NVRAM+kernel related bug, will also hit this bug and be unable to boot the installed Fedora.
they'd be unable to boot it without manual intervention in any case, so it's not precisely clear-cut. can you please provide a single cohesive and complete alpha blocker justification? I'm not seeing one at present, for *this* bug. cases where install already went somewhat wrong, and we'd like it not to go much further wrong, do not usually constitute alpha blockers. to my mind, #1114775 is the more likely candidate for blocker status, if it affects a sufficient number of systems: *that's* the bug where things actually go wrong, this one is damage control.
Booting the installed system is an alpha release criterion: "A system installed with a release-blocking desktop must boot ..." nothing that comes later matters in this case, because the failure happens at GRUB. I get to GRUB, but there is no menu. There's no menu because there's no grub.cfg. There's no grub.cfg because anaconda didn't create it. And the NVRAM failure doesn't prevent the creation of grub.cfg. The entire purpose of the "continue anyway" feature was to permit completion of bootloader and postinstall operations despite NVRAM modification failures, yet the installer fails to do these things when there is NVRAM modification failure. I'm not sure what your first sentence means. shim.efi+fallback.efi have a way to make sure the system gets to GRUB. And in fact I do get a grub rescue menu. The reason it's rescue is because there's no grub.cfg. The NVRAM boot entry is icing. The grub.cfg is cake. We must have the cake.
The expected normal success case is "bootloader installation and NVRAM modification both succeed". In that case, the installed system boots, yes? It only fails in the case that NVRAM modification fails. We are already in a non-optimal case, here, not the 'typical' case. The criterion notes include a "System-specific issues" note, reading "System-specific bugs don't necessarily constitute an infringement of this criterion - for instance, if the system fails to boot because of a bug in the support some specific system's hardware, that is unlikely to constitute a violation unless the system is an extremely popular one. See Blocker_Bug_FAQ for more discussion of this." (I see there's a typo in that. will fix.) Remember, we're discussing whether this blocks an Alpha release, not whether it's a bug. Clearly it's a bug, your reasoning is entirely sound there: there is a bug in the code that's meant to allow us to handle the case where NVRAM modification fails relatively gracefully. Yes. The question is whether that fallback code being buggy constitutes a reason not to make an Alpha release.
(In reply to Adam Williamson (Red Hat) from comment #8) > It only fails in the case that NVRAM modification fails. We are already in a > non-optimal case, here, not the 'typical' case. Non-optimal but not critical. The critical failure preventing boot is this bug, which occurs due to its own deficiency, not because of some missing prerequisite from another bug. If there were a grub.cfg, the system would boot. > The criterion notes include a "System-specific issues" note, reading > "System-specific bugs don't necessarily constitute an infringement of this > criterion - for instance, if the system fails to boot because of a bug in > the support some specific system's hardware, that is unlikely to constitute > a violation unless the system is an extremely popular one. See > Blocker_Bug_FAQ for more discussion of this." a.) This bug is not system specific. It always happens when efibootmgr exit status is non-zero. Other bugs are system specific but also are themselves non-fatal. This one is fatal, and is why all of the other bugs result in installation failure. b.) The system fails to boot directly because of this bug, not any other bug. c.) The system is extremely popular. See the 2nd sentence of the 1st paragraph. http://mjg59.dreamwidth.org/31714.html > Remember, we're discussing whether this blocks an Alpha release, not whether > it's a bug. And I think it should block for reasons given. It's not just about bug 1114775, it's about all NVRAM related bugs that anaconda then barfs on for no good reason, resulting in non-bootable installs. This reduces an already small UEFI test pool. Block on this bug, or block on all NVRAM related bugs, some of which we may not be able to fix due to firmware bugs?
Discussed at the 2014-07-09 Fedora 21 alpha blocker review meeting. While this could result in broken systems, it seems to be limited to a minority of systems and thus, is rejected as a blocker for Fedora 21 alpha. If this turns out to affect more system types than we understood, please re-submit as a blocker.
Created attachment 917197 [details] patch to always write the config
*** Bug 1085507 has been marked as a duplicate of this bug. ***