bashclub-os

bashclub OS: Debian mit Root auf ZFS, ZFSBootMenu, Boot Environments, Secure Boot. Installer und Live-/Recovery-ISO; Paketquelle apt.bashclub.org. Baut auf bashclub-zfs-kernel (Kernel mit signierten OpenZFS-Modulen) und bashclub-zfsbootmenu (signiertes ZBM-Image).

Stand: Installer bashclub-install mit Konfiguration, Prüfungen, Trockenlauf, geführtem Assistenten und Installation (UEFI und BIOS, Mirror als Boot-Pool und Datenpools auf VM geprüft). Secure Boot mit MOK-Schlüssel auf VM geprüft. ISO „bashclub OS“ (Live-System mit Installer). Boot-Environment-Werkzeug mit Probe-Boot, Offline-Installation und Recovery folgen.

bashclub-install

bashclub-install disks                  # Platten: by-id, Größe, HDD/SSD, Modell, Belegung
bashclub-install validate install.yaml  # Konfiguration prüfen
bashclub-install plan install.yaml      # Trockenlauf: was mit welcher Platte passiert, mit Befehlen
bashclub-install wizard                 # interaktiv (whiptail), erzeugt install.yaml
bashclub-install tui --packages DIR   # Installer der ISO: Assistent, Bestätigung, Installation
bashclub-install install install.yaml --packages DIR

--packages: unsere Pakete (bashclub-zfs-kernel und OpenZFS, bashclub-zfsbootmenu, bashclub-base, bashclub-branding-default, bashclub-archive-keyring, bashclub-boot-env, Metapaket bashclub-os), auf der ISO unter /usr/share/bashclub-install/packages. Danach hält apt sie aus apt.bashclub.org aktuell, siehe „Pakete“.

• Assistent: Er fragt in dieser Reihenfolge Sprache, Land, Zeitzone, Tastatur, Rechnername, Netz, Benutzer und Partitionierung ab, zeigt am Ende die Zusammenfassung („Installieren“ oder „Zurück“) und schreibt dieselbe YAML-Datei wie für die unbeaufsichtigte Installation.
  • Vor und Zurück: Jeder Schritt hat „Zurück“ (Knopf oder Esc). Eingaben bleiben erhalten, auch wenn der Assistent nach einem Abbruch oder einer gescheiterten Installation neu beginnt; ein leeres Passwortfeld behält das bisherige Passwort.
  • Schrift: Bei hoher Auflösung wählt der Installer die größte Terminus-Schrift, bei der der Assistent noch passt (bei 4K verdoppelt); das installierte System bekommt die passende Größe in /etc/default/console-setup (console_font, Standard auto).
  • Sprachen: Deutsch (Standard) und Englisch; Französisch, Italienisch, Spanisch, Niederländisch und Polnisch als Entwurf. Übersetzungen in po/<sprache>.po (gettext); po/update.sh zieht neue Texte nach, po/build.sh erzeugt die .mo-Dateien.
  • Land: EU-27, EFTA und Vereinigtes Königreich; es belegt Zeitzone, Tastatur und Locale vor. Länder- und Tastaturnamen kommen übersetzt aus Debian (iso-codes, xkb-data). Über „Andere …“ sind alle europäischen Zeitzonen erreichbar.
  • Netz (NetworkManager): Liste der Karten (Ethernet und WLAN, mit MAC, Treiber, Link, Adresse); bei nur einer Karte keine Frage. Die übrigen Karten werden abgeschaltet, fremde Default-Routen entfernt. Bei WLAN: Suche (stärkstes Signal zuerst, „Andere SSID“ für versteckte Netze) und WPA2-Personal-Passwort; gespeichert wird nur der PSK-Hash. Der Assistent zeigt die per DHCP bezogenen Werte (Adresse, Gateway, DNS) und fragt, ob sie bleiben oder fest eingestellt werden (vorbelegt). Alles gilt sofort im Live-System; danach prüft er Gateway (ping) und deb.debian.org, bei Problemen fragt er nach. Das installierte System bekommt die Verbindung als Keyfile (/etc/NetworkManager/system-connections/bashclub.nmconnection, an die MAC gebunden) und keine automatischen Verbindungen für andere Karten. Später ändern: nmtui oder nmcli.
  • Benutzer: Name und Passwort (mindestens 8 Zeichen, gespeichert nur als SHA-512-Hash), mit sudo. Ohne SSH-Schlüssel darf sich der Benutzer per Passwort anmelden, bis es abgeschaltet wird (siehe „Nach der Installation“). root meldet sich nie per Passwort an.
  • Platten: Jede Platte erscheint einmal (lesbarster by-id-Name), Platten in Benutzung gar nicht; Pool-Namen und Labels vorhandener Inhalte sind sichtbar. Über der Auswahl steht, welches Layout bei welcher Anzahl entsteht; gibt es nur eines, wählt der Assistent es selbst, für den Boot-Pool nie RAIDZ. Belegte Platten löscht er nur nach Eintippen des Bestätigungsworts (z. B. LÖSCHEN, auch ohne Umlaut). Am Ende stehen Zusammenfassung und Plan.
