I'm exploring the boot- and management experience for a group of homogeneous Raspberry Pi systems using bootc, specifically using: U-Boot splash screen for the early boot stage, and plymouth splash screen/theme taking over. The setup itself works fine, but one of elements I have need for is to provide a polished boot experience while allowing end-users to customize branding, without direct access to the upstream container files.
Ideally, I'd like to ship a single container image to keep build-time permutations small. Rather than producing separate images for different branding/themes, users should be able to override the splash screen and Plymouth theme after deployment (i.e. controlled mutability).
However, there are a couple of challenges:
U-Boot
The raspberry pi's bootloader dont support efi directly, so it has to chainloads uboot and grub. So the U-Boot splash image is presently copied onto the boot (FAT) partition with a bootupctl shims. Since this file isn't tracked by bootc itself- a bootc upgrade and rebooting into the "next" deployment - you manually need to run bootupctl update to complete updating the splash image. In a scenario, where a default splash screen is provisioned with the container, you'd always have to bootc upgrade -> reboot now -> bootupctl update and gives the perception of a broken update.
Plymouth
Plymouth themes are often included in the initramfs, to my understanding theme assets are baked into initram so they load fast while the rootfs is still being prepared/loaded. Without rebuilding or regenerating the initramfs, the branding isn't updated and the directory where initram is loaded from is an immutable directory somewhere in /usr
I'm wondering if anybody has already explored or can recommend any good patterns into tackling this kind of issues. I'm thinking one the missing pieces is being able to defer some computations to deployment time, much like docker files which you can use CMD or ENTRYPOINT instructions perhaps initramfs inside the chroot of the next deployment.
I'm exploring the boot- and management experience for a group of homogeneous Raspberry Pi systems using bootc, specifically using: U-Boot splash screen for the early boot stage, and plymouth splash screen/theme taking over. The setup itself works fine, but one of elements I have need for is to provide a polished boot experience while allowing end-users to customize branding, without direct access to the upstream container files.
Ideally, I'd like to ship a single container image to keep build-time permutations small. Rather than producing separate images for different branding/themes, users should be able to override the splash screen and Plymouth theme after deployment (i.e. controlled mutability).
However, there are a couple of challenges:
U-Boot
The raspberry pi's bootloader dont support efi directly, so it has to chainloads uboot and grub. So the U-Boot splash image is presently copied onto the boot (FAT) partition with a
bootupctlshims. Since this file isn't tracked by bootc itself- a bootc upgrade and rebooting into the "next" deployment - you manually need to runbootupctl updateto complete updating the splash image. In a scenario, where a default splash screen is provisioned with the container, you'd always have tobootc upgrade -> reboot now -> bootupctl updateand gives the perception of a broken update.Plymouth
Plymouth themes are often included in the initramfs, to my understanding theme assets are baked into initram so they load fast while the rootfs is still being prepared/loaded. Without rebuilding or regenerating the initramfs, the branding isn't updated and the directory where initram is loaded from is an immutable directory somewhere in /usr
I'm wondering if anybody has already explored or can recommend any good patterns into tackling this kind of issues. I'm thinking one the missing pieces is being able to defer some computations to deployment time, much like docker files which you can use
CMDorENTRYPOINTinstructions perhaps initramfs inside the chroot of the next deployment.