bashclub/bashclub-zfsbootmenu
Watch
1
0
Fork
You've already forked bashclub-zfsbootmenu
 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

Ruhiger Start: Startbild bis kexec, Wartezeit ohne Countdown #5

Merged
freehold-bot merged 5 commits from ruhiger-start into main 2026-10-28 22:58:56 +01:00
Conversation 0 Commits 5 Files changed 9 +246 -6
freehold-bot commented 2026-10-28 11:31:42 +01:00
Collaborator
Copy link

Hängt ab von #4 (Marke als Bauparameter): Basis dieses PRs ist marke-als-parameter. Zusammen mit bashclub/bashclub-os „Ruhiger Start“ (Kernel-Zeile, Plymouth) und freehold-office/freehold-brand „Ruhiger Start“.

Was

Ruhiger Start unter UEFI: Solange der Start in Ordnung ist, steht das Startbild der Marke mit „Press Esc for boot menu“ durchgehend da, bis das System per kexec startet; kein Countdown, keine Meldungen.

  • Kernel-Zeile im signierten Image: quiet loglevel=0 console=tty2 fbcon=vc:2-63 zbm.timeout=2 watchdog.stop_on_reboot=0. Debians Kernel hat kein FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER und löschte das Startbild sofort. Mit fbcon=vc:2-63 bleibt tty1 ohne Framebuffer-Konsole, das Bild des Stubs bleibt stehen. ZBM läuft unsichtbar auf tty2.
  • bashclub_countdown (zbm/bashclub-quiet.sh, an zfsbootmenu-core.sh angehängt) ersetzt den Countdown von zfsbootmenu-init: Es wartet still auf Esc (Menü) oder Enter. init.d/15-bashclub-keys öffnet tty1 früh, damit ein Esc während des Startbilds nicht verloren geht.
  • Sichtbar, sobald ZBM etwas braucht (bashclub_unquiet = chvt 2): bei Esc, in timed_prompt (alle Meldungen), in emergency_shell, vor zfs load-key -L prompt und bei Hinweisen aus /run/bashclub-notice. Ein gescheiterter Probe-Boot zeigt „Probe boot of … failed. Starting previous boot environment …“ 9 s lang. Scheitert der kexec des neuen Stands, steht das 5 s da. Alt+F2 zeigt ZBM jederzeit von Hand.
  • Farben: Die Palette gilt für die Konsole von ZBM (tty2). Das Menü behält die Markenfarben.
  • BIOS (syslinux) bleibt unverändert, mit sichtbarem Countdown (3 s): Ohne Startbild wüsste sonst niemand von Esc.
  • build.sh prüft die Kernel-Zeile, chvt und den Ersatz im Image. sed-Anpassungen an ZBM 3.1.0 mit Zählprüfung, wie schon bei zpowermenu.

Wartezeit 2 s, begründet: In der VM vergehen vom Startbild bis zur Wartezeit gut 3,7 s (Kernel, initramfs, Pool-Import). Tasten wirken ab etwa 2,5–3 s nach dem Erscheinen des Startbilds; davor gehen sie verloren (Esc 2,0 s danach: verloren, 2,75 s und 3,0 s danach: Menü). Der Hinweis steht damit gut 5,5 s da, und Esc wirkt in den letzten etwa 3 s davon. Esc halten oder mehrmals drücken klappt sicher. Jede Sekunde mehr verlängert jeden Start.

Getestet

  • Bau im Container mit einem eigenen Testschlüssel (bashclub und Havora), sbverify: OK; build.sh prüft die Kernel-Zeile und lsinitrd.
  • VM (OVMF, Secure Boot aus), Bildfolge per QMP-Screendump alle 0,1 s: Startbild ununterbrochen bis kexec (vorher folgten Schwarz, eine Textzeile von udev, der Countdown und Kernelmeldungen).
  • Esc während des Startbilds öffnet das Menü (iso/test-vm.sh in bashclub-os, Teil 2, und von Hand). Ctrl+E (Kernel-Zeile bearbeiten) funktioniert.
  • Rückfall des Probe-Boots nach Kernel-Panic: Hinweis sichtbar (iso/test-vm.sh Teil 7a mit Bildschirmfoto, Havora-Bildfolge). Teil 7b (Watchdog, Netzprüfung) bleibt grün.
  • BIOS: sichtbarer Countdown wie bisher (Teil 2 seabios).

Grenzen

  • Der Stub füllt den Bildschirm außerhalb des Startbilds fest schwarz und zeichnet kein Bild, das größer als der Bildschirm ist. Ein Startbild mit farbiger Fläche hat auf größeren Bildschirmen deshalb einen schwarzen Rand. Bei bashclub (Hintergrund schwarz) tritt das nicht auf.
  • Zwischen kexec und Plymouth ist der Schirm etwa 1,3 s schwarz: Der Kernel des Systems übernimmt die Konsole, ohne Text und ohne Cursor.
  • Unter Secure Boot nicht getestet (Testschlüssel). Der Mechanismus ändert nichts an Signatur oder kexec.

Nachtrag (2026-10-28, Basis jetzt main)

  • Wartezeit 3 s (Entscheidung Thorsten). Gemessen in der VM mit je einem einzelnen Esc nach dem Erscheinen des Startbilds:

    • 2,5 s: verloren
    • 3,0 s: Menü
    • 5,75 s: Menü
    • 6,25 s: zu spät

    Esc wirkt also etwa von 3 s bis 6 s nach dem Startbild. Das Startbild steht knapp 8 s bis zum kexec.

  • Rand in der Markenfarbe: init.d/14-bashclub-splash füllt gleich nach dem Start von ZBM den Rand, den der Stub schwarz lässt, in ZBM_SPLASH_BACKGROUND.

    • Werkzeug: bashclub-fbfill, ein eigenes, kleines statisches C-Programm (zbm/bashclub-fbfill.c, etwa 90 Zeilen). Es schreibt per mmap in /dev/fb0 und lässt das mittige Rechteck mit dem Bild unberührt. Es wird nichts skaliert; Logo und Fläche bleiben gleich groß wie in Plymouth.
    • Bei schwarzem Hintergrund (bashclub) tut es nichts.
    • Ergebnis (Havora in der VM bei 1280×800): Der Rand steht etwa 2,9 s, danach steht der ganze Schirm in Nacht bis kexec. Am Übergang zwischen Rand und Fläche sind die Pixel gleich (0b1a2e).
    • Aufwand: etwa 120 Zeilen. initramfs: +335 KB komprimiert, das Programm hat 795 KB statisch. Dazu gcc/libc6-dev im Build-Container.
    • Risiko gering: Ohne /dev/fb0 oder bei unpassendem Format endet es mit Rückgabe 2, und ZBM startet wie zuvor. Plymouth im ZBM-initramfs wäre deutlich größer und schwerer zu kontrollieren.

  • Die Basis-PR #4 ist gemergt, die Basis dieses PRs ist jetzt main.

🤖 Generated with Claude Code

**Hängt ab von #4** (Marke als Bauparameter): Basis dieses PRs ist `marke-als-parameter`. Zusammen mit bashclub/bashclub-os „Ruhiger Start“ (Kernel-Zeile, Plymouth) und freehold-office/freehold-brand „Ruhiger Start“. ## Was Ruhiger Start unter UEFI: Solange der Start in Ordnung ist, steht das Startbild der Marke mit „Press Esc for boot menu“ durchgehend da, bis das System per kexec startet; kein Countdown, keine Meldungen. - **Kernel-Zeile im signierten Image:** `quiet loglevel=0 console=tty2 fbcon=vc:2-63 zbm.timeout=2 watchdog.stop_on_reboot=0`. Debians Kernel hat kein `FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER` und löschte das Startbild sofort. Mit `fbcon=vc:2-63` bleibt tty1 ohne Framebuffer-Konsole, das Bild des Stubs bleibt stehen. ZBM läuft unsichtbar auf tty2. - **`bashclub_countdown`** (`zbm/bashclub-quiet.sh`, an `zfsbootmenu-core.sh` angehängt) ersetzt den Countdown von `zfsbootmenu-init`: Es wartet still auf Esc (Menü) oder Enter. `init.d/15-bashclub-keys` öffnet tty1 früh, damit ein Esc während des Startbilds nicht verloren geht. - **Sichtbar, sobald ZBM etwas braucht** (`bashclub_unquiet` = `chvt 2`): bei Esc, in `timed_prompt` (alle Meldungen), in `emergency_shell`, vor `zfs load-key -L prompt` und bei Hinweisen aus `/run/bashclub-notice`. Ein gescheiterter Probe-Boot zeigt „Probe boot of … failed. Starting previous boot environment …“ 9 s lang. Scheitert der kexec des neuen Stands, steht das 5 s da. Alt+F2 zeigt ZBM jederzeit von Hand. - **Farben:** Die Palette gilt für die Konsole von ZBM (tty2). Das Menü behält die Markenfarben. - **BIOS (syslinux)** bleibt unverändert, mit sichtbarem Countdown (3 s): Ohne Startbild wüsste sonst niemand von Esc. - `build.sh` prüft die Kernel-Zeile, `chvt` und den Ersatz im Image. sed-Anpassungen an ZBM 3.1.0 mit Zählprüfung, wie schon bei `zpowermenu`. **Wartezeit 2 s, begründet:** In der VM vergehen vom Startbild bis zur Wartezeit gut 3,7 s (Kernel, initramfs, Pool-Import). Tasten wirken ab etwa 2,5–3 s nach dem Erscheinen des Startbilds; davor gehen sie verloren (Esc 2,0 s danach: verloren, 2,75 s und 3,0 s danach: Menü). Der Hinweis steht damit gut 5,5 s da, und Esc wirkt in den letzten etwa 3 s davon. Esc halten oder mehrmals drücken klappt sicher. Jede Sekunde mehr verlängert jeden Start. ## Getestet - Bau im Container mit einem eigenen Testschlüssel (bashclub und Havora), `sbverify`: OK; `build.sh` prüft die Kernel-Zeile und `lsinitrd`. - VM (OVMF, Secure Boot aus), Bildfolge per QMP-Screendump alle 0,1 s: Startbild ununterbrochen bis kexec (vorher folgten Schwarz, eine Textzeile von udev, der Countdown und Kernelmeldungen). - Esc während des Startbilds öffnet das Menü (`iso/test-vm.sh` in bashclub-os, Teil 2, und von Hand). Ctrl+E (Kernel-Zeile bearbeiten) funktioniert. - Rückfall des Probe-Boots nach Kernel-Panic: Hinweis sichtbar (`iso/test-vm.sh` Teil 7a mit Bildschirmfoto, Havora-Bildfolge). Teil 7b (Watchdog, Netzprüfung) bleibt grün. - BIOS: sichtbarer Countdown wie bisher (Teil 2 seabios). ## Grenzen - Der Stub füllt den Bildschirm außerhalb des Startbilds fest schwarz und zeichnet kein Bild, das größer als der Bildschirm ist. Ein Startbild mit farbiger Fläche hat auf größeren Bildschirmen deshalb einen schwarzen Rand. Bei bashclub (Hintergrund schwarz) tritt das nicht auf. - Zwischen kexec und Plymouth ist der Schirm etwa 1,3 s schwarz: Der Kernel des Systems übernimmt die Konsole, ohne Text und ohne Cursor. - Unter Secure Boot nicht getestet (Testschlüssel). Der Mechanismus ändert nichts an Signatur oder kexec. ## Nachtrag (2026-10-28, Basis jetzt `main`) - **Wartezeit 3 s** (Entscheidung Thorsten). Gemessen in der VM mit je einem einzelnen Esc nach dem Erscheinen des Startbilds: - 2,5 s: verloren - 3,0 s: Menü - 5,75 s: Menü - 6,25 s: zu spät Esc wirkt also etwa von 3 s bis 6 s nach dem Startbild. Das Startbild steht knapp 8 s bis zum kexec. - **Rand in der Markenfarbe:** `init.d/14-bashclub-splash` füllt gleich nach dem Start von ZBM den Rand, den der Stub schwarz lässt, in `ZBM_SPLASH_BACKGROUND`. - Werkzeug: `bashclub-fbfill`, ein eigenes, kleines statisches C-Programm (`zbm/bashclub-fbfill.c`, etwa 90 Zeilen). Es schreibt per mmap in `/dev/fb0` und lässt das mittige Rechteck mit dem Bild unberührt. Es wird nichts skaliert; Logo und Fläche bleiben gleich groß wie in Plymouth. - Bei schwarzem Hintergrund (bashclub) tut es nichts. - Ergebnis (Havora in der VM bei 1280×800): Der Rand steht etwa 2,9 s, danach steht der ganze Schirm in Nacht bis kexec. Am Übergang zwischen Rand und Fläche sind die Pixel gleich (`0b1a2e`). - Aufwand: etwa 120 Zeilen. initramfs: +335 KB komprimiert, das Programm hat 795 KB statisch. Dazu `gcc`/`libc6-dev` im Build-Container. - Risiko gering: Ohne `/dev/fb0` oder bei unpassendem Format endet es mit Rückgabe 2, und ZBM startet wie zuvor. Plymouth im ZBM-initramfs wäre deutlich größer und schwerer zu kontrollieren. - Die Basis-PR #4 ist gemergt, die Basis dieses PRs ist jetzt `main`. 🤖 Generated with [Claude Code](https://claude.com/claude-code) 
Unter UEFI läuft ZBM auf tty2 (console=tty2 fbcon=vc:2-63 im signierten
Image): tty1 bleibt ohne Framebuffer-Konsole, das Startbild des Stubs
bleibt stehen, bis das System per kexec startet. bashclub_countdown
ersetzt den Countdown von zfsbootmenu-init und wartet 2 s still auf Esc
(Menü) oder Enter; init.d/15-bashclub-keys öffnet tty1 früh, damit ein
Esc während des Startbilds nicht verloren geht. timed_prompt,
emergency_shell und Passphrasen wechseln vorher auf tty2
(bashclub_unquiet). Die Palette gilt für die Konsole von ZBM.
BIOS (syslinux) bleibt wie bisher mit sichtbarem Countdown.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Ein nicht bestätigter Probe-Boot legt einen Hinweis in /run/bashclub-notice,
den bashclub_countdown 10 s zeigt (Enter startet, Esc öffnet das Menü);
scheitert der kexec des neuen Stands, steht das 5 s auf dem Schirm.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Die Zeile „Booting … in N seconds“ hat so viele Stellen wie zbm.timeout;
bei 10 s blieb beim Wechsel auf 9 ein „B“ stehen (Bildfolge Havora).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
zbm.timeout=3 (Entscheidung Thorsten). Gemessen: Esc wirkt etwa 3–6 s
nach dem Erscheinen des Startbilds.

Der Stub füllt außerhalb des Startbilds fest schwarz. init.d/14-bashclub-splash
füllt diesen Rand gleich nach dem Start von ZBM in ZBM_SPLASH_BACKGROUND
(bashclub-fbfill, kleines statisches Programm, schreibt in /dev/fb0; das
Bild bleibt unberührt). Bei schwarzem Hintergrund nichts zu tun.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
freehold-bot changed target branch from marke-als-parameter to main 2026-10-28 16:58:43 +01:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
bashclub/bashclub-zfsbootmenu!5
No description provided.