uboot and plymouth splash screen customisations
- Lingua principale
- Rust
- Stelle
- 2.3k
- Fork
- 230
- Merge medio
- 3g 3h
- PR unite (30g)
- 36
Descrizione
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.
Guida per i contributori
Apri la guida per i contributori
Direzione di ricerca
Inizia con il flusso di aggiornamento di bootupctl durante bootc upgrade e il riavvio, quindi esamina come gli asset splash di U-Boot e i temi Plymouth vengano inclusi nell’initramfs del deployment successivo. Il lavoro è completato quando esiste un modello documentato per le modifiche al branding durante il deployment che gestisca entrambe le fasi dello splash senza richiedere immagini separate o una riparazione manuale post-aggiornamento.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- linux, raspberry-pi
- Ambito
- embedded-iot, operating-systems
- Tipo di issue
- Funzionalità
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Stato di attività
- Tranquilla
- Chiarezza
- Da chiarire
- Idoneità per principianti
- 30/100