On Thu, Jun 04, 2020 at 08:04:42AM -0500, Richard Shaw wrote: > Is there someone that can help me convert my Fedora install from GRUB to > systemd-boot and actually get it where kernel updates won't break it? > > The reason is that my MS Surface GO does not work with GRUB for some > reason. Probably a non-standard UEFI implementation but I both found this > to be the case personally and google seem to confirm this. One proposed > solution is to use systemd-boot, which I have semi-successfully done. > > Getting to where I can boot the currently installed kernel is > chronicled here: > > https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx/message/DDSAMQUGXWYTHAC73W4DTLDOLRM56FNX/ > > If I wasn't using both the internal NVME for "/" and a SD card for > everything else I probably would have just converted the /boot partition to > FAT32 and made it the new ESP partition... > > So the last two steps is: > > 1. See if I can get it working with secure boot enabled. > > 2. How to make it work with kernel updates which are completely grub > centric. That is a misconception. The kernel package is completely agnostic about the boot loader. It just calls 'kernel-install add'. And kernel-install has a plugin architecture and supports the sd-boot layout and the grub layouts. kernel-install has some logic to figure out the layout. Sadly, when grub adopted the boot-load-specification format, it not only reimplemented the file format in an incompatible fashion (adding its own macro language on top, which of course defeats the ideals of portability in the original design), but also picked different locations for the files (although here there are valid reasons to prefer a different path). The short story is that the grub and sd-boot layouts are incompatible. Because of the limited space on boot and efi partitions, we can't just install both, and we pick one or the other. kernel-install looks for the directories that grub would use, and if those are present, the kernel entry is installed there, and otherwise the sd-boot layout is used. This was done for backwards compatibility and to minimize disruption to existing users, with the assumption that grub is much more widely used. In retrospect this automatism was a mistake, because this autodetection logic is frequently broken when grub is installed. And sadly grubby and grub are pulled in by various unrelated packages. (Incidentally, today morning I was fixing of my VMs where the grub stack got pulled in by some dnf update and the boot layout got broken again...) Thus, my recommendation is to do 'dnf remove grubby grub2-common' and nuke the grub entries (usually /boot/loader and directories listed there). Obviously, make sure that another mechanism to boot is in place! When you (inevitably it seems) see that new kernels are not getting boot entries in sd-boot, repeat. Longer-term, we should add an explicit configuration option to kernel-install about the layout, so we autodetection logic is only used as a fallback and there's less chance of breakage if grub gets pulled in. > Side question: If you're booting EFI with GPT partitions, is there any > advantage to using grub over systemd-boot? The latter seems much simpler as > the former seems way more complicated than necessary including the very > fragile environment block[1] Not really, they provide similar functionality. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
