Reinstalling the bootloader

[Chris Murphy]

On Apr 14, 2014, at 4:27 PM, Andrew Lutomirski <luto at mit.edu> wrote:

> On Mon, Apr 14, 2014 at 3:14 PM, Chris Murphy <lists at colorremedies.com> wrote:
>> 
>> On Apr 14, 2014, at 4:04 PM, Andrew Lutomirski <luto at 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.

No. Boot entries in NVRAM come first. See UEFI spec 2.4.0, section 3.4.1.2, and 12.3.1.3 "This directory contains EFI images that aide in recovery if the boot selections for the software installed on the EFI system partition are ever lost."

> Removing other entries is hard, given the aforementioned OOPS. :(

Sure. OOPS isn't good. But chances are it's naughty firmware.


> 
>> 
>>> 
>>> 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.

It does create a new boot manager entry using efibootmgr.


> 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.

Has there been buy off on this?


Chris Murphy