Re: New UEFI guide on the wiki

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Feb 4, 2014 at 10:19 AM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote:
>
> On Feb 4, 2014, at 10:42 AM, Andrew Lutomirski <luto@xxxxxxx> 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?
IIRC that approach used to be frowned upon.

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

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

--Andy

> Chris Murphy
>
>
> [1] https://lists.fedoraproject.org/pipermail/devel/2014-January/193857.html
> --
> devel mailing list
> devel@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux