This was included in F39 for new installs: cleanup systemd Install
There was a post on reddit: How to convert F39 from grup to systemd boot if you didn’t want to do a new installation.
I personally haven’t tried it.
4 Likes
I hope so, but I doubt it. I don’t see the advantages of GRUB, systemd-boot is cleaner spec file - wise, and a far cleaner /boot. I think it’s easier to manage as well over GRUB. I left GRUB around Fedora 29/30 for good, haven’t looked back. Also, haven’t had issues with Nvidia drivers since I made the move.
TBF, that’s still kind of messy, @glb has a better implementation, one that also has a Fedora magazine article to accompany it.
2 Likes
Can you please post the link? Thanks much!
1 Like
I have the steps from the video in a file somewhere, it’s good for reference but would need more tooling to be a full script.
1 Like
This is not by default. Can we have systemdboot by default.
As I recall, one of the requirements for a full switch is someone authorized from RedHat will need to work to have systemd-boot (aka gummiboot) signed for those that use secure boot. As systemd-boot is currently built as part of the systemd builds, I suspect that that will need to change to build systemd-boot as a separate package so it can be independently updated (and signed).
1 Like
I always wondered about that. . . When I do bootctl I see :
bootctl
System:
Firmware: UEFI 2.70 (INSYDE Corp. 24710.50)
Firmware Arch: x64
Secure Boot: disabled
TPM2 Support: no
Boot into FW: supported
Current Boot Loader:
Product: systemd-boot 254.9-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/533f37a7-d987-4de1-9a24-9545607ba1b2
File: └─/EFI/systemd/systemd-bootx64.efi
I thought as a feature it could enroll secureboot keys?
1 Like
IMO the reddit instructions are more straight forward. Seems like the article in the magazine is more about partitions, with maybe a small section regarding systemd boot. That’s probably why it didn’t show up in a Google search.
1 Like
The video does the walk through of the install, Like i mentioned I have the steps listed. The Reddit post, creates and mounts it all to /EFI I’ve done it in the past, it was originally under using Nvidia gpu’s with systemd-boot.
You end up with a more convoluted partitioning scheme IMO with /boot/ , /boot/efi, /EFI
What I was referencing was an easy documented, step by step way of converting an existing grub based system to systemd boot. If I found one, I would consider trying it, but have yet to come across it.
3 Likes
Yes, one can individually enroll secureboot keys, but having each person individually manage their own keys is not really viable, to be widely useful one needs systemd-boot to be signed using the Microsoft keys. I found the discussion that is ongoing about signing systemd-boot at: Issue #10765: secure boot signing for systemd-boot - releng - Pagure.io which indicates that this is still an on-going work in progress.
2 Likes
The question is if the different variants are able to add their latest boot entry to systemd-boot.
That would indeed be great to have, the issues are pretty old.
3 Likes
FWIW:
- make a backup of any important data you do not want to risk losing.
- unmount and remove grub’s (THREE!!!) partitions –
BIOSBOOT,/boot, and/boot/efi[1] - create one new ESP, update your /etc/fstab, and mount the ESP at
/boot[2] dnf install systemd-boot-unsigned[3]- install sd-boot with
bootctl install --esp-path=/boot --make-entry-directory=yes[4] - create
/etc/kernel/cmdline[5] - re-add the kernel to the new boot partition (aka ESP) with
kernel-install add $(uname -r) /lib/modules/$(uname -r)/vmlinuz
The final result might look something like this (your kernel version will be different):
# tree /boot
/boot
├── 2f9473ba6b744ccea0349a09a467f694
│ ├── 0-rescue
│ │ ├── initrd
│ │ └── linux
│ └── 6.8.0-0.rc6.20240227git45ec2f5f6ed3.50.fc41.x86_64
│ ├── initrd
│ └── linux
├── efi
│ ├── boot
│ │ └── bootx64.efi
│ ├── Linux
│ └── systemd
│ └── systemd-bootx64.efi
└── loader
├── entries
│ ├── 2f9473ba6b744ccea0349a09a467f694-0-rescue.conf
│ └── 2f9473ba6b744ccea0349a09a467f694-6.8.0-0.rc6.20240227git45ec2f5f6ed3.50.fc41.x86_64.conf
├── entries.srel
├── loader.conf
└── random-seed
10 directories, 11 files
Of course, the above proceedure is extremely dangerous in that it will leave your system unbootable if you get anything wrong. There are also a few details that you need to know such as that the ESP must be formatted with FAT32 (aka vfat) and that it must have its type code set to EF00. You also need to specify the permissions (umask and context) as mount options in /etc/fstab since FAT filesystems don’t support unix mode bits or SELinux permissions directly.
Here is what my /etc/fstab looks like:
PARTLABEL=boot@a /boot@a vfat umask=0077,shortname=lower,context=system_u:object_r:boot_t:s0,flush,discard,x-systemd.before=bootbind.service,nofail 0 0
PARTLABEL=boot@b /boot@b vfat umask=0077,shortname=lower,context=system_u:object_r:boot_t:s0,flush,discard,x-systemd.before=bootbind.service,nofail 0 0
My /etc/fstab is more complicated than the typical version would be because my system is configured with mirrored system drives (and ZFS). A more typical example might look more like this (lines containing “boot” are the only ones you should need to edit):
UUID=... / btrfs subvol=root ...
LABEL=boot /boot vfat shortname=lower,umask=0077,context=system_u:object_r:boot_t:s0 0 0
UUID=... /home btrfs subvol=home ...
Note that this configuration aligns closely with the current bootloader specification (Boot Loader Specification | UAPI Group Specifications) and with how other distros such as Arch are likely configured (Talk:Syslinux - ArchWiki) but it is not how the current Anaconda installer will configure a system if you use it to install the sd-boot bootloader. (The current Anaconda implementation deviates from the spec by mounting the ESP at /boot/efi. This is done because the shim package (which sd-boot doesn’t currently use) is hard-coded to place files at /boot/efi/EFI/fedora. I suspect that this sort of deviation from the spec is the sort of thing that will cause many many users great frustration for years (or decades) to come. You can use the correct /boot mountpoint and just let shim place its files there even though the path is wrong (or maybe uninstall that package). Just my 2¢.)
By the way, I’ve been using systemd-boot (with the ESP mounted at /boot) since before Fedora Linux 28 and I’ve only experienced one “significant” issue but that only happened with the upgrade from F28 to F29.
I prefer using sgdisk from the
gdiskpackage to manage GPT partitions. You will likely need to runpartprobeafter you’ve finished updating the partition table. ↩︎You will need the
dosfstoolspackage installed to format the ESP. Use something likemkfs -t vfat -n boot /dev/sda1to format the ESP with a FAT32 filesystem and set itsLABELto “boot”. The label you use here can be used to identify this filesystem in your /etc/fstab. Note that FAT32 labels are limited to 11 characters. The warning about case sensitivity can be ignored (unless you intend to install an old version of MS-DOS on your ESP). ↩︎Needing to install systemd-boot-unsigned is new as of Fedora Linux 38 ↩︎
I forgot to include the
--make-entry-directory=yes. Older versions of bootctl used to make that directory automatically, but more recent versions require this extra parameter. ↩︎I missed step 5 initially (though it will work without it, at least for a while). Before you run the last step of re-adding the kernel to the boot partition, you should create a
/etc/kernel/cmdlinefile containing your current kernel parameters. It will fall back to using whatever the current system was booted with by referencing/proc/cmdline, but it is best to be explicit about what you want those parameters to be. (You should not include the BOOT_IMAGE=… or initrd=… parameters from /proc/cmdline when creating /etc/kernel/cmdline.) ↩︎
5 Likes
@glb We had a chat about it several years ago, and watching your video I did write down the process with some minor tweaks. Not sure if I “should” post it here, but it’s been the only way I use the system now !
1 Like
Thanks. It’s OK that you linked the video here. Unfortunately though, it is out of date with respect to how the current version of Anaconda works. Someone pointed out a while back that Anaconda will no longer let you choose “vfat” as the filesystem to format /boot with. (It is an artificial limitation imposed by Anaconda on the assumption that you will be using the grub bootloader. 
)
2 Likes
So Blivet does it differently? Well either way, I have done the majority of these after a full install too, and it has worked. So immediately after the reboot into the fresh system, I have gone through this process. Then rebooted a second time with systemd-boot.
1 Like
Opensuse switching to systemdboot.
2 Likes
While I am an advocate for systemd-boot for it’s simplicity and features, A proper distribution needs to consider it’s user base and the potential for issues arising. Fedora knows it’s user base.
Having the option to do so is great, I’ve always said “If you know you need something you get it, otherwise rely on the distribution for support” I personally have been using it since Fedora 28/29. It has done nothing but provided comfortable ways of installing all I need, especially dealing with Nvidia.
Fedora has to consider many things before making something so critical as a default, if it were to happen it would take several releases to roll out. Having the option to do so at install is just fine IMO.
1 Like
Right now it is possible to boot many alternative OS’s (although probably not all), as all modern OS’s have an EFI stub, and there is even some automatic magic to detect and be able to boot arguably the most common alternative, Windows. However, systemd-boot still needs to be signed for this to be closer to being considered seamless (at least if you run Windows in secure boot mode).
Given the reality of legacy BIOS only systems, grub (or syslinux, or whatever) is likely to continue to exist for some time, although once systemd-boot is signed there will be one fewer reason to not consider making it the default for new UEFI capable system installations.
1 Like
I think we are 10-15yrs into Legacy BIOS not being commercially widespread. At some point there needs to be a pivot from it. New systems are UEFI only and consumers simply do not know it. This is the same issue we have with x_86_64v.X and 32bit/64bit. The layman simply wouldn’t know the difference. I don’t believe a system with SecureBoot can run BIOS any way?
1 Like