This is a tracking bug for Change: Clean Systemd-boot installs For more details, see: https://fedoraproject.org/wiki/Changes/cleanup_systemd_install Fedora default installs with a shim + grub bootloader on EFI platforms, yet has been shipping systemd-boot in various forms for a number of releases. There are a few howto's which describe how to replace grub with systemd-boot with varying levels of functionality. This should be easier with a formalized default method that can be built upon. This proposal aims to complete the work started with anaconda (inst.sdboot), kickstart (bootloader --sdboot) such that the "everything" media can install a grub free machine. If you encounter a bug related to this Change, please do not comment here. Instead create a new bug and set it to block this bug.
Jeremy, what is the status here? I see the comps PR has been merged, but the sdubby package review bug is still open.
*** Bug 2226796 has been marked as a duplicate of this bug. ***
*** Bug 2231901 has been marked as a duplicate of this bug. ***
*** Bug 2231897 has been marked as a duplicate of this bug. ***
The review is now approved so it was just waiting on me to finish up the fedpkg requests and push the branch. Which i'm doing now, so it should happen.
The change proposal also states that a systemd-boot-signed package should be provided which I currently cannot find in the repositories. Is there an estimate on when we can expect this, e.g. in time for the beta release?
I think that was in the, once we get an install path that works, we can work on cleaning up the following items. AFAIK, the signed-systemd-boot package is stuck, and its not clear once that happens if the support path is going to be enrolling the fedora keys, or using shim (which i'm not a big fan of) which currently doesn't support chaining to systemd-boot if its not called grub${PLATFORM}.efi. So, TODO which will probably be that way for a while yet.
So sdubby is now in, and I think in theory you should be able to do a (non-signed, so not Secure Bootable?) install from the Everything netinst. However, there's still no systemd-boot-signed - only systemd-boot-unsigned from the systemd .src.rpm - and https://bugzilla.redhat.com/show_bug.cgi?id=2234638 isn't fixed. So in theory we can call the current state 'complete' based on the scope in the Change, which really only covered the comps change and the sdubby package review, and more generally kinda the idea that you can, somehow, complete a systemd-boot install. However...I just tested it, and it doesn't entirely work. I did an install from the 2023-09-10 F39 Everything netinst nightly (that's the most recent I had lying around) with `inst.sdboot` on the cmdline, in a libvirt UEFI VM. Install completed successfully, and the installed system shows a clearly-not-grub boot menu, but when I choose the default option, I immediately wind up at the emergency console. In the journal I see "Failed to switch root: Specified switch root path '/sysroot' does not seem to be an OS tree. os-release file is missing". So...I guess we can call this MODIFIED, for now? I'll file a specific bug for the problem I see.
What your seeing is the btrfs bug https://github.com/rhinstaller/anaconda/pull/5194 and bz #2237327 and is caused by the fact that I did 99% of my testing with the server DVD and it defaults to XFS. You can work around this by selecting anything but btrfs during the install, or just dumping the btrfs rootflags=subvolume= parameter into the first boot of the machine and then updating the loader entries/etc. And presumably it will be fixed once that patch lands.
F39 was released on November 7th, so I am closing this tracker. If this Change was not completed, please notify me ASAP.
This Change was not completed.
There should at least be a follow up ticket about providing a systemd-boot-signed package