On Mon, Apr 14, 2014 at 3:14 PM, Chris Murphy <lists(a)colorremedies.com> wrote:
On Apr 14, 2014, at 4:04 PM, Andrew Lutomirski <luto(a)mit.edu> wrote:
>>
>> Create a boot menu entry can be skipped if it's not a dual boot system.
/boot/efi/EFI/BOOT contains shim.efi as bootx64.efi which is run by default on a system
without an NVRAM entry already pointing to shim or grub, and a fallback entry is created
automagically. With Windows, yeah you probably have to do something manually because it
probably always boots Windows otherwise.
>>
>
> Not on my crappy motherboard :( It apparently can't boot from
> EFI/BOOT on a hard disk. Sigh.
Huh, you're sure? You have to either remove all removable NVRAM boot entries, or you
have to remove the file/device the entry points to trigger the use of
//BOOT/BOOT<arch>.efi. If this isn't working, what does happen instead? It just
hangs?
Hmm. I assumed that just asking the system to boot off that disk
would do the trick. Apparently not.
Removing other entries is hard, given the aforementioned OOPS. :(
>
> I tried to clarify it a bit, though.
>
>>
>>
>>>>> It's currently mostly working, modulo the efibootbgr issue. But
I
>>>>> don't actually know what to type into efibootmgr to fix it, the
OOPS
>>>>> notwithstanding. I can probably figure it out once the OOPS is
fixed.
>>>>
>>>> Strictly speaking you don't need to point UEFI non-Secure Boot
computer to shim.efi, you can just leave it alone and put a grub.cfg in the proper place.
At the grub prompt if you type set you should see either config_directory= and prefix= to
show where it's looking for the grub.cfg.
>>>
>>>
https://bugzilla.kernel.org/show_bug.cgi?id=73761
>>>
https://bugzilla.redhat.com/show_bug.cgi?id=1085957
>>
>> I'm not familiar with this usage: efibootmgr -B -b 0
>>
>> If 0 is the same as 0000 then that seems to ask for the removal of a fixed entry:
the DVD in CSM-BIOS mode (?) which I wouldn't expect to work, ever. But then it also
shouldn't crash the kernel.
>>
>> A valid command would be efibootmgr -b 0003 -B
>>
>
> -B -b 0 seems to be the same as -B -b 0000, and my 0000 isn't the same
> as your 0000 :)
I'm basing it off the 0000 entry in your bug 73761. It points to a DVD drive.
>> Something that properly deals with restoring shim, grub, grub.cfg, and NVRAM
would be nice. But the NVRAM part might be a rat hole, seeing as some of the manufacturer
NVRAM behaviors are pretty icky. And on top of that don't seem to have a good way for
users to reset/wipe it. It's something I think the UEFI Forum ought to put in the
standard and require it.
>
> Anaconda does this somehow, I think. Even just exposing that would be nice.
No all it does is look for a Fedora boot entry in NVRAM and then uses efibootmgr -b xxxx
-B against it. It doesn't have a mechanism, nor should it, to obliterate everything in
NVRAM which can contain a lot more than just boot entries.
ls -l /sys/firmware/efi/efivars
Two dozen variables. On my Mac there's 50+ items including speaker and brightness
level.
I meant that I assumed that anaconda set up a new boot manager entry.
If it doesn't, and just relies on fallback, then I guess there's
nothing to ask for.
Of course, that'll change once anaconda becomes sensible enough to set
up each ESP once and keep it unmounted from then on, since that'll
involve changing the RPMs so they don't install to /boot/efi.
Unless, of course, /boot/efi just becomes the efi boot template, in
which case some script will need to propagate the contents.
--Andy