Migrating Fedora from GRUB to systemd-boot

A Guide for Fedora 44

If you've been running Fedora for a while, your system almost certainly has the same partition layout the installer has been creating for years: a small FAT32 EFI partition and a separate /boot partition. This guide will walk you through replacing GRUB with systemd-boot and merging those two partitions into one clean setup.

Each step was tested on a Fedora 44 system. Follow carefully and you'll be done in about 30 minutes.

Before You Start

Who this guide is for

Fedora users on a single-drive, single-boot system (no Windows dual boot)
Systems with the standard Fedora partition layout: EFI partition + separate /boot partition
UEFI systems only (systemd-boot does not support Legacy BIOS)

Who should stop reading now

Dual-boot Windows users
BitLocker users
Systems with encrypted /boot
Legacy BIOS systems

What you'll need

A Fedora Live USB
Physical access to your machine
Your BIOS key (common choices: F2, Del, ESC, F7; check your motherboard manual)
About 30 minutes

Why bother?

GRUB has served Linux well for decades, but it is significantly more complex than most users need. It contains hundreds of thousands of lines of code, including its own filesystem drivers, all running before your OS starts, before any security protections are active. For the vast majority of users, that complexity exists purely to solve problems they don't have.

systemd-boot is simpler by design. It reads only FAT32 (the same filesystem your UEFI firmware reads natively), has a fraction of the codebase, and is straightforward to configure and maintain. Less code also means less attack surface. BootHole in 2020 demonstrated this concretely; a buffer overflow in GRUB's config parser allowed attackers to bypass Secure Boot entirely. That class of vulnerability doesn't exist in systemd-boot because the complexity that enabled it doesn't exist.

systemd-boot is also where Fedora, and the Linux ecosystem broadly, is heading. This guide gets you there now.

Understanding the Partition Problem

A standard Fedora install creates this:

/dev/nvme0n1p1   600MB   vfat               /boot/efi   ← EFI System Partition
/dev/nvme0n1p2   1GB     xfs/ext4/btrfs     /boot       ← Boot partition (kernels live here)
/dev/nvme0n1p3   64GB    swap
/dev/nvme0n1p4   1.8TB   xfs/btrfs          /           ← Root partition

Fedora's installer (Anaconda) has used different filesystems for /boot over the years depending on the version and installation choices:

XFS: common default in recent Fedora versions
ext4: was the default for many years, common on older installations
btrfs: increasingly common, especially when Fedora's btrfs-by-default option is selected

It doesn't matter which one you have. The problem is identical regardless: systemd-boot cannot read XFS, ext4, or btrfs. It only speaks FAT32, the same filesystem your UEFI firmware uses natively. GRUB worked with these filesystems because it carries its own filesystem drivers. systemd-boot deliberately does not, which is a feature: less code means less attack surface.

The solution is the same in every case: merge the two partitions into one larger FAT32 partition. This is the direction the Linux ecosystem is moving toward, with a single, larger EFI partition that holds both the bootloader and the kernels.

End result:

/dev/nvme0n1p1   1.7GB   vfat        /boot/efi   ← Single merged partition
/dev/nvme0n1p3   64GB    swap
/dev/nvme0n1p4   1.8TB   xfs/btrfs   /           ← Root partition (unchanged)

First: Check Your Layout

lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINTS

Confirm:

A vfat partition mounted at /boot/efi
A partition (xfs, ext4, or btrfs) mounted at /boot
Your root partition mounted at /

Phase 1: Prepare Your Running System

Do these steps before you boot the Live USB.

Step 1: Install systemd-boot

Fedora doesn't install the systemd-boot binaries by default. Install the unsigned version (we're disabling Secure Boot anyway). These binaries will be written to your ESP now, then preserved through the backup and restore process in Phase 2. After the partition merge, Fedora will still need to regenerate the boot entries and copy the kernels/initramfs files onto the new merged ESP.

run0 dnf install systemd-boot-unsigned
run0 bootctl install

Step 2: Set the Boot Layout

Tell Fedora's kernel management tools to use the Boot Loader Specification format and to place kernels directly on the EFI System Partition:

run0 mkdir -p /etc/kernel
printf 'BOOT_ROOT=/boot/efi\nlayout=bls\n' | run0 tee /etc/kernel/install.conf

BOOT_ROOT=/boot/efi tells Fedora to place kernels and initramfs files directly on the EFI System Partition instead of the old separate /boot partition.

layout=bls tells Fedora to generate Boot Loader Specification entries compatible with systemd-boot.

Verify the file:

cat /etc/kernel/install.conf

You should see:

BOOT_ROOT=/boot/efi
layout=bls

Step 3: Capture Your Kernel Command Line

Your current boot parameters need to be preserved. This command captures them and strips the GRUB-specific prefix:

cat /proc/cmdline | sed 's/BOOT_IMAGE=[^ ]* //' | run0 tee /etc/kernel/cmdline

Verify the output looks correct. It should be a single line starting with root=UUID=... and containing your boot parameters. If you have selinux=0 or other custom flags, confirm they are present.

Step 4: Set the Boot Order

Tell your firmware to prefer systemd-boot. First check current entries:

run0 efibootmgr

Find the ID number for "Linux Boot Manager" and put it first. For example, if Linux Boot Manager is 0001 and Fedora is 0000:

run0 efibootmgr -o 0001,0000

Phase 2: The Partition Merge (Live USB)

Reboot into your Fedora Live USB. Open a terminal and switch to root:

run0

Step 5: Mount Your Root Partition

mount /dev/nvme0n1p4 /mnt

Replace nvme0n1p4 with your actual root partition if different. If unsure, run lsblk to confirm.

Step 6: Mount Your EFI Partition

mkdir -p /mnt/boot/efi
mount /dev/nvme0n1p1 /mnt/boot/efi

Step 7: Back Up Your EFI Partition

This intentionally copies the visible EFI contents only. Hidden files on an ESP are usually firmware or application leftovers and are not normally something you want to carry forward into a clean migration.

mkdir -p /mnt/temp_efi_backup
cp -a /mnt/boot/efi/* /mnt/temp_efi_backup/

Verify the backup:

ls /mnt/temp_efi_backup

You should see folders like EFI, loader, and a long machine-id string.

Step 8: Unmount the EFI Partition

umount /mnt/boot/efi

Step 9: Check the Partition Layout

parted /dev/nvme0n1 print

Note the End value of your /boot partition (p2). You'll use this in the next step. In a standard Fedora install this is typically around 1704MB, but it will vary on your system.

Step 10: Delete the Boot Partition

parted /dev/nvme0n1 rm 2

You'll see a message saying you may need to update /etc/fstab. We'll handle that shortly.

Step 11: Resize the EFI Partition

Expand p1 to fill the space left by the deleted partition. Use the End value you noted in Step 9:

parted /dev/nvme0n1 resizepart 1 1704MB

Step 12: Format the Enlarged Partition

Since we changed the size, we need to reformat. Your backup is safe in /mnt/temp_efi_backup:

mkfs.fat -F32 /dev/nvme0n1p1

Step 13: Mount the New Partition

mount /dev/nvme0n1p1 /mnt/boot/efi

Step 14: Restore Your Backup

cp -a /mnt/temp_efi_backup/* /mnt/boot/efi/

Verify the restore:

ls /mnt/boot/efi

You should see your EFI files back in place.

Step 15: Get the New UUID

Reformatting created a new UUID. Write this down, you will need it for fstab:

lsblk -o NAME,UUID /dev/nvme0n1p1

Step 16: Check and Update fstab

cat /mnt/etc/fstab

You need to make two changes:

Update the UUID for the /boot/efi line to the new UUID from Step 15
Delete the line for /boot entirely, as that partition no longer exists

Edit the file:

nano /mnt/etc/fstab

Note: In some cases Fedora's fstab may already show the correct UUID if the partition inherited it. Always verify before assuming.

Step 17: Verify the Final Partition Table

parted /dev/nvme0n1 print

You should see only three partitions: p1 (fat32, ~1.7GB), p3 (swap), p4 (your root filesystem). No p2.

Step 18: Regenerate Kernel Entries

At this point the old /boot partition is gone. Fedora now needs to regenerate the boot entries and copy the kernels/initramfs files onto the new merged EFI partition. Restoring the ESP files alone is not enough.

Bind the runtime filesystems and enter the installed system:

mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /run /mnt/run
chroot /mnt

If you see this message, it is harmless:

tty: ttyname error: No such device

Verify the kernel-install configuration:

cat /etc/kernel/install.conf

You should see:

BOOT_ROOT=/boot/efi
layout=bls

If not, recreate it:

mkdir -p /etc/kernel
printf 'BOOT_ROOT=/boot/efi\nlayout=bls\n' > /etc/kernel/install.conf

Reinstall systemd-boot onto the recreated ESP:

bootctl install

Now regenerate all installed kernel entries and copy the kernels/initramfs files onto the ESP:

kernel-install add-all

You may see harmless warnings such as:

grub2-editenv: error: failed to get canonical path of `/boot/grub2'

These warnings are expected and can safely be ignored.

Verify the entries exist:

bootctl list

You should see your Fedora kernels listed.

Verify the actual kernel and initramfs payloads exist on the ESP. In this layout they may be named linux and initrd, not vmlinuz and initramfs:

find /boot/efi -path '*/linux' -o -path '*/initrd'

Set the boot menu timeout:

printf 'timeout 3\nconsole-mode keep\ndefault @saved\n' > /boot/efi/loader/loader.conf

Exit the chroot:

exit

Phase 3: First Boot into systemd-boot

Reboot the machine and immediately enter your BIOS/UEFI settings.

umount -R /mnt
reboot

In the BIOS:

Disable Secure Boot. This is required because we installed the unsigned systemd-boot binary. On many motherboards this is confusingly labeled as OS Type: Other OS. This still uses UEFI boot; it usually just disables Secure Boot enforcement.
Set boot order. Move "Linux Boot Manager" to position #1.
Save and exit.

What to expect:

Instead of the Fedora GRUB menu, you'll see a simple black-and-white text menu. Use arrow keys to select your kernel and press Enter.

If you see a Secure Boot violation, Secure Boot is still enabled. Go back into BIOS/UEFI settings and look for OS Type, Other OS, Secure Boot Control, or Key Management.

If you see a blank screen or "File not found" error, reboot and press your boot menu key (usually F12) to manually select an entry. Choose "Linux Boot Manager" if it appears.

Phase 4: Post-Boot Cleanup

These final steps clean up after the migration.

Step 19: Verify systemd-boot is Running

run0 bootctl status

You should see Product: systemd-boot under Current Boot Loader, with all features showing ✓.

Step 20: Verify Kernel Entries

run0 bootctl list

Your current kernel should appear as (default) (selected). If you have multiple kernels installed they should all be listed.

Step 21: Verify the Final Layout

lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINTS
findmnt /boot/efi
cat /etc/fstab
cat /etc/kernel/install.conf

You should see the EFI partition mounted at /boot/efi, no separate /boot mount, and this in /etc/kernel/install.conf:

BOOT_ROOT=/boot/efi
layout=bls

Step 22: Clean Up Stale EFI Entries

Check what's in your EFI variables:

run0 efibootmgr

Delete any remaining Fedora/GRUB entries, as they are no longer needed. For each stale entry ID (e.g. 0000, 0006):

run0 efibootmgr -b 0000 -B

Leave "Linux Boot Manager" in the list.

Step 23: Enable Automatic Bootloader Updates

As of systemd version 250, a service exists that keeps the systemd-boot binary itself up to date automatically. Enable it:

run0 systemctl enable --now systemd-boot-update.service

Without this, the systemd-boot binary on your ESP can fall out of sync with the version installed by dnf.

Step 24: Final Verification

Run these verification checks:

run0 bootctl status
run0 bootctl list
systemctl is-enabled systemd-boot-update.service
run0 efibootmgr
run0 cat /boot/efi/loader/loader.conf

Everything should be clean: one preferred Linux Boot Manager entry in EFI variables, all kernels listed, service enabled, timeout configured.

Will Future Kernel Updates Work Automatically?

Yes, provided /etc/kernel/install.conf contains:

BOOT_ROOT=/boot/efi
layout=bls

Fedora's kernel-install scripts will automatically place new kernels on your ESP when you run dnf update. However, the scripts still contain some GRUB references that generate harmless warnings like:

grub2-editenv: error: failed to get canonical path of `/boot/grub2'

This is benign. The kernel installs correctly regardless. After any kernel update, verify with:

run0 bootctl list

If the new kernel appears, everything is working. If it doesn't appear, run kernel-install add-all and check the output.

What About Secure Boot?

Secure Boot is disabled in this guide because we installed the unsigned systemd-boot binary. For most home users this is a reasonable tradeoff. The security benefit of Secure Boot is primarily protection against physical "evil maid" attacks on unattended hardware.

On many motherboards, disabling Secure Boot is confusingly labeled as changing OS Type from Windows UEFI Mode to Other OS. This does not switch the system to Legacy BIOS mode. It remains UEFI boot. It usually just disables Secure Boot enforcement.

The path to re-enabling Secure Boot with systemd-boot involves Unified Kernel Images (UKIs), which are single signed .efi files that combine the kernel, initrd, and command line into one tamper-evident package. Fedora is actively working toward making this the default. Your current setup is already compatible since systemd-boot supports UKIs natively and your ESP has sufficient space.

Troubleshooting

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.

Secure Boot violation: Secure Boot is still enabled. Enter BIOS and disable it. On many motherboards this is under OS Type, where Other OS disables Secure Boot enforcement while still using UEFI boot.

"No entries found" in systemd-boot menu: Your .conf files are missing. Boot into the Live USB, mount your root filesystem and ESP, chroot into the installed system, verify /etc/kernel/install.conf, and run kernel-install add-all.

Boot entry exists but kernel file is missing: The BLS entry exists, but the kernel payload was not copied to the ESP. Boot from the Live USB, chroot into the installed system, and run kernel-install add-all.

System drops to emergency shell: Your fstab UUID is wrong. Boot the Live USB, mount your root partition, and correct the UUID in /mnt/etc/fstab.

"Error preparing initrd": The tuned service injected a bad parameter. Press e at the boot menu to edit the entry and remove any initrd /tuned... reference from the options line. Then reinstall the kernel entry.

GRUB keeps loading despite boot order change: Some firmware ignores efibootmgr changes and hardcodes a preference for \EFI\fedora\shimx64.efi. Enter your BIOS boot menu manually (usually F7 or F12) and select "Linux Boot Manager" directly. Once confirmed working, clean up stale Fedora/GRUB EFI entries with efibootmgr.

btrfs /boot note: If your /boot was formatted as btrfs the deletion and reformat process is identical. btrfs requires no special handling. It is simply another filesystem that systemd-boot cannot read, and the partition merge resolves that the same way as XFS or ext4.

Summary

You now have:

systemd-boot replacing GRUB
A single clean ~1.7GB FAT32 boot partition
Kernels and initramfs files stored directly on the ESP
Automatic bootloader updates configured
A 3 second boot menu timeout
A setup compatible with the upcoming UKI and Secure Boot transition

Fedora's default partition layout was designed around GRUB, which is why this manual migration is necessary in the first place. On a fresh install configured correctly from the start, none of this would be needed.

Sunday, May 3, 2026