After a frozen install while trying to make a dual-boot system I had to hard-reboot my laptop using the power button.
On restarting, I was greeted with a UEFI message telling me that there was no bootable device installed! I quickly inserted a boot CD and managed to boot into my installed Fedora 20 by editing the booted CD's grub commands (thank goodness for grub's command line completion!).
I therfore know that my Fedora installation (including the EFI partition) is intact and that my crash had somehow corrupted my UEFI NVRAM.
A quick check with 'efibootmgr -v' confirmed this, as it just listed the basic 'fallback' paths (no filepaths to the Fedora installed EFI files).
The simple answer was therefore to re-add the entry for Fedora and reboot. In order to get the correct syntax for efibootmgr I grep'd '/var/log/anaconda.program.log' and found:
'efibootmgr -c -w -L Fedora -d /dev/sda -p 1 -l \EFI\fedora\shim.efi'.
I simply escaped the back-slashes by changing them to double-back-slashes and ran the command as root.
I confirmed that everything had worked using 'efibootmgr -v' again and it showed that the entry was there, so I rebooted.
Unfortunately, I was greeted by the same 'no bootable device' message as before at which point I had to use the boot CD to get back in again.
To my suprise 'efibootmgr -v' didn't show the entry that I'd just created - it had simply vanished.
I Googled and Googled and got nowhere. To get out of this predicament, I installed Fedora again in the partition I'd earmarked for the dual boot, at which point anaconda os-probed all partitions/installations, re-created grub's grub.cfg file and fixed the NVRAM. I was then able to successfully boot my laptop. Fortunately, there was a kernel update waiting for me, so installing that reconfigured grub2 and my main Fedora installation was the default in grub again.
While I'm now working again, there is still the issue of not being able to alter NVRAM using 'efibootmgr' directly.
My question therefore is: Does anaconda do something else after running 'efibootmgr' to make it permanent? Or: Why can anaconda update NVRAM using efibootmgr, while I can't?
Thanks in advance.
On Jul 10, 2014, at 4:56 AM, "Williams, Gareth" gareth@garethwilliams.me.uk wrote:
My question therefore is: Does anaconda do something else after running 'efibootmgr' to make it permanent? Or: Why can anaconda update NVRAM using efibootmgr, while I can't?
'no bootable device' sounds suspiciously like a BIOS message. It's not a failure message I'd expect from an UEFI systems due to how it does fallback - or at least should. It should arrive at worst to EFI/BOOT/BOOTX64.EFI which ought to be shim.efi, which with help from fallback.efi ought to write a new entry in NVRAM for itself.
NVRAM garbage collection is a weak area of UEFI. Some of them are slow to do what they're told, some of them barf if they're told to do too many things too quickly. There's all sorts of non-deterministic failure here. And then there's also kernel versions. efibootmgr is a userspace program that tells the kernel to do something to NVRAM.
Apple has dealt with this forever with CMOS and NVRAM. Even before moving to EFI ~10 years ago Macs had parameter RAM for storing things like volume, brightness, and which disk to boot off of. All Macs since practically the dawn of time have the same keyboard shortcut to "zap" it, effectively clearing it entirely.
Anyway, the problem you're facing is it's unclear whether it's a firmware bug or a kernel bug. I'd make sure the firmware is updated. See if users are having problems with that version if it's already at the latest version and was recently posted. And then use newer kernels and see if the behavior changes - the Fedora 20 media is using kernel 3.11.10, and 3.16 is mainline. So it might be worth grabbing a Fedora 21 pre-alpha build to see if you get different results making NVRAM modifications with efibootmgr.
Chris Murphy
On 11/07/14 06:24, Chris Murphy wrote:
On Jul 10, 2014, at 4:56 AM, "Williams, Gareth" gareth@garethwilliams.me.uk wrote:
My question therefore is: Does anaconda do something else after running 'efibootmgr' to make it permanent? Or: Why can anaconda update NVRAM using efibootmgr, while I can't?
'no bootable device' sounds suspiciously like a BIOS message. It's not a failure message I'd expect from an UEFI systems due to how it does fallback - or at least should. It should arrive at worst to EFI/BOOT/BOOTX64.EFI which ought to be shim.efi, which with help from fallback.efi ought to write a new entry in NVRAM for itself.
Why would it come up in 'BIOS' mode? I've not changed any settings on the laptop to enable that - unless my laptop's firmware automatically does it when it can't find any EFI to boot. But as you said that it should arrive at BOOTX64.EFI (which is present) then even that theory falls at the first hurdle.
Anyway, the problem you're facing is it's unclear whether it's a firmware bug or a kernel bug. I'd make sure the firmware is updated. See if users are having problems with that version if it's already at the latest version and was recently posted. And then use newer kernels and see if the behavior changes - the Fedora 20 media is using kernel 3.11.10, and 3.16 is mainline.
I didn't boot from the CD image - I merely used the EFI and GRUB from the CD, then edited the GRUB line to point to boot from (hd0,gpt5) and so on, so that it booted my regular Fedora 20 install. That was running 3.14.9 at the time - it's now running 3.15.3.
So it might be worth grabbing a Fedora 21 pre-alpha build to see if you get different results making NVRAM modifications with efibootmgr.
When I experimented last night (since the kernel upgrade) efibootmgr changes seem to work! That proves your kernel theory, or it's something else completely unrelated. Thanks for you reply. All's well that ends well, as they say. And I learnt something in the process.
Gareth
On Jul 10, 2014, at 11:39 PM, Gareth Williams gareth@garethwilliams.me.uk wrote:
On 11/07/14 06:24, Chris Murphy wrote:
On Jul 10, 2014, at 4:56 AM, "Williams, Gareth" gareth@garethwilliams.me.uk wrote:
My question therefore is: Does anaconda do something else after running 'efibootmgr' to make it permanent? Or: Why can anaconda update NVRAM using efibootmgr, while I can't?
'no bootable device' sounds suspiciously like a BIOS message. It's not a failure message I'd expect from an UEFI systems due to how it does fallback - or at least should. It should arrive at worst to EFI/BOOT/BOOTX64.EFI which ought to be shim.efi, which with help from fallback.efi ought to write a new entry in NVRAM for itself.
Why would it come up in 'BIOS' mode? I've not changed any settings on the laptop to enable that - unless my laptop's firmware automatically does it when it can't find any EFI to boot.
It's possible. I've seen some of the "hardwired" enumerated entries on some firmware indicate they'll try to fallback to legacy booting with the CSM-BIOS.
But as you said that it should arrive at BOOTX64.EFI (which is present) then even that theory falls at the first hurdle.
Anyway, the problem you're facing is it's unclear whether it's a firmware bug or a kernel bug. I'd make sure the firmware is updated. See if users are having problems with that version if it's already at the latest version and was recently posted. And then use newer kernels and see if the behavior changes - the Fedora 20 media is using kernel 3.11.10, and 3.16 is mainline.
I didn't boot from the CD image - I merely used the EFI and GRUB from the CD, then edited the GRUB line to point to boot from (hd0,gpt5) and so on, so that it booted my regular Fedora 20 install. That was running 3.14.9 at the time - it's now running 3.15.3.
So it's conceivable you're getting different results from different kernels and even different states of the firmware through subsequent reboots. Some firmware only GC on a reboot.
So it might be worth grabbing a Fedora 21 pre-alpha build to see if you get different results making NVRAM modifications with efibootmgr.
When I experimented last night (since the kernel upgrade) efibootmgr changes seem to work! That proves your kernel theory, or it's something else completely unrelated. Thanks for you reply. All's well that ends well, as they say. And I learnt something in the process.
Basically it takes a lot of iterative testing to establish a pattern of behavior. It may have been kernel change, it may have been reboot causing firmware/NVRAM state change, it may have been a combination.
There's an argument for totally ignoring NVRAM. rEFInd, an EFI boot manager, produces its boot entries dynamically from fstab, a static configuration file, and the contents of /boot. It ignores NVRAM, there's no constantly modified grub.cfg on the EFI system partition when kernels are updated.
Chris Murphy
There's an argument for totally ignoring NVRAM. rEFInd, an EFI boot manager, produces its boot entries dynamically from fstab, a static configuration file, and the contents of /boot. It ignores NVRAM, there's no constantly modified grub.cfg on the EFI system partition when kernels are updated.
That sound worth investigating. How can it ignore NVRAM? Isn't NVRAM used by the firmware to decide which EFI executable to run? Or does rEFIind simply takes the place of the default EFI/BOOT/BOOTX64.EFI and hence there won't be any reason to have entries in NVRAM? Maybe I should RTFM instead of asking!
Thank you again for your help - it's most appreciated.
Gareth
On Jul 11, 2014, at 2:09 PM, Gareth Williams gareth@garethwilliams.me.uk wrote:
There's an argument for totally ignoring NVRAM. rEFInd, an EFI boot manager, produces its boot entries dynamically from fstab, a static configuration file, and the contents of /boot. It ignores NVRAM, there's no constantly modified grub.cfg on the EFI system partition when kernels are updated.
That sound worth investigating. How can it ignore NVRAM? Isn't NVRAM used by the firmware to decide which EFI executable to run? Or does rEFIind simply takes the place of the default EFI/BOOT/BOOTX64.EFI and hence there won't be any reason to have entries in NVRAM? Maybe I should RTFM instead of asking!
There are a number of ways you can configure it. The firmware's built-in boot manager will go with NVRAM entries. GRUB defers entirely to its grub.cfg even if its stale and doesn't reflect the actual state of the system, e.g. you connect an external device. rEFInd is kinda like the Apple firmware built-in boot manager in that it dynamically produces boot menu entries based on the actual state of the system at the time it loads. So its entries aren't ever stale because it has no configuration file, and it ignores NVRAM entries in favor of the ones it self generates.
But yes, of course you're first at the whim of the firmware to first load rEFInd. That can be done either by an NVRAM entry pointing to rEFInd and setting that entry first in bootorder (also in NVRAM0 which tells the firmware to load rEFInd first. The other way is to obliterate NVRAM contents, and make the only BOOTX64.EFI file actually be rEFInd, but that's tricky if you're using UEFI Secure Boot and is probably a separate thread.
Chris Murphy