One thing I forgot to mention, 1 & 2 are interrelated from what I can tell including a problem I didn't mention. Supposedly systemd-boot will attempt to find the root, /home, /var, etc automatically and ignore /etc/fstab, but it's not working for me, the boot hangs at gpt-auto-root. From my research it SHOULD work, my ESP and root are on the same drive. It's supposed to find it using the partition type GUID. My work around was to change /boot/loader/entries/*.conf from options $kernelopts (which systemd boot doesn't substitute from grubenv) to options <actual kernel options from grubenv The reason this get's more complicated is according to this Arch wiki[1] if Secure Boot is enabled, the options in the loader file are ignores and only the .cmdline embedded in the kernel is used. AFAICT, Fedora doesn't embed the command line. So even if I can get systemd-boot to work with Secure Boot enabled, the options I'm specifying will be ignored and I'll be back to getting stuck at gpt-auto-root. I could attempt to create a unified kernel image[2], but automating that is probably beyond my skills, or certainly the time I have to teach myself how to do it. Thanks, Richard [1] https://wiki.archlinux.org/index.php/systemd-boot#Adding_loaders [2] https://wiki.archlinux.org/index.php/systemd-boot#Preparing_a_unified_ker...

On Thu, Jun 04, 2020 at 08:04:42AM -0500, Richard Shaw wrote: 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. Not really, they provide similar functionality. Zbyszek

On Thu, Jun 4, 2020 at 9:15 AM Richard Shaw <hobbes1069(a)gmail.com&gt; wrote: Well, that didn't work, perhaps the the ESP partition is somehow protected, so perhaps the solution is to go back to having a second ESP for Fedora. Thanks, Richard