On Tue, Feb 4, 2014 at 10:19 AM, Chris Murphy <li...@colorremedies.com> wrote: > > On Feb 4, 2014, at 10:42 AM, Andrew Lutomirski <l...@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? 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@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
