Reinstalling the bootloader

Chris Murphy lists at colorremedies.com
Mon Apr 14 22:14:19 UTC 2014


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?

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


Chris Murphy



More information about the devel mailing list