On Jul 10, 2014, at 11:39 PM, Gareth Williams <gareth(a)garethwilliams.me.uk> wrote:
On 11/07/14 06:24, Chris Murphy wrote:
> On Jul 10, 2014, at 4:56 AM, "Williams, Gareth"
<gareth(a)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