New UEFI guide on the wiki

[Chris Murphy]

On Feb 4, 2014, at 11:30 AM, Andrew Lutomirski <luto at mit.edu> wrote:

> On Tue, Feb 4, 2014 at 10:19 AM, Chris Murphy <lists at colorremedies.com> wrote:
>> 
>> On Feb 4, 2014, at 10:42 AM, Andrew Lutomirski <luto at mit.edu> wrote:
>> 
>>> I think that half the difficulty here is that UEFI is annoying and the
>>> other half is that both GRUB2 and efibootmgr are miserable.
>> 
>> For single OS installs, you shouldn't have to interact with any of those things. shim.efi, or shim via fallback.efi (?) will even do a fallback boot of Fedora if NVRAM has somehow been vanquished.
> 
> How does firmware find shim.efi?  Is it installed as bootx64.efi?

BOOT/BOOT<arch>.EFI

> IIRC that approach used to be frowned upon.

UEFI spec "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."

Seems correct to me.


> 
>> 
>> Multiboot, you get to deal with either your firmware's boot manager, or learn a 3rd party replacement (including GRUB, gummiboot, or rEFInd).
>> 
>>> TBH, I've
>>> never had much trouble convincing UEFI to load an image -- most of the
>>> trouble is convincing GRUB2, once successfully running, to do anything
>>> useful.
>> 
>> Care to be more specific? The UX should be basically identical to grub on BIOS.
> 
> Exactly.  The GRUB2 UX is special.  :)   Somehow anaconda does the
> right thing.  Since I haven't the faintest clue what the right thing
> is, I can't replicate it.
> 
> To be fair, UEFI is slightly worse.  Disk numbers seem to change on
> occasion if they're in a bad mood, at least on my box.

You mean a disk can flip between /dev/sda and /dev/sdb between boots? That's been happening on BIOS also for years, it's not guaranteed assignment which is why UUID is better.



> 
>> 
>> 
>>> (The Debian/Ubuntu approach regenerating grub config all the
>>> time is nicer here, but it still sucks.  I'm anxiously awaiting
>>> BootLoaderSpec and something that isn't GRUB or GRUB2 to make a lot of
>>> the unpleasantness go away.)
>> 
>> It's a continuum. The less interaction the less customizable but the more pleasant. Automatic is great, when it just works. That usually means constraining the options. For gummiboot it means it's presently not supporting boot from anything but FAT32 which I find untenable. Way too much writing is happening on a FAT32 volume in that paradigm for my comfort level.  So yes, when it decides what it wants to be when it grows up, then it could be a viable alternative. And like I mentioned in another thread [1], bootloaderspec has regressive boot capabilities also, it effectively says no to snapshotting $BOOT. Since the kernel goes on $BOOT, it means $BOOT contents can be so new they can't boot older snapshots which contain older /lib/modules. So if rootfs is being snapshot, then /boot needs to be snapshot with it.
>> 
> 
> Fair enough.  Some day this will all work well.
> 
> In the mean time, I actually preferred GRUB 1, the lack of maintenance
> notwithstanding.

That's a long ago sailed, and long lost or sunken ship. It's a choice between two week old left overs in the fridge, will I get food poisoned? Versus a new bottle of Burns Going In and Coming Out Hot Sauce™?



Chris Murphy