NVRAM changes not persistent with efibootmgr

[Chris Murphy]

On Jul 10, 2014, at 4:56 AM, "Williams, Gareth" <gareth at 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