#20 poor integration of systemd-boot
Closed by fansari. Opened by fansari.

As I have discussed here:

https://discussion.fedoraproject.org/t/getting-rid-of-grub/1816

systemd-boot support for Fedora SB is very bad.

It was not clear to me right from the beginning that setting up the /boot partition with vfat would end up with a system you cannot update anymore because ostree does not like this.

On the other hand with any other filesystem (ext4, xfs) the UEFI cannot read the kernel. This was something clear to me that kernel and initrd have both to be placed on a vfat partition.

Meanwhile I have setup some test installation putting kernel and initrd into /boot/efi but this is not maintained by the update process.


After I read some comments on bugzilla it seems that Fedora will not support different boot loader. Although the user can install systemd-boot if he wants to.

The script I suggested (see the link above) is enough for me to maintain my setup.

So I guess since Fedora will stick to grub nothing more could be done.

Metadata Update from @fansari:
- Issue status updated to: Closed (was: Open)

Thanks for the investigation you've done here! But yes, I think this is best closed - supporting GRUB is hard enough - trying to support GRUB and something in addition, even harder. So, any replacement worth putting effort into would have to be part of a plan to at least eventually replace GRUB entirely.

The reason that OSTree doesn't like VFAT is it doesn't allow standard UNIX tricks for atomic changes - there is inevitably an intermediate state where the configuration is corrupt, and if power failure (etc.) occurred at that point, the result would be broken.

My problem is: I have no knowledge on OSTree. After I played a little bit around with Silverblue my ostree got into a state where no update command where working and "rpm-ostree status" did not work and gave a timeout error. I don't even know how to rescue such a system. The normal way with chroot and afterwards making binds for /dev /sys and /proc does not work.

What I mean is:I don't know how many people are out there who will be able to hack OSTree if something goes wrong. In my case the only thing I could do was to reinstall my PC.

Per https://github.com/ostreedev/ostree/issues/1801 I have no opposition to trying to support other bootloaders at a best-effort level, but at this time I don't see the CoreOS team actively pursuing it either. We have large gaps in CI that we need to fill to support variations like that, among other work.

The reason that OSTree doesn't like VFAT is it doesn't allow standard UNIX tricks for atomic changes - there is inevitably an intermediate state where the configuration is corrupt, and if power failure (etc.) occurred at that point, the result would be broken.

Don't see it as a problem since there are standard failover mechanisms..

After I played a little bit around with Silverblue my ostree got into a state where no update command where working and "rpm-ostree status" did not work and gave a timeout error.

What is the update commands which put your system to this state? I want to try it myself.

After I played a little bit around with Silverblue my ostree got into a state where no update command where working and "rpm-ostree status" did not work and gave a timeout error.

What is the update commands which put your system to this state? I want to try it myself.

After I played a little bit around with Silverblue my ostree got into a state where no update command where working and "rpm-ostree status" did not work and gave a timeout error.

What is the update commands which put your system to this state? I want to try it myself.

The only update command I used is "rpm-ostree upgrade"

As I have discussed here:

https://discussion.fedoraproject.org/t/getting-rid-of-grub/1816

systemd-boot support for Fedora SB is very bad.

It was not clear to me right from the beginning that setting up the /boot partition with vfat would end up with a system you cannot update anymore because ostree does not like this.

On the other hand with any other filesystem (ext4, xfs) the UEFI cannot read the kernel. This was something clear to me that kernel and initrd have both to be placed on a vfat partition.

Meanwhile I have setup some test installation putting kernel and initrd into /boot/efi but this is not maintained by the update process.

Could you describe the steps more acurate or try with SB 33.
I've been trying this extensively but systemd-boot can never find (bootctl command finds it)
the kernel. When you select in systemd-boot the entry it shows error loading \path\kernel no such file or directory

If you want to do this the main point is that your write a script which puts your config into /boot/efi/loader/entries/-.fc32.x86_64.conf.

In the link above I have suggested such a script but it is not perfect. If you run it after "rpm-ostree upgrade" but as I found out: if you after this do a change like installing an rpm you have manually to change the boot.0 to boot.1 in the loader config mentioned above. If you then do another rpm change you have to keep it. Only change the 0 or 1 flag after the first rpm change you do after you did an upgrade.

Managed to install systemd-boot.
The error message is incorrect in systemd-boot.

It says that the kernel was not found, nautilus failed to copy the kernel so the file was present but 0 bytes.
Instead it should say kernel invalid...

Metadata