You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently bootc install to-disk --bootloader systemd bails with "bootupd is required for ostree-based installs" when using the ostree backend. This blocks using systemd-boot on ostree-based systems.
The problem
ostree needs hardlinks and symlinks on /boot for atomic deployment swaps, so it requires a POSIX filesystem (ext4/XFS). systemd-boot can only read FAT32. These are fundamentally incompatible -- ostree can't write to FAT32, systemd-boot can't read ext4.
The composefs backend avoids this entirely by not using ostree's /boot management. But for the ostree backend, there's no path forward today.
Proposed approach: translation layer
I have a working implementation (PR incoming) that adds a translation layer between ostree's /boot and the ESP:
Create an ext4 /boot partition for ostree's internal use (hardlinks, symlinks, atomic swaps)
Set sysroot.bootprefix=false so BLS paths are relative to /boot root
After ostree writes BLS entries to /boot, copy them (plus kernel + initrd) to the FAT32 ESP
This gives ostree the POSIX filesystem it needs while giving systemd-boot the FAT32 it needs. The ESP has plenty of space (512MB) for a couple of kernels + initrds.
Tested on Fedora 42 with QEMU + OVMF 4M -- system boots with systemd-boot v257, ostree deployment active, kargs.d entries in /proc/cmdline.
Upgrade path (needs discussion)
The install-time sync is straightforward because ostree has already written BLS entries to /boot by the time we copy them. The upgrade path is harder: stage_tree_with_options stages the deployment but does NOT write new BLS entries to /boot -- that happens during the next boot via ostree-finalize-staged.service. So there's nothing to copy to the ESP before reboot.
Options I see:
Generate BLS entries from staged deployment metadata and write directly to ESP
Hook into ostree-finalize-staged.service to sync ESP during early boot
Currently
bootc install to-disk --bootloader systemdbails with "bootupd is required for ostree-based installs" when using the ostree backend. This blocks using systemd-boot on ostree-based systems.The problem
ostree needs hardlinks and symlinks on /boot for atomic deployment swaps, so it requires a POSIX filesystem (ext4/XFS). systemd-boot can only read FAT32. These are fundamentally incompatible -- ostree can't write to FAT32, systemd-boot can't read ext4.
The composefs backend avoids this entirely by not using ostree's /boot management. But for the ostree backend, there's no path forward today.
Proposed approach: translation layer
I have a working implementation (PR incoming) that adds a translation layer between ostree's /boot and the ESP:
sysroot.bootprefix=falseso BLS paths are relative to /boot rootThis gives ostree the POSIX filesystem it needs while giving systemd-boot the FAT32 it needs. The ESP has plenty of space (512MB) for a couple of kernels + initrds.
Tested on Fedora 42 with QEMU + OVMF 4M -- system boots with systemd-boot v257, ostree deployment active, kargs.d entries in /proc/cmdline.
Upgrade path (needs discussion)
The install-time sync is straightforward because ostree has already written BLS entries to /boot by the time we copy them. The upgrade path is harder:
stage_tree_with_optionsstages the deployment but does NOT write new BLS entries to /boot -- that happens during the next boot viaostree-finalize-staged.service. So there's nothing to copy to the ESP before reboot.Options I see:
ostree-finalize-staged.serviceto sync ESP during early bootI'd appreciate guidance on which approach fits best with bootc's architecture.
Related