Fedora Silverblue 41: "Systemd-boot cannot be utilized with the current type of payload"

[bam80]

systemd-boot installation is not supported for Atomic Desktops by Anaconda:

• inst.sdboot Anaconda Boot Option
• bootloader [--sdboot] Kickstart Command

anaconda/pyanaconda/modules/storage/bootloader/systemd.py

Lines 80 to 86 in 659bc62

	"""Verify the bootloader configuration."""
	if self._get_payload_type() != PAYLOAD_TYPE_DNF:
	self.errors.append(_(
	"Systemd-boot cannot be utilized with the current type of payload. "
	"Choose an installation media that supports package installation."
	))
	return False

Since 41(42?), Fedora Silverblue supports systemd-boot (at least it can be installed manually and works), so it's auto-installation should be supported, too.
Furthermore, ostree-grub2 will be removed from the future versions..

@Conan-Kudo @jlintonarm @jlinton @travier

[Conan-Kudo]

Who said grub2 is getting removed? Nobody said that anywhere.

[bam80]

It's about ostree-grub2, which doesn't ease the problem:
fedora-silverblue/issue-tracker#120
Will happen on F42 SB.

[Conan-Kudo]

bootupd supports GRUB, RPM-OSTree based Fedora variants will use that for GRUB instead of ostree-grub2.

[bam80]

Please read what's the problem about again.

Fedora Silverblue supports systemd-boot, so it's installation should be supported, too.

[travier]

systemd-boot is not yet supported for Atomic Desktops.

We are not removing GRUB2 from the Atomic Desktops in Fedora 42, only part of the ostree/grub2 integration that is no longer needed now that we can ensure that all bootloaders are BLS capable.

[bam80]

What I mean by systemd-boot support is it can be installed manually and works on SB.

That's enough to be able to install it with the Kickstart option too, I suppose.
Be it supported "officially" (installed by default) is seems to me another question not directly related with the issue.

[jlinton]

Is there a bit of confusion about the boot manager aspect of systemd-boot here vs the bootloader/UKI bits?

But at the same time the systemd-boot package is not yet signed (Without checking again) so shim+$OPTIONALS+uki is an 'ugly' but usable boot path for the time being. The inst.sdboot option is really only supported for regular anaconda installs for the time being. Plus the ostree based paths in anaconda used for atomic images need to be merged if there is a desire to change the boot flow for those kinds of images.

Part of the reason I did the systemd-boot->kernel path is to avoid shim, grub and having a lot of complex additional (ex advanced filesystems like btrfs) code running in UEFI context as its been shown that code becomes targets for persistent exploits which can hide from the kernel/etc.

So, yes more work is needed, but my focus personally is simplifying the existing boot flow, rather than adding more options (ex UEFI->systemd-boot manager->normal kernel->upstream kernel validates and measures initrd)

[bam80]

The inst.sdboot option is really only supported for regular anaconda installs for the time being.

If so, should we make it clear in some docs (Anaconda, etc.)?

[bam80]

So, yes more work is needed

How about start with generating BootLoaderSpec boot entry files stored in /boot/loader/entries/ even for grub (GRUB_ENABLE_BLSCFG=true) instead of casual grub.cfg?

That alone would presumably solve current issues with multiboot installations..

[Conan-Kudo]

That's already what's going on with the move to bootupd for F42.