• Installation:
  • Hostid.
  • Pools und Datasets nach Plan.
  • debootstrap der Suite.
  • Pakete: Kernel mit OpenZFS und unsere Pakete (siehe „Pakete“), shim, SSH. Was von uns kommt, schreibt der Installer nicht selbst, sondern installiert es als Paket; er schreibt nur, was zu dieser Installation gehört (Netz, Benutzer, Sprache, Paketquellen).
  • NetworkManager (DHCP oder fest, Ethernet oder WLAN; mit network.mac nur diese Karte, ohne Angaben DHCP auf allen Karten), ifupdown entfernt, Benutzer, SSH (siehe oben), Zeitzone, Tastatur, Locale, Konsolenschrift mit allen lateinischen Sonderzeichen.
  • Paketquellen: Debian main non-free-firmware, bashclub https://apt.bashclub.org/<kanal>/ (testing oder release, Standard: Kanal der ISO). Microcode passend zur CPU. Firmware für die im Live-System geladenen Treiber (modinfo -F firmware, Paket per dpkg -S), z. B. firmware-realtek für die Netzwerkkarte.
  • Jede ESP des Boot-Pools richtet bashclub-zbm-update --install aus bashclub-zfsbootmenu ein: shim + signiertes ZFSBootMenu (mit bashclub-Logo als Startbild) unter EFI/bashclub/ und als Rückfall unter EFI/BOOT/ (startet ohne NVRAM-Eintrag), je Platte ein UEFI-Booteintrag vorn in der Bootreihenfolge, für BIOS syslinux mit Kernel und initramfs von ZBM. Derselbe Weg aktualisiert die ESPs bei jedem Update des Pakets und behält den vorigen Stand als Rückfall.
  • Speichertest: signiertes memtest86+ hinter shim unter EFI/memtest/ mit UEFI-Eintrag „bashclub memtest“ (auch mit Secure Boot), aufrufbar auch aus dem Power-Menü von ZFSBootMenu (Strg+X); unter BIOS beim Start Umschalt halten und memtest eintippen.
  • Ruhiger Start (siehe unten): Plymouth-Theme bashclub (Logo, Fortschrittsbalken; Esc zeigt die Meldungen), Kommandozeile quiet splash loglevel=3 vt.global_cursor_default=0 auf <pool>/ROOT.
  • motd „bashclub OS“ (/etc/update-motd.d/20-bashclub) mit Hinweisen passend zur Firmware, beim Login erkannt: unter UEFI UEFI-Setup und Speichertest über ZFSBootMenu (Strg+X), unter BIOS der Speichertest über Umschalt; Secure Boot wird angezeigt. Solange SSH Passwörter annimmt, ein Kasten mit sudo bashclub-ssh-keyonly; Anmeldebildschirm der Konsole nur mit unserem Namenszug, Rechnername und IP-Adressen: /etc/issue ersetzt, Debians Fassung per dpkg-divert als /etc/issue.debian beiseitegelegt (Updates von base-files ohne Nachfrage).
  • WLAN: Auf Rechnern mit WLAN-Karte kommen wpasupplicant, wireless-regdb und iw mit (bei NetworkManager nur empfohlen, fehlten sonst), auch nach einer Installation per Kabel. Nachgerüstete Karte: sudo bashclub-wifi-setup erkennt sie über die Hardware-IDs (auch ohne Firmware), installiert Pakete und passende Firmware und lädt den Treiber neu; die motd weist darauf hin.
  • Shell: bash-completion (auch für root), Prompt und Farben (ls, grep, ip, newt-Programme wie nmtui über NEWT_COLORS) in bashclub-Farben aus /etc/bashclub/bashrc, geladen am Ende von ~/.bashrc. Die Farben folgen dem Hintergrund des Terminals: BASHCLUB_THEME=dark|light, sonst COLORFGBG, sonst Abfrage per OSC 11 (0,3 s), auf der Linux-Konsole dunkel.
  • Alle Pools stehen in /etc/zfs/zpool.cache des neuen Systems und werden beim Start importiert.
  • Hooks pre_partition, post_install (im chroot) und first_boot (einmalige Unit).

Pakete

Alles, was von uns ins System kommt, ist ein Paket aus apt.bashclub.org und wird mit apt upgrade aktuell gehalten (ADR 0010). Jede Version trägt einen Build-Zähler (+b<n>), ein Neubau ist also immer ein Update.

Paket	Quelle	Inhalt
bashclub-zfs-kernel, openzfs-*	bashclub-zfs-kernel	Kernel mit signierten OpenZFS-Modulen, Userland
bashclub-zfsbootmenu	bashclub-zfsbootmenu	ZFSBootMenu, Speichertest, shim auf allen ESPs (bashclub-zbm-update), voriger Stand als Rückfall
bashclub-base	hier (packages/)	Kernel-Zeile des ruhigen Starts für bestehende Systeme (/usr/lib/bashclub/quiet-boot, einmal), Cursor für Anmeldung und Notfall-Shell, motd mit Hinweisen, bashclub-ssh-keyonly, bashclub-mok-enroll, bashclub-wifi-setup, /etc/bashclub/bashrc, MOK-Zertifikat; Texte in allen Sprachen des Installers, gewählt zur Laufzeit (LANG der Sitzung, sonst /etc/default/locale)
bashclub-branding-default	hier	Name der Marke (/usr/share/bashclub/branding.sh), /etc/issue (Diversion von Debians Fassung), Plymouth-Theme, Desktop-Theme bashclub-theme (siehe unten); Provides bashclub-branding, havora-branding ersetzt es
bashclub-archive-keyring	hier	Schlüssel von apt.bashclub.org, damit ein Schlüsselwechsel per apt kommt
bashclub-boot-env	hier (packages/bashclub-boot-env/)	bashclub-be: Snapshot des laufenden Boot Environments vor jedem dpkg-Lauf (APT-Hook, @apt-<datum>, Aufbewahrung KEEP_APT in /etc/bashclub/boot-env.conf), list, prune, Reboot-Guard check-reboot (jeder Kernel mit ZFS-Modul im initramfs, ZFSBootMenu auf einer ESP), Sperre für Kernel ohne ZFS-Modul (apt-Pin für rt/cloud, APT-Hook apt-check für jeden anderen; KERNEL_GUARD), Probe-Boot mit Rückfall bei jedem Neustart (siehe unten)
bashclub-updates	hier (packages/bashclub-updates/)	automatische Updates (unattended-upgrades für Debian und apt.bashclub.org, needrestart startet Dienste neu), standardmäßig stündlich (UPDATE_CALENDAR=hourly, täglich zu einer Uhrzeit möglich); Neustart nur wenn nötig (neuer Kernel, /run/reboot-required): window (feste Uhrzeit, Standard 04:30; ist gerade jemand aktiv, alle 15 min erneut bis REBOOT_WINDOW, 2 h), asap oder never, immer über Reboot-Guard und Probe-Boot. Erweiterbar (ADR 0021 in freehold-docs): Skripte in busy.d/ melden Aktivität (Rückgabe ≠ 0, letzte Zeile = Grund) und halten den Neustart auf, notify.d/ bekommt Ankündigungen (planned, postponed, deadline-soon 24 h vor Ablauf der Frist, deadline, reboot), jeweils unter /usr/lib/bashclub-updates/ und /etc/bashclub/; bashclub-updates postpone 2h verschiebt, bashclub-updates now startet sofort neu. Nach der Frist REBOOT_DEADLINE (7 Tage ab „Neustart nötig“) zählen Verschieben und busy.d nicht mehr. Einstellungen /etc/bashclub/updates.conf, `bashclub-updates apply
bashclub-os (Metapaket, Name = BASE_SLUG aus product.env)	hier	hängt von bashclub-base, bashclub-boot-env, bashclub-updates, bashclub-zfsbootmenu und bashclub-zfs-kernel ab; bashclub-debian (Name bis 2026-10-25) ist ein Übergangspaket darauf; neue Bausteine kommen als weitere Abhängigkeit mit apt upgrade (nicht apt-get upgrade, das hält Pakete mit neuen Abhängigkeiten zurück)

Ruhiger Start

Solange der Start in Ordnung ist, steht durchgehend das Logo da: erst das Startbild von ZFSBootMenu mit „Press Esc for boot menu“ (ohne Countdown und Meldungen, siehe README von bashclub-zfsbootmenu), dann Plymouth mit Fortschrittsbalken. Dazwischen, beim Wechsel per kexec, zeigt der Kernel des Systems etwa 1 s eine schwarze Fläche (Debians Kernel übernimmt die Konsole sofort; ohne Text und Cursor). Beim Beenden von Plymouth stehen für etwa 0,1 s zwei Statuszeilen von systemd auf dem Schirm, dann die Anmeldung.

Taste	Wann	Wirkung
Esc	Startbild von ZFSBootMenu (Esc halten oder mehrmals drücken)	Menü von ZFSBootMenu: Boot Environments, Snapshots, Kernel, Kernel-Zeile, Notfall-Shell
Alt+F2	Startbild von ZFSBootMenu	ZFSBootMenu von Hand sichtbar machen (läuft auf tty2)
Esc	Plymouth	Meldungen des Starts statt Logo (noch einmal Esc: zurück)

Kernel-Zeile (org.zfsbootmenu:commandline auf <pool>/ROOT, gilt für alle Boot Environments ohne eigenen Wert):

Parameter	Wirkung
quiet, loglevel=3	keine Kernelmeldungen außer kritischen (quiet allein zeigt Fehler wie pci_bus … failed, die Debian nicht ausblendet)
splash	Plymouth, früh aus dem initramfs (FRAMEBUFFER=y im Branding-Paket)
vt.global_cursor_default=0	kein blinkender Cursor zwischen ZFSBootMenu und Plymouth; für Anmeldung (getty@), emergency und rescue schalten Drop-ins von bashclub-base ihn wieder ein

Mit quiet meldet systemd nur fehlgeschlagene Units (systemd.show_status=error). Nicht nötig sind rd.udev.log_level=3 bzw. udev.log_level=3 (udev meldet ohnehin nur Fehler, im Test kein Unterschied). Bewusst nicht gesetzt ist systemd.show_status=auto: Dauert ein Dienst beim Start länger (z. B. NetworkManager-wait-online), schaltet es die Statuszeilen ein, und nach Plymouth blitzten „[ OK ] Finished …“-Zeilen auf. Hängende Starts sieht man mit Esc unter Plymouth, Fehler und Notfall-Shell ohnehin.

Neue Installationen bekommen die Zeile vom Installer. Bestehende Systeme ergänzt bashclub-base beim Update einmal (/usr/lib/bashclub/quiet-boot): Fehlende Parameter kommen dazu, vorhandene bleiben (auch eigene Werte wie loglevel=7; nosplash verhindert splash), ebenso auf jedem Boot Environment mit eigenem Wert. Danach steht org.bashclub:quiet-boot=1 auf <pool>/ROOT, und es wird nichts mehr ergänzt: Wer Parameter entfernt, behält das. Erneut ergänzen: sudo /usr/lib/bashclub/quiet-boot --force. Den ruhigen Start abschalten: sudo zfs set org.zfsbootmenu:commandline="<zeile ohne quiet splash>" rpool/ROOT; einmalig im ZBM-Menü (Esc, dann Strg+E die Kernel-Zeile bearbeiten).

Immer sichtbar, auch beim ruhigen Start:

• Rückfall des Probe-Boots: ZFSBootMenu meldet „Probe boot of … failed. Starting previous boot environment …“ 9 s lang (Enter startet sofort, Esc öffnet das Menü); im System danach motd, Anmeldebildschirm und Checkmk (siehe bashclub-be).
• Passphrase und Fragen (systemd-ask-password, cryptsetup, zfs load-key): das Plymouth-Theme zeigt Frage und Eingabe unter dem Balken; Passphrasen in ZFSBootMenu zeigt ZBM selbst.
• Emergency- und Rescue-Mode, den Start blockierende Fehler: systemd beendet Plymouth und zeigt die Notfall-Shell bzw. ihre Meldung (z. B. eine nicht einhängbare Platte aus /etc/fstab nach dem Gerät-Timeout); Meldungen von Plymouth (plymouth display-message, z. B. fsck) stehen unter dem Balken.
• Fehler in ZFSBootMenu (Pool nicht importierbar, kein Kernel, Notfall-Shell): ZBM wechselt auf seine Konsole.

Bauen: MOK_CERT=<zertifikat.der> packages/build.sh trixie <ausgabe> (Inhalt aus bashclub_install/system.py). Die CI baut sie vor der ISO, testet sie mit der ISO auf den VMs und veröffentlicht sie danach.

Desktop-Theme: bashclub-branding-default bringt das Theme bashclub-theme im Aufbau von Debians desktop-base (/usr/share/desktop-base/bashclub-theme/{wallpaper,lockscreen,login}, GNOME-XML, metadata.json für KDE, Bilder 3840×2160, 3840×2400, 5120×2160) und trägt es mit Priorität 80 in dessen Alternativen ein (desktop-theme, desktop-background, desktop-background.xml, desktop-lockscreen.xml, desktop-plasma5-wallpaper, desktop-login-background; desktop-base nutzt höchstens 70). Das wirkt auch, wenn desktop-base erst später installiert wird; Server brauchen weder desktop-base noch Desktop-Pakete. Ein gschema-Override (20_bashclub.gschema.override) setzt GNOME ohne desktop-base auf dieselben Links. Zurück zu Debians Theme: update-alternatives --config desktop-theme usw. Die Hintergründe („Prompt“) erzeugt iso/branding/wallpaper.py beim Paketbau (SVG, gerendert mit rsvg-convert); Mechanik für alle Brandings (auch die Diversion von /etc/issue) in packages/branding/: build-theme.sh beim Bau, maintscript.sh in preinst/postinst/postrm über die Zeile #BRANDING#.

Installationen aus Prototyp-ISOs bis Oktober 2026 haben diese Dateien noch ohne Paket. Einmal sudo apt update && sudo apt install bashclub-os (das Metapaket): Die Pakete übernehmen die Dateien (auch die lokale Diversion von /etc/issue), entfernen die alten Befehle aus /usr/local/sbin und bringen ZFSBootMenu auf alle ESPs; der bisherige ZBM-Stand bleibt als Booteintrag „bashclub (vorige Version)“.

Nach der Installation

1. SSH-Schlüssel hinterlegen (vom eigenen Rechner): ssh-copy-id <benutzer>@<server>, danach mit dem Schlüssel anmelden.
2. Passwort-Anmeldung per SSH abschalten (bewusst nicht automatisch; die motd zeigt einen Hinweis, bis es erledigt ist): sudo bashclub-ssh-keyonly. Der Befehl verweigert, solange kein Schlüssel hinterlegt ist (sonst sperrte man sich aus; --force übergeht das), prüft die Konfiguration mit sshd -t und lädt sshd neu. Danach mit dem Schlüssel neu anmelden, bevor die alte Sitzung geschlossen wird.
3. Netz ändern: sudo nmtui (Menü) oder nmcli (z. B. nmcli connection show, nmcli device wifi list). Die Installation legt eine Verbindung bashclub an der gewählten Karte an.
4. Secure Boot: Wurde der bashclub-Schlüssel im Installer eingeschrieben, ist nichts weiter zu tun; mokutil --sb-state zeigt den Stand.
5. UEFI-Setup: im ZFSBootMenu Strg+X (Power-Menü) → „Reboot to UEFI Firmware“. Speichertest: ebenda „Speichertest / Memory test“ oder Booteintrag „bashclub memtest“ im Bootmenü der Firmware; unter BIOS beim Start Umschalt halten und memtest eintippen.

Beispiel: Boot-Pool als Mirror auf zwei NVMe, Datenpool RAIDZ2 auf sechs Festplatten.

version: 1
hostname: server
updates:
  auto: true          # täglich automatisch installieren (Pflichtangabe)
  time: "04:00"
  reboot: window      # window | asap | never – nur wenn nötig, mit Probe-Boot
  reboot_time: "04:30"
pools:
  - name: rpool
    boot: true
    layout: mirror
    disks: [/dev/disk/by-id/nvme-A, /dev/disk/by-id/nvme-B]
  - name: tank
    layout: raidz2
    disks: [/dev/disk/by-id/ata-1, /dev/disk/by-id/ata-2, /dev/disk/by-id/ata-3,
            /dev/disk/by-id/ata-4, /dev/disk/by-id/ata-5, /dev/disk/by-id/ata-6]

Schema: schema/install.schema.json. Standardwerte: suite: trixie, language: de, country: DE (daraus timezone, keyboard, locale), esp_size: 2G, firmware: uefi+bios, ashift: 12, Kompression zstd. updates ist Pflicht (auch der Assistent fragt es immer ab); später ändern in /etc/bashclub/updates.conf, dann bashclub-updates apply. Zugang über users (Name, password_hash aus openssl passwd -6, optional Schlüssel) oder ssh_authorized_keys für root; eins von beiden ist Pflicht. WLAN in der Antwortdatei: network: {wifi: {ssid: Heim, psk: <64 Hex-Zeichen aus wpa_passphrase Heim passwort>}}.

• Layouts:

  Layout	Platten	Boot-Pool erlaubt
  single	1	ja
  mirror	≥ 2	ja
  raid10	gestreifte Mirrors, Breite width (Standard 2), Vielfaches davon, ≥ 2 Mirrors	ja
  raidz1	≥ 3	nein, nur Datenpools
  raidz2	≥ 4	nein, nur Datenpools
  raidz3	≥ 5	nein, nur Datenpools

• Boot-Pool (genau einer): Jede Platte bekommt eine ESP (esp_size, FAT32, für BIOS mit „legacy BIOS bootable“) und eine ZFS-Partition. Fällt eine Platte aus, startet der Server von einer anderen. Boot Environments unter <pool>/ROOT/<name>, bootfs zeigt auf das aktive. Außerhalb der Boot Environments liegen <pool>/home (/home), <pool>/home/root (/root), <pool>/var/log und <pool>/var/lib/containers: Ein Rückfall auf einen älteren Stand setzt das System zurück, nicht Benutzerdaten, Logs und Container. Hat ein Datenpool denselben Mountpoint, übernimmt er ihn.

• Datenpools: ganze Platten, eingehängt unter mountpoint (Standard /<name>).

• Prüfungen vor jedem Schreibzugriff:

  • Plattenzahl passt zum Layout.
  • Keine Platte in zwei Pools, verglichen über das echte Gerät, denn eine Platte hat mehrere by-id-Namen.
  • Platten nur über /dev/disk/by-id.
  • Warnung bei unterschiedlich großen Platten.
  • Belegte Platten nur mit wipe: true.

• Nie gelöscht werden Platten in Benutzung, auch nicht mit wipe: true: eingehängte Partitionen (auch über LVM, LUKS, md), Swap, Platten in importierten ZFS-Pools, das Installationsmedium.

Boot Environments und Neustart (bashclub-be)

• Vor jedem apt-Lauf ein Snapshot des laufenden BE (@apt-<datum>), die letzten KEEP_APT bleiben (/etc/bashclub/boot-env.conf). bashclub-be list zeigt BEs und Snapshots; zurück geht es im Bootmenü (Strg+S am BE).
• Probe-Boot bei jedem Neustart, egal ob reboot, Ausschalten oder unattended-upgrades: Hat sich seit dem Start etwas geändert (Snapshot dieses Starts), bereitet das Herunterfahren (bashclub-be-prepare.service) die Probe vor. bashclub-be reboot startet zusätzlich nur neu, wenn der Reboot-Guard zustimmt (startet der neueste Kernel mit ZFS? auch einzeln bashclub-be check-reboot). Der Stand, mit dem das System gestartet ist, wird als <pool>/ROOT/fallback-<datum> geklont und bootfs; das aktualisierte BE startet einmal zur Probe. Erst wenn es hochkommt (bashclub-be-confirm.service), wird es wieder bootfs, und das Rückfall-BE wird gelöscht: Zurück auf einen früheren Stand geht es danach über die Snapshots (im ZBM-Menü Strg+S). Bei Kernel-Panic (panic=10), Hänger (Hardware-Watchdog; Fenster WATCHDOG_SEC=auto: dreifache gemessene Startdauer der letzten 5 Starts, 120–900 s, ohne Messung 600 s, höchstens das Maximum des Watchdog-Chips; fester Wert möglich) oder Reset startet beim nächsten Mal der vorige Stand; den Fehlschlag melden bis zum Quittieren (bashclub-be ack) ein roter Kasten in der Begrüßung (motd), eine Zeile auf dem Anmeldebildschirm der Konsole (/etc/issue.d), der Checkmk-Local-Check „Boot Environment“ (CRIT; WARN, solange der Reboot-Guard sperrt) und die gescheiterte Unit; Details in /var/lib/bashclub-be/probe-failed und bashclub-be status.
• Der Zustand liegt als bashclub/probe auf jeder ESP, die Hooks in ZFSBootMenu (bashclub-zfsbootmenu) werten ihn aus – unter UEFI und BIOS gleich. Ohne Hardware-Watchdog fängt nur panic=10; ein Hänger ohne Panic braucht dann den Reset von außen.
• Bestätigung erst mit Netz: Bevor bashclub-be-confirm.service bestätigt, laufen die Prüfungen aus /usr/lib/bashclub-be/probe-check.d/ und /etc/bashclub/probe-check.d/ (eigene ergänzen; gleicher Name in /etc ersetzt, Link auf /dev/null schaltet ab). Mitgeliefert: 10-network (Default-Route, Gateway antwortet per Ping oder als Nachbar). Der Watchdog ist dann schon aus; die Prüfungen laufen alle 10 s bis PROBE_CHECK_WAIT (auto: dreifache Startdauer, 120–300 s; oder fester Wert). Bestehen sie bis dahin nicht, startet der Server ins Rückfall-BE neu, der Grund steht in der Rückfall-Meldung. Geräte, die nach dem Start oft kein Netz haben (Laptop): PROBE_CHECKS=no. Im laufenden Betrieb gibt es keine solche Prüfung: Fällt dort das Netz weg, startet nichts neu (Meldung über Monitoring).
• PROBE=no schaltet den Probe-Boot ab, bashclub-be reboot --no-probe einmalig.

ISO

CHANNEL=testing MOK_CERT=<mok.der> APT_PROXY=http://10.91.0.20:3142 iso/build.sh trixie <debs> <out>

live-build im Container debian:<suite>; <debs>: alle unsere Pakete (Kernel und OpenZFS, bashclub-zfsbootmenu bzw. das Paket aus ZBM_PACKAGE, die aus packages/build.sh). Name, Branding und Zusätze aus product.env, für abgeleitete Produkte siehe „Ableiten“. Ergebnis bashclub-os-<suite>-<kanal>-<version>-<datum>-<uhrzeit UTC>-amd64.iso (UEFI und BIOS, Secure Boot über Debians shim).

• Bootmenü im bashclub-Design: Installieren (Deutsch, Standard nach 5 s), Install (English), Grafik-Kompatibilitätsmodus (nomodeset), Speichertest (memtest86+), unter UEFI Firmware-Einstellungen.
• Live-System: unser Kernel mit OpenZFS, Netz per DHCP; auf tty1 startet der Assistent in den Markenfarben, auf tty2–6 eine Konsole (user/live). Vorhandene Pools werden nicht importiert oder eingehängt, bis die Installation bestätigt ist.
• Unbeaufsichtigt: bashclub.config=<URL> auf der Kernel-Befehlszeile lädt die Antwortdatei, installiert und schaltet aus.
• Secure Boot: Unser ZFS-Modul lädt erst, wenn der bashclub-Schlüssel eingeschrieben ist. Ist Secure Boot an und der Schlüssel fehlt, bietet der Installer vor dem Assistenten an, ihn vorzumerken (mokutil --import). Danach startet der Rechner in den MokManager: Enroll MOK → Continue → Yes → Passwort bashclub → Reboot. Das Zertifikat (MOK_CERT beim Build) liegt unter /usr/share/bashclub-install/mok.der; MokManager (mmx64.efi) ergänzt der Hook 9100-mokmanager, live-build legt ihn nicht ab.
• Konsolen: tty1 Installer, tty2–6 und seriell (ttyS0, 115200) Anmeldung als user / live mit sudo.
• Uhrzeit und Paketquellen: Die Installation stellt die Uhr per NTP (systemd-timesyncd) und schreibt sie in die Hardware-Uhr (hwclock --systohc). Mit falscher Uhr (leere CMOS-Batterie) lehnt apt die Signaturen ab; der Assistent warnt deshalb schon bei der Netzprüfung, wenn die Uhr nicht gestellt werden kann. Den Schlüssel des bashclub-Repos lädt der Installer per HTTPS von https://apt.bashclub.org/gpg/bashclub.pub, ohne Netz nimmt er den von der ISO.

Secure Boot: bashclub-Schlüssel einschreiben

Unser ZFS-Modul und ZFSBootMenu sind mit dem bashclub-Schlüssel signiert. Pflicht: Unter UEFI mit shim schreibt der Installer ihn immer ein, auch wenn Secure Boot gerade aus oder im Setup Mode ist; sonst startet das System nicht mehr, sobald Secure Boot später eingeschaltet wird (z. B. BIOS auf Werkseinstellungen). Ohne Schlüssel wird nicht installiert; nur ohne shim im Startweg (MokListRT fehlt) gibt es eine Warnung. Die unbeaufsichtigte Installation merkt den Schlüssel vor. Im installierten System liegt das Zertifikat unter /usr/share/bashclub/mok.der; sudo bashclub-mok-enroll merkt es vor, und die motd zeigt einen Hinweis, solange es unter UEFI fehlt. Einschreiben heißt: einmal je Rechner im MokManager bestätigen (Passwort beim Vormerken: bashclub). Drei Wege, auch beim Start über Ventoy:

1. Im Installer (Standard): Ist Secure Boot an und der Schlüssel fehlt, fragt der Installer „Jetzt einschreiben?“ → Ja. Der Rechner startet neu; der blaue MokManager erscheint (bei Ventoy aus dessen shim, das funktioniert genauso): Enroll MOK → Continue → Yes → Passwort bashclub → Reboot. Danach die ISO erneut starten.
2. Aus dem Bootmenü der ISO: Eintrag „bashclub-Schlüssel einschreiben (Secure Boot, MokManager)“. Das Live-System merkt den Schlüssel ohne weitere Frage vor und startet neu; shim zeigt dann den MokManager wie bei Weg 1. (Aus GRUB direkt gestartet, zeichnete MokManager im Grafikmodus von GRUB nur einen kaputten Bildschirm.)
3. Von Hand, falls nach dem Neustart kein MokManager erscheint: bashclub-mok.der (liegt im ISO unter EFI/boot/, im Testnetz auch unter http://192.168.200.138/bashclub-mok.der) auf die kleine FAT-Partition VTOYEFI des Ventoy-Sticks oder einen beliebigen FAT-formatierten Stick kopieren. Beim Start „Enroll key from disk“ im MokManager wählen (den Ventoy beim ersten Start mit Secure Boot ohnehin zeigt) und die Datei auswählen. MokManager liest nur FAT, nicht exFAT/NTFS.

Prüfen: mokutil --test-key /usr/share/bashclub-install/mok.der im Live-System (Alt+F2) meldet „is already enrolled“. Secure Boot auszuschalten geht natürlich auch.

Ableiten: ein Produkt auf bashclub OS

Ein anderes Produkt (eigener Name, eigenes Branding, eigene Pakete) baut seine ISO mit iso/build.sh aus diesem Repo, ohne Kopie und ohne Patch. Alle Haken sind optional; ohne sie entsteht bashclub OS wie bisher.

PRODUCT_ENV=<produkt>/product.env EXTRA_DEBS=<produkt>/debs INSTALL_DEFAULTS=<produkt>/defaults.d \
  CHANNEL=testing MOK_CERT=<mok.der> iso/build.sh trixie <debs> <out>

Haken	Wirkung
PRODUCT_ENV	eigene product.env, gilt über der des Repos: Sie setzt nur, was sich ändert (spätere Zuweisung gilt, wie beim Einlesen mit der Shell). Pfade darin relativ zu ihr. Auf der ISO stehen beide hintereinander in /usr/share/bashclub-install/product.env.
PRODUCT_NAME, PRODUCT_TAGLINE, PRODUCT_SLUG, PRODUCT_VOLUME	Anzeigename (Installer, Bootmenü, Splash), ISO-Dateiname, Volume
BASE_SLUG	Metapaket der Basis, getrennt von PRODUCT_SLUG: Ein abgeleitetes Produkt behält bashclub-os (Kernel, ZFSBootMenu, Boot Environments, Updates kommen weiter darüber) und bringt seine Pakete dazu
ZBM_PACKAGE	ZFSBootMenu-Paket, Standard bashclub-zfsbootmenu; das Paket einer anderen Marke aus bashclub-zfsbootmenu (BRAND=…, eigenes Startbild und Farben) ersetzt es mit denselben Pfaden und derselben Update-Logik. Es muss in <debs> liegen; andere *-zfsbootmenu dort kommen nicht auf die ISO.
EXTRA_DEBS (Bau)	Verzeichnis mit Paketen; auf der ISO unter /usr/share/bashclub-install/extra-packages/, der Installer installiert sie nach den eigenen in einem eigenen Schritt (sie dürfen z. B. bashclub-branding-default ersetzen)
EXTRA_PACKAGES	weitere Pakete aus den Paketquellen, im selben Schritt
INSTALL_DEFAULTS (Bau)	*.yaml nach /usr/share/bashclub-install/defaults.d/: Voreinstellungen für jede Installation (Assistent und Antwortdatei). Zuordnungen werden zusammengeführt, alles andere (Werte, Listen wie hooks.post_install) aus der Antwortdatei gewinnt; Dateien alphabetisch, spätere gewinnen. Fehler darin meldet die Prüfung als defaults.d/<datei>. Statt das Schema zu ändern.
INSTALL_DEFAULTS: *.debconf	Vorbelegungen für debconf im Format von debconf-set-selections (<paket> <frage> <typ> <wert>, # Kommentar), auf der ISO ebenfalls unter defaults.d/. Der Installer spielt sie im Ziel ein (alphabetisch), bevor er die Zusatzpakete (EXTRA_DEBS, EXTRA_PACKAGES) installiert; so sehen deren Maintainer-Skripte sie schon bei der ersten Installation. Beispiel: ein Upstream-Paket, dessen postinst ohne Vorbelegung einen Dienst anmeldet: paket paket/anmelden boolean false. Fehler (Zeile mit weniger als drei Feldern, unbekannter Typ, boolean/seen nicht true/false) meldet die Prüfung als defaults.d/<datei>:<zeile>.
ISO_SPLASH, ACCENT_COLOR	Splash des Bootmenüs (SVG 640×480, Platzhalter @PRODUCT_NAME@ und die von live-build), Akzentfarbe für Auswahl und Fortschritt (GRUB, isolinux)
INSTALLER_LOGO, INSTALLER_BACKTITLE, INSTALLER_NEWT_COLORS, CONSOLE_PALETTE	Kopf des Assistenten: Bildmarke als Textgrafik (\n trennt Zeilen, @PRODUCT_NAME@), Zeile oben links, whiptail-Farben und die Konsolenpalette, die die Markenfarben auf die Farbnamen von whiptail legt (<index>=<rrggbb>)
/usr/share/bashclub/branding.sh (Branding-Paket, ersetzt bashclub-branding-default)	Begrüßung im installierten System: BRAND_NAME, BRAND_ACCENT und BRAND_ERROR (SGR-Parameter, z. B. 38;5;222), Bildmarke BRAND_LOGO_1–3 (@A@ Akzent, @R@ zurücksetzen), BRAND_SSH_HINT=no (kein Kasten „sudo bashclub-ssh-keyonly“, wenn das Produkt SSH selbst regelt). Ohne Angabe gelten die bashclub-Werte.
ISO_PUBLISHER, SOURCES_URL	Herausgeber im ISO-Kopf, Adresse des Quellcode-Manifests in SOURCES.txt (@CHANNEL@, @ISO@)

Was bleibt: Paketquelle apt.bashclub.org und ihr Schlüssel, der MOK-Schlüssel (ein abgeleitetes ZBM-Image wird mit demselben signiert, ein Wechsel braucht keine neue MOK-Bestätigung), die Pakete bashclub-* und /etc/bashclub/.

Ruhiger Start in einem abgeleiteten Produkt: Kernel-Zeile, Migration und Cursor kommen unverändert aus bashclub-base. Ein eigenes Plymouth-Theme (Script-Modul) muss wie plymouth/bashclub.script Passphrasen, Fragen und Meldungen zeichnen (SetDisplayPasswordFunction, SetDisplayQuestionFunction, SetMessageFunction), sonst sähe niemand eine Abfrage beim Start.

Tests

test/install-vm.sh (Proxmox der Sandbox, frische VM mit UEFI ohne Secure Boot): Installation Mirror-Boot-Pool + RAIDZ1-Datenpool, Start vom Mirror (Root, Kernel, ZFS 2.4.4, Pools ONLINE, Datenpool eingehängt, SSH nur mit Schlüssel, Booteinträge je Platte), Ausfall der ersten Boot-Platte (Start von der zweiten), BIOS über syslinux. Stand 2026-10-23: alle 15 Prüfungen grün. Unterwegs gefunden: Datenpools wurden beim Start nicht importiert (zfs-import-scan läuft nur ohne Cache-Datei) → Pools stehen jetzt in zpool.cache.

tests/run-in-container.sh        # pyflakes, shellcheck, pytest in debian:$SUITE (Standard trixie)

Geprüft auf einer Proxmox-VM mit sieben Platten (Sandbox, 2026-10-23): Erkennung mit by-id, Plan für Mirror + RAIDZ2; die laufende Systemplatte (/, /boot/efi) und eine Platte in einem importierten Pool werden auch mit wipe: true abgelehnt. Der erste Versuch hatte die Systemplatte nur als „belegt“ erkannt: lsblk -J liefert ohne die Spalte NAME eine flache Liste, die Zuordnung läuft jetzt über PKNAME.

test/secureboot-vm.sh (frische VM, OVMF mit Microsoft-Schlüsseln, Secure Boot an): Der Testschlüssel wird per MokManager eingeschrieben, test/mokenroll.py bedient ihn über die serielle Konsole. Danach lädt das signierte OpenZFS-Modul im Live-System, und die Installation läuft durch (Mirror). Das installierte System startet über shim → ZFSBootMenu (MOK) → kexec Debian-Kernel → ZFS-Modul (MOK), mit Lockdown. Ohne NVRAM-Einträge startet es über EFI/BOOT/BOOTX64.EFI. Stand 2026-10-23: alle 13 Prüfungen grün. Hinweis: Ein zusätzlich installiertes zfs-dkms überdeckt die signierten Module (updates/dkms hat Vorrang); das Metapaket bashclub-zfs-kernel schließt es deshalb aus.

iso/test-vm.sh <iso> (Proxmox der Sandbox; ONLY=start|secureboot|network nur der jeweilige Teil):

1. Start von der ISO unter UEFI (GRUB) und BIOS (isolinux): Bildschirmfotos von Bootmenü und Assistent; geprüft wird, dass der Assistent in den Markenfarben als zusammenhängende Fläche erscheint (nicht zerrissen, kein Bootmenü, keine Fehlermeldung).
2. Unbeaufsichtigt unter UEFI und BIOS (Kernel direkt, bashclub.config=<URL>): Installation endet mit Ausschalten, Start von den Platten, Root auf ZFS im Mirror, signiertes Modul, Land DE → Europe/Berlin, Tastatur de, Locale de_DE, Benutzer mit sudo und Passwort, feste Adresse an der MAC, Paketquellen mit apt update.
3. Secure Boot ohne bashclub-Schlüssel (ONLY=secureboot): Frage im Assistenten, Bestätigung, MokManager (test/mokenroll.py über die serielle Konsole), nach dem Neustart Anmeldung über die serielle Konsole (test/serial-run.py): Schlüssel eingeschrieben, ZFS-Modul geladen.
4. Netz im Live-System (ONLY=network, test/live-network.py) mit NetworkManager: DHCP-Werte gelesen, feste Adresse gesetzt, erreichbar und stabil, Rückkehr zu DHCP; WLAN gegen einen simulierten Access Point (mac80211_hwsim, hostapd, WPA2): Suche, falsches Passwort gemeldet, richtiges verbindet, Ethernet dabei getrennt.

Ruhiger Start (Teile 2, 6, 7): Kernel-Zeile, Marke org.bashclub:quiet-boot, Plymouth-Theme im initramfs und Cursor-Drop-ins nach der Installation; unter UEFI öffnet Esc (erst wenn das Startbild steht, sonst öffnete es das UEFI-Setup) das ZBM-Menü, Enter startet weiter; nach dem Update einer vorigen Installation ist die Kernel-Zeile ergänzt und ein eigener Wert (loglevel=7) geblieben; beim Rückfall nach Kernel-Panic steht der Hinweis von ZFSBootMenu auf dem Schirm (Bildschirmfoto). Stand 2026-10-28: alle Prüfungen der Teile 2, 6 und 7 grün; dazu von Hand Bildfolgen des Neustarts (Bildschirmfoto alle 0,1 s per QMP), Passphrase unter Plymouth (systemd-ask-password), Emergency-Mode durch eine nicht einhängbare Platte in /etc/fstab, Esc unter Plymouth. Bekannt: Beim Beenden von Plymouth blitzen für etwa 0,1 s die Statuszeilen der letzten beiden Units („[ OK ] Finished plymouth-quit …“) auf, auch mit systemd.show_status=false; danach kommt die Anmeldung.

Stand 2026-10-24: alle Prüfungen grün. Unterwegs gefunden: Das Live-System blieb nach poweroff.target stehen (jetzt sysrq nach der Installation); live-media-timeout=60 verhinderte die Suche nach dem Medium ganz (live-boot beginnt die Suche erst nach dieser Zeit, sucht aber nur 60 s); noprompt gegen „Medium entfernen“.

Lizenz

GPL-3.0-or-later (LICENSE).