I’ve been running Fedora 44 and decided to migrate from GRUB to systemd-boot. The short version: it works well, kernel updates are automatic, and the setup is cleaner. The longer version, including every command and what to watch out for, is on my blog.
The main thing that trips people up is that Fedora’s default partition layout puts kernels on an XFS /boot partition that systemd-boot can’t read. The fix is merging the EFI and boot partitions into a single FAT32 partition, which sounds more complicated than it is.
Good point, and the guide covers that. Whether your /boot is XFS, ext4, or btrfs doesn’t change anything — systemd-boot can’t read any of them. The partition merge is the same regardless. I used XFS as the example in the post because that’s what my system had.
Very nice and clear write-up, thanks. I’ll definitely try this once it’s possible with secure-boot - or earlier if I can convince myself that secure-boot with un-encrypted /boot (encrypted root fs) provides limited security benefits anyways
If I replace GRUB with systemd-boot like this, will I still be able to reinstall Fedora while keeping the /home subvolume (using Fedora’s default reinstall options)?
As far as I can see the /home data is safe as it lives on the btrfs partition which the bootloader migration doesn’t touch. The problem may be Anaconda’s ‘reinstall keeping /home’ option as it expects Fedora’s standard partition layout (separate /boot partition).
After the merge that partition is gone, so Anaconda won’t recognise it as a standard install and the easy reinstall path won’t work as expected.
You’d need to use manual partitioning and correctly identify the /home subvolume yourself.
I’ve added this to the troubleshooting section: Reinstalling Fedora after this migration: Anaconda’s standard “reinstall keeping /home” option may not work as expected since the separate /boot partition no longer exists. If you need to reinstall, use manual partitioning and identify your /home subvolume yourself.
Thanks for the feedback, good points on -a and --no-target-directory. I’ve updated the guide to use -a for both the backup and restore commands to preserve timestamps and permissions.
On the dotfiles point I went a different direction. For an ESP specifically, hidden files are typically put there by firmware tools or previous EFI applications and aren’t something you’d want to carry forward into a clean migration. Intentionally skipping them with the * glob seemed like the right call. If I’m missing a scenario where preserving ESP dotfiles matters I’m happy to reconsider.
does it matter if you use Kinoite?
I have an old z77 motherboard and I’m keen to see if it supports this. My main concern is if the load becomes too big the BIOS may not handle it.
Thanks, was hoping to find a guide like this.
What ramifications does that have in terms of a snapshot roll back with btrfs? I have btrfs assistant running but I don’t think a rollback will boot the kernel.
