Hello there!
How do I proceed to switch my Fedora Workstation to systemd-boot after dnf system upgrade from F38 to F39?
I’m on a laptop with hybrid Intel+NVIDIA (via UEFI can switch between hybrid or discreet mode).
2 Likes
Hello @msmafra ,
I did this a few releases back, and I didn’t remove Grub2, I just installed systemd-boot package then ran the bootctl command with install, so sudo bootctl install. But you should look through the docs for it, fedora docs are pretty good for it I think those are under the HowTo’s?!?
[Edit] Also, of note in my system I am using UEFI but not secure boot or TPM2 and my understanding is that secure boot adds wrinkles for doing this (I think systemd-boots keys need enrolling with the BIOS).
1 Like
Thank you for this, quite helpful.
I did it some weeks back, but it wont update the list of kernels. It just added systemd-boot.EFI file, basically. The only entry was my UEFI Settings. Secureboot is disbled.
Interesting, I don’t remember (and neither does my command history) an extra command. What does sudo bootctl list or sudo bootctl status report? I guess you could just do sudo bootctl update to update the entries.
[Edit]
Mine reports for status …
System:
Firmware: UEFI 2.70 (American Megatrends 5.17)
Firmware Arch: x64
Secure Boot: disabled
TPM2 Support: no
Boot into FW: supported
Current Boot Loader:
Product: systemd-boot 254.7-1.fc39
Features: ✓ Boot counting
✓ Menu timeout control
✓ One-shot menu timeout control
✓ Default entry control
✓ One-shot entry control
✓ Support for XBOOTLDR partition
✓ Support for passing random seed to OS
✓ Load drop-in drivers
✓ Support Type #1 sort-key field
✓ Support @saved pseudo-entry
✓ Support Type #1 devicetree field
✓ Enroll SecureBoot keys
✓ Retain SHIM protocols
✓ Boot loader sets ESP information
ESP: /dev/disk/by-partuuid/35fc0fb2-ccd2-4339-a68f-b2d857f11e02
File: └─/EFI/SYSTEMD/SYSTEMD-BOOTX64.EFI
Random Seed:
System Token: set
Exists: yes
Available Boot Loaders on ESP:
ESP: /efi (/dev/disk/by-partuuid/35fc0fb2-ccd2-4339-a68f-b2d857f11e02)
File: ├─/EFI/systemd/systemd-bootx64.efi (systemd-boot 254.7-1.fc39)
└─/EFI/BOOT/BOOTX64.EFI (systemd-boot 254.7-1.fc39)
Boot Loaders Listed in EFI Variables:
Title: Linux Boot Manager
ID: 0x0000
Status: active, boot-order
Partition: /dev/disk/by-partuuid/35fc0fb2-ccd2-4339-a68f-b2d857f11e02
File: └─/EFI/SYSTEMD/SYSTEMD-BOOTX64.EFI
Title: UEFI OS
ID: 0x000A
Status: active, boot-order
Partition: /dev/disk/by-partuuid/35fc0fb2-ccd2-4339-a68f-b2d857f11e02
File: └─/EFI/BOOT/BOOTX64.EFI
Boot Loader Entries:
$BOOT: /efi (/dev/disk/by-partuuid/35fc0fb2-ccd2-4339-a68f-b2d857f11e02)
token: c1d0698d3ac34d00ae714cc01ea5140f
Default Boot Loader Entry:
type: Boot Loader Specification Type #1 (.conf)
title: Fedora Linux 39 (Workstation Edition) (6.6.8-200.fc39.x86_64)
id: c1d0698d3ac34d00ae714cc01ea5140f-6.6.8-200.fc39.x86_64.conf
source: /efi//loader/entries/c1d0698d3ac34d00ae714cc01ea5140f-6.6.8-200.fc39.x86_64.conf
sort-key: fedora
version: 6.6.8-200.fc39.x86_64
machine-id: c1d0698d3ac34d00ae714cc01ea5140f
linux: /efi//c1d0698d3ac34d00ae714cc01ea5140f/6.6.8-200.fc39.x86_64/linux
initrd: /efi//c1d0698d3ac34d00ae714cc01ea5140f/6.6.8-200.fc39.x86_64/initrd
options: root=UUID=17d62767-03c0-4f34-8038-65136eaa7a5c ro rootflags=subvol=fedora-root-sub resume=UUID=4c9bbdab-9aaa-461f-a0c6-3d583e2caf5d rhgb quiet nosmt systemd.machine_id=c1d0698d3ac34d00ae714cc01ea5140f
You also have to make sure the BLS file layout is followed as systemd-boot is particular about it.
Boot from GRUB (saved by rEFInd).
doas bootctl status
System:
Firmware: n/a (n/a)
Firmware Arch: x64
Secure Boot: disabled (setup)
TPM2 Support: yes
Boot into FW: supportedCurrent Boot Loader:
Product: n/a
Features: ✗ Boot counting
✗ Menu timeout control
✗ One-shot menu timeout control
✗ Default entry control
✗ One-shot entry control
✗ Support for XBOOTLDR partition
✗ Support for passing random seed to OS
✗ Load drop-in drivers
✗ Support Type #1 sort-key field
✗ Support @saved pseudo-entry
✗ Support Type #1 devicetree field
✗ Enroll SecureBoot keys
✗ Retain SHIM protocols
✗ Boot loader sets ESP information
ESP: n/a
Random Seed:
System Token: set
Exists: yesAvailable Boot Loaders on ESP:
ESP: /efi (/dev/disk/by-partuuid/6040b629-c790-44d3-82cc-8983e0bcaf50)
File: ├─/EFI/systemd/systemd-bootx64.efi (systemd-boot 254.7-1.fc39)
├─/EFI/BOOT/BOOTX64.EFI (systemd-boot 254.7-1.fc39)
└─/EFI/BOOT/BOOTIA32.EFIBoot Loaders Listed in EFI Variables:
Title: Linux Boot Manager
ID: 0x0005
Status: active, boot-order
Partition: /dev/disk/by-partuuid/6040b629-c790-44d3-82cc-8983e0bcaf50
File: └─/EFI/systemd/systemd-bootx64.efiTitle: rEFInd Boot Manager ID: 0x0004 Status: active, boot-order Partition: /dev/disk/by-partuuid/6040b629-c790-44d3-82cc-8983e0bcaf50 File: └─/EFI/refind/refind_x64.efiBoot Loader Entries:
$BOOT: /efi (/dev/disk/by-partuuid/6040b629-c790-44d3-82cc-8983e0bcaf50)
token: fedoraDefault Boot Loader Entry:
type: Boot Loader Specification Type #2 (.efi)
title: Fedora Linux 39 (Workstation Edition) (39 (Workstation Edition)) (linux-6.6.8-200.fc39.x86_64-97b69db64f31472dbecd7505c0f348ca.efi)
id: linux-6.6.8-200.fc39.x86_64-97b69db64f31472dbecd7505c0f348ca.efi
source: /efi//EFI/Linux/linux-6.6.8-200.fc39.x86_64-97b69db64f31472dbecd7505c0f348ca.efi
sort-key: fedora
version: 39 (Workstation Edition)
linux: /efi//EFI/Linux/linux-6.6.8-200.fc39.x86_64-97b69db64f31472dbecd7505c0f348ca.efi
The doas bootctl list will list the efi files, but just because I ran dracut with --uefi manually.
Hello @msmafra ,
There is a pretty good guide to the steps at https://kowalski7cc.xyz/blog/systemd-boot-fedora-32/. I did use kernel-install I remember as well as the steps outlined since I removed Grub2 in my case.
I did remove grub because I didn’t want to risk it taking over again.
It didn’t reinstall itself until the most recent upgrade to F39. However, I removed it again without issue.
Gave it another try today, it seems mkosi, which I installed months back, was causing it to not generate the conf files. At least with my current one 6.6.8-cb1.0 it is working. Thanks all.
I’ve been doing this since Fedora 31?! , it works, but I have a list of commands i run to get it done. It’ basically a the info in that website, with some quirks. In Fedora 35 the commands did not create the directory structure completely so I included a command to do it.
What is really nice about it, is that if you do not echo "exclude=grub2-*,os-prober,grubby" >> /etc/dnf/dnf.conf you can even continue to use dnf-plugin-system-upgrade without issue. An update will continue to install grub, but it does nothing and can be removed after the install.
Here is an example of what I have been doing over the years :
#Encrypted Container xfs Fedora_38_systemd-boot_edits_09-22-2023
#sudo chroot /mnt/sysroot /bin/bash --login
PS1="> "
rm -rfv /etc/dnf/protected.d/grub*
rpm -v --nodeps --erase $(rpm -qa | grep "^grub2-\|^os-prober-\|^grubby-")
echo "exclude=grub2-*,os-prober,grubby" >> /etc/dnf/dnf.conf
tree /boot
rm -rfv /boot/*
#
#
# unmount /boot/efi
# unmount /boot
# create new partition mkfs.exfat /dev/nvme0n1p1
# mount /dev/nvme0n1p1 /boot
blkid /dev/nvme0n1p1
# update /etc/fstab with UUID= of the new /boot partition
# remove old /boot/efi entries
#
#
mount /dev/nvme0n1p1 /boot
echo "dracut_rescue_image=no" > /etc/dracut.conf.d/rescue.conf
echo "quiet rhgb" > /etc/kernel/cmdline
#root=/dev/mapper/fedora_localhost--live00-00 ro rd.md.uuid=f96f11c7:c9a6569a:8450de56:6d7d6a49 rd.lvm.lv=fedora_localhost-live00/00 rd.luks.uuid=luks-651c0655-48e2-4fa4-a4b5-b466872e009e rhgb quiet
cat /proc/cmdline | cut -d ' ' -f 2- | sudo tee /etc/kernel/cmdline
SYSTEMD_RELAX_XBOOTLDR_CHECKS=1 bootctl install --boot-path=/boot --esp-path=/boot
mkdir -pv /boot/$(</etc/machine-id)/$(uname -r)
tree /boot
kernel-install add $(uname -r) /usr/lib/modules/$(uname -r)/vmlinuz
tree /boot
cat /boot/loader/entries/$(</etc/machine-id)-$(uname -r).conf
#/boot
#├── b555e3f4c0bb4a4bb280cab193983840
#│ └── 5.14.10-300.fc35.x86_64
#│ ├── initrd
#│ └── linux
#├── EFI
#│ ├── BOOT
#│ │ └── BOOTX64.EFI
#│ ├── Linux
#│ └── systemd
#│ └── systemd-bootx64.efi
#└── loader
# ├── entries
# │ └── b555e3f4c0bb4a4bb280cab193983840-5.14.10-300.fc35.x86_64.conf
# ├── loader.conf
# └── random-seed
#8 directories, 7 files
#title Fedora Linux 35 (Workstation Edition)
#version 5.14.10-300.fc35.x86_64
#machine-id b555e3f4c0bb4a4bb280cab193983840
#options root=/dev/mapper/fedora_localhost--live00-00 ro rd.md.uuid=f96f11c7:c9a6569a:8450de56:6d7d6a49 rd.lvm.lv=fedora_localhost-live00/00 rd.luks.uuid=luks-651c0655-48e2-4fa4-a4b5-b466872e009e rhgb quiet
#linux /b555e3f4c0bb4a4bb280cab193983840/5.14.10-300.fc35.x86_64/linux
#initrd /b555e3f4c0bb4a4bb280cab193983840/5.14.10-300.fc35.x86_64/initrd
1 Like
Do you still need to do this? Won’t current versions of systemd create this path if it doesn’t exist when you kernel-install?
I still do it as a rule of thumb, only because F35 and F36 did not do this automatically and caused the kernel to not be installed and not give a message as to why ( i didn’t get/check logs though. . . ).
IMO it does not hurt to have it. I have tested this with every release (except F39).
For Nvidia gpu’s, you can run the rpm -v but skip exclude= in dnf.conf
The Nvidia driver needs grubby to write the blacklist command:
rpm -v --nodeps --erase $(rpm -qa | grep "^grub2-\|^os-prober-\|^grubby-")
skip => echo "exclude=grub2-*,os-prober,grubby" >> /etc/dnf/dnf.conf
I have never had to exclude anything in dnf.conf in my systemd-boot machines.
I just uninstalled all the grub packages using dnf.
I did need to remove a package or two from the protected list though.
Definitely a valid point, These commands were put together from what worked for me over the years, just posting them for reference.
1 Like
It’s working. It did generate today another entry for 6.6.10-cb1.0 (cachyos).
But a problem arouse: how can I disable the generation of the rescue image and entry?
it is occupying 100MB more than the kernel and I don’t use it.
By uninstalling the package dracut-config-rescue.x86_64.
I don’t think anyone uses the rescue image except when the system fails to otherwise boot properly.
With today’s drive sizes 100 MB seems insignificant and I wonder why you feel removing that image that may be very useful in an emergency would be necessary. Yes, the rescue image is larger but that is its purpose – to provide all that may be needed when the system fails to boot otherwise.
What is the output of df which should show the free space in /boot ?
My image sizes are
-rw-------. 1 root root 116490525 Nov 22 13:02 initramfs-0-rescue-c50eedc1bcb245299bc96b1173897ac2.img
-rw-------. 1 root root 36540925 Jan 5 17:52 initramfs-6.6.9-200.fc39.x86_64.img
and my free space shows
df
/dev/nvme0n1p2 941740 307172 569392 36% /boot
/dev/nvme0n1p1 238M 18M 221M 8% /boot/efi
I have 3 kernels plus the rescue image in /boot
The OP has switched to sd-boot and therefore all kernel and initrd images goes into the ESP so the df should show the size of /boot/efi or wherever the ESP is mounted.
If the ESP is big enough, there are no problems keeping the rescue image.
OOPs, I failed to recognize that he has switched to sd-boot.
In that case I believe the path for sd-boot would place the kernels in /efi so that would be the location to verify adequate space.
I believe fedora is preparing for switch to sd-boot by creating new installs with the efi partition at 600M and /boot at 1G size
My /boot/efi is already 629MB and my /boot 1074MB. The rescue entry is useless for me. Every time I needed it to help me back to my system it wasn’t helpful, it was much faster/practical to use a live image and chroot to my system. I would prefer to do like POP!_OS and keep a copy of the installation on a different partition, if that was the case.