bashclub-zfsbootmenu

Signiertes ZFSBootMenu-Image für „bashclub OS“ (bashclub-os), gebaut aus dem Debian-Kernel und den OpenZFS-Paketen von bashclub-zfs-kernel.

Warum ein eigenes Image

• Secure Boot: ZFSBootMenu liefert keine signierten Images. Die Kette ist Firmware (Microsoft-CA) → shim (Debian) → ZBM-Image (MOK) → kexec → Debian-Kernel (Debian-signiert) → ZFS-Modul (MOK). Image und Module tragen denselben bashclub-Schlüssel; der Server braucht keinen privaten Schlüssel.
• Unabhängig vom installierten System: ZBM bringt Kernel und ZFS mit. Ein kaputtes Modul im System macht den Server nicht unbootbar, ein älteres Boot Environment bleibt wählbar.
• Gleicher ZFS-Stand wie das System: Das Image enthält dieselbe OpenZFS-Version wie bashclub-zfs-kernel, Pool-Features passen also immer.

Bauen

build.sh <suite> <zbm-version> <kernel-abi> <deb-verzeichnis> <schlüssel> <ausgabe>
build.sh trixie 3.1.0 6.12.113+deb13-amd64 /root/out /root/keys /root/zbm-out

Läuft vollständig in einem Container debian:<suite>. Neue Debian-Versionen wie forky brauchen nur eine andere Suite und Pakete daraus. Ablauf:

1. Debian-Kernel und die OpenZFS-Pakete aus <deb-verzeichnis> installieren, einschließlich openzfs-zfs-dracut.
2. ZFSBootMenu aus dem Quelltext (make core dracut), Tarball geprüft gegen versions/zfsbootmenu-<version>.sha256.
3. generate-zbm erzeugt das EFI-Image (systemd-boot-Stub, mit dem Startbild der Marke als SplashImage, Standard: bashclub-Logo aus branding/) sowie Kernel und initramfs für den BIOS-Weg.
4. sbsign mit dem MOK-Schlüssel, sbverify prüft. Ebenso für Debians memtest86+: Der Installer legt es als eigenen UEFI-Booteintrag hinter shim ab, damit der Speichertest auch mit Secure Boot startet.

Ergebnis: zfsbootmenu.EFI (signiert, für shim als grubx64.efi), vmlinuz-bootmenu, initramfs-bootmenu.img, memtest86+x64.efi (signiert), memtest86+x64.bin (BIOS), SHA256SUMS.

Im ZBM-Menü öffnet Strg+X das Power-Menü: „Reboot to UEFI Firmware“ und „Speichertest / Memory test (memtest86+)“ (setzt den UEFI-Eintrag „bashclub memtest“ als nächsten Start; nur unter UEFI). In der Recovery-Shell gibt es firmware-setup. Das Textmenü nutzt das Farbschema der Marke (Konsolenpalette per early-setup-Hook, ZBM_PALETTE).

Ruhiger Start

Solange der Start in Ordnung ist, steht unter UEFI durchgehend das Startbild der Marke mit „Press Esc for boot menu“ da, bis das System per kexec startet und Plymouth übernimmt: kein Countdown, keine Meldungen. So geht es (zbm/, build.sh):

• Kernel-Zeile im signierten Image: quiet loglevel=0 console=tty2 fbcon=vc:2-63 zbm.timeout=3 watchdog.stop_on_reboot=0. Debians Kernel übernimmt die Framebuffer-Konsole sofort (ohne „deferred takeover“) und löschte dabei das Startbild. Mit fbcon=vc:2-63 bleibt tty1 ohne Framebuffer-Konsole: Das Bild des Stubs bleibt stehen. ZFSBootMenu läuft auf tty2 (console=tty2), alles, was es zeichnet, bleibt dort unsichtbar.
• Wartezeit ohne Countdown: bashclub_countdown ersetzt den Countdown von zfsbootmenu-init und wartet 3 s still auf Esc (Menü) oder Enter (sofort starten). Die Tasten liest es von der sichtbaren Konsole, die init.d/15-bashclub-keys gleich nach dem Start von ZFSBootMenu öffnet: Ein Esc während des Startbilds bleibt liegen und wirkt, sobald die Wartezeit beginnt.
• Sichtbar, sobald ZFSBootMenu etwas braucht (bashclub_unquiet, Wechsel auf tty2): Esc, jede Meldung von ZFSBootMenu (timed_prompt, z. B. Pool nicht importierbar, kein Kernel), Passphrase (zfs load-key -L prompt), Notfall-Shell, und Hinweise aus /run/bashclub-notice: Ein gescheiterter Probe-Boot meldet dort „Probe boot of … failed. Starting previous boot environment …“ und wartet 9 s (Enter startet, Esc öffnet das Menü). Scheitert der kexec des neuen Stands, steht das 5 s auf dem Schirm. Von Hand zeigt Alt+F2 ZFSBootMenu jederzeit.
• Wartezeit 3 s: Die Tastatur gehört ZFSBootMenu erst etwa 3 s nach dem Erscheinen des Startbilds (Kernel und initramfs laden), Tasten davor gehen verloren. Gemessen in einer VM (2026-10-28, je ein einzelnes Esc): 2,5 s nach dem Startbild verloren, 3,0 s Menü, 5,75 s Menü, 6,25 s zu spät (Start läuft). Esc wirkt also etwa von 3 s bis 6 s nach dem Erscheinen des Startbilds; das Startbild steht insgesamt knapp 8 s bis zum kexec. Wer Esc gedrückt hält oder mehrmals drückt, kommt sicher ins Menü.
• Vollbild in der Markenfarbe: Hat die Marke einen farbigen Hintergrund, füllt init.d/14-bashclub-splash gleich nach dem Start von ZFSBootMenu den Rand um das Startbild, den der Stub schwarz lässt, in dieser Farbe (bashclub-fbfill, kleines statisches Programm aus zbm/bashclub-fbfill.c, schreibt direkt in /dev/fb0; das Bild selbst bleibt unberührt, nichts springt). Der schwarze Rand steht so nur die ersten etwa 3 s. Bei schwarzem Hintergrund (bashclub) tut es nichts. Kosten: etwa 330 KB mehr im initramfs.
• BIOS: syslinux hat seine eigene Kernel-Zeile ohne console=tty2, ZFSBootMenu läuft wie gewohnt auf tty1 mit sichtbarem Countdown (3 s): ohne Startbild wüsste sonst niemand von Esc.

Grenzen: Der Stub (systemd-stub) füllt den Bildschirm außerhalb des Startbilds immer schwarz (fest im Stub, Apple: grau) und zeichnet kein Bild, das größer als der Bildschirm ist. Die Auflösung der Firmware ist beim Bauen unbekannt; ein Startbild mit farbiger Fläche (ZBM_SPLASH_CANVAS) hat deshalb auf größeren Bildschirmen zunächst einen schwarzen Rand, bis bashclub-fbfill ihn füllt (siehe oben). Skaliert wird das Bild nicht: Logo und Fläche bleiben gleich groß wie in Plymouth. Zwischen kexec und Plymouth übernimmt der Kernel des Systems die Konsole und zeigt etwa 1 s eine schwarze Fläche (ohne Text, ohne Cursor, siehe bashclub-os).

Stand 2026-10-23: ZBM 3.1.0 mit OpenZFS 2.4.4 und Kernel 6.12.113+deb13 gebaut und signiert (sbverify: OK). Der Boot unter Secure Boot wird mit dem Installer aus bashclub-os geprüft.

Marke: Startbild, Farben, Paketname

Startbild, Farben des Textmenüs und Paketname sind Bauparameter. branding/bashclub.env beschreibt die bashclub-Marke und ist der Standard; eine andere Marke bringt eine Datei derselben Form mit und baut mit BRAND=<datei>:

BRAND=<marke>/zbm.env build.sh trixie 3.1.0 <kernel-abi> <debs> <schlüssel> <ausgabe>
package.sh trixie <ausgabe> <pakete>

Wert	Bedeutung
ZBM_PACKAGE	Paketname; ein anderer als bashclub-zfsbootmenu ersetzt es (Provides: bashclub-zfsbootmenu (= <version>), Conflicts, Replaces)
ZBM_BRAND, ZBM_MAINTAINER	Name der Marke in der Paketbeschreibung, Maintainer
ZBM_SOURCES	Adresse des Quellcode-Manifests (@PACKAGE@, @VERSION@) für copyright
ZBM_SPLASH, ZBM_SPLASH_WIDTH, ZBM_SPLASH_BACKGROUND, ZBM_SPLASH_CANVAS	Startbild als SVG (Pfad relativ zur Datei), Breite in Pixeln, Hintergrund; optional eine Fläche <breite>x<höhe> in der Hintergrundfarbe mit dem Logo in der Mitte, passend zu einem Plymouth-Theme mit farbigem Grund (außerhalb füllt der Stub schwarz)
ZBM_SPLASH_HINT, ZBM_SPLASH_HINT_COLOR	Zeile unter dem Logo, Standard „Press Esc for boot menu“ (Englisch für jede Marke; Esc wirkt bis zum Ende der Wartezeit von ZBM, siehe „Ruhiger Start“), leer: keine
ZBM_PALETTE	16 Farben der Konsole (rrggbb, Index 0–15) für das Textmenü: 0 Hintergrund, 3 Akzent, 7 Text
ZBM_COPYRIGHT	optional: weitere DEP-5-Absätze für copyright, z. B. Lizenz bzw. Markenhinweis des Startbilds

build.sh prüft die Werte und legt sie als BRAND neben das Image; package.sh nimmt sie von dort, Image und Paket passen so immer zusammen. Alles andere ist für jede Marke gleich: dieselben Pfade (/usr/lib/bashclub-zfsbootmenu/, EFI/bashclub/ auf den ESPs), dasselbe bashclub-zbm-update mit Rückfall auf den vorigen Stand, derselbe Probe-Boot, derselbe MOK-Schlüssel. Ein Wechsel der Marke per apt ist deshalb ein gewöhnliches Update der ESPs (das bisherige Image bleibt als „vorige Version“ wählbar) und braucht unter Secure Boot keine neue MOK-Bestätigung. Das Image einer anderen Marke baut deren eigene CI aus diesem Repo; Logos fremder Marken liegen nicht hier.

Paket bashclub-zfsbootmenu

package.sh <suite> <build-ergebnis> <ausgabe> baut aus dem Ergebnis von build.sh das Paket, Version <ZBM>+zfs<OpenZFS>+deb<n>+b<Zähler> (z. B. 3.1.0+zfs2.4.4+deb13+b5; die CI setzt die Laufnummer als Zähler, so ist jeder Neubau ein Update). Inhalt: die Dateien unter /usr/lib/bashclub-zfsbootmenu/ und das Werkzeug bashclub-zbm-update (package/).

bashclub-zbm-update läuft nach jeder Installation und Aktualisierung des Pakets und, per dpkg-Trigger, wenn sich shim-signed oder grub-efi-amd64-signed ändern:

• ESPs: alle Partitionen vom Typ ESP auf den Platten des Pools mit bootfs, also auch eine nach dem Tausch einer Mirror-Platte neu eingerichtete.
• Je ESP: EFI/bashclub/ (shim, mmx64, ZBM als grubx64.efi), EFI/BOOT/ als Rückfall ohne NVRAM-Eintrag, EFI/memtest/ (shim → Debians signiertes GRUB → memtest86+), zfsbootmenu/ und – wenn die ESP für BIOS eingerichtet ist – syslinux/syslinux.cfg und memtest/. Jede Datei wird neben dem Ziel geschrieben und dann umbenannt.
• Rückfall: Weicht das ZBM auf der ESP vom neuen ab, wandert der alte Stand vorher nach EFI/bashclub-backup/ bzw. zfsbootmenu/backup/; Booteintrag „bashclub (vorige Version)“, unter BIOS beim Start Umschalt halten und backup eintippen.
• Booteinträge: fehlende Einträge („bashclub “, Rückfall, „bashclub memtest“) kommen ans Ende der Bootreihenfolge, die Reihenfolge des Admins bleibt; nur der Installer (--install) stellt „bashclub “ nach vorn.
• bashclub-zbm-update --list zeigt Stand und Einträge, ohne etwas zu ändern. Rückgabe: 0 alles aktuell, 1 eine ESP gescheitert, 2 keine aktualisiert, 3 kein Boot-Pool.

Neubau ohne Handgriff: Die Pipeline läuft zusätzlich nachts (2:30) und baut nur, wenn sich ein Eingang geändert hat: OpenZFS oder Kernel-ABI von bashclub-zfs-kernel in apt testing, memtest86+ in Debian oder die ZBM-Version in versions/current (Liste des letzten Builds: https://repo.bashclub.org/zbm/testing/INPUTS). Ein neuer Debian-Kernel kommt so nachts über bashclub-zfs-kernel (1:00) und ZBM (2:30) bis in die ISO (4:00).

Schon installierte Systeme ohne Paket (Prototyp-ISOs bis Oktober 2026): apt install bashclub-zfsbootmenu übernimmt die ESPs; der bisherige Stand bleibt als Rückfall.

Offen

• Hooks für den Probe-Boot (aus Spike B von Freehold Office), Watchdog.
• CI: Neubau bei jedem ZBM-, OpenZFS- und Kernel-Release; arm64.

Lizenz

Quellcode zu jedem veröffentlichten Paket (eigene Skripte, Upstream-Tarballs, alle enthaltenen Debian-Pakete) liegt am selben Ort unter https://repo.bashclub.org/sources/, Manifest je Paket unter manifests/deb/<paket>_<version>.sources (bashclub-ci ci/sources.py, ADR 0020).

Eigene Skripte: GPL-3.0-or-later (LICENSE). ZFSBootMenu: MIT. OpenZFS: CDDL-1.0.