bootc-dev / bootc-dev/bootc

uboot and plymouth splash screen customisations

Open
#2,367 4 comments 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
2.3k
Forks
230
Avg merge
3d 12h
Merged PRs (30d)
38

Description

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.

Contributor guide

Open the contributing guide

Research direction

Start with the bootupctl update flow during bootc upgrade and reboot, then examine how U-Boot splash assets and Plymouth themes are included in the initramfs of the next deployment. Done means a documented pattern for deployment-time branding changes that handles both splash stages without requiring separate images or manual post-upgrade repair.

Written by the indexing model from the issue text.

Assessment

Tech stack
linux, raspberry-pi
Domain
embedded-iot, operating-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.