bashclub-zfs-kernel

Debian-Kernel mit dazu gebauten, für Secure Boot signierten OpenZFS-Modulen, für Debian 13 (trixie). Teil der bashclub-Basis für „bashclub OS“ (bashclub-os, ZFSBootMenu aus bashclub-zfsbootmenu); genutzt u. a. von Freehold Office.

Warum

Debian liefert ZFS als DKMS-Quellen: Die Module entstehen erst auf dem Server, nach jedem Kernel-Update. Scheitert der Bau oder passt die ZFS-Version nicht zum neuen Kernel, startet ein Root-auf-ZFS-System nicht mehr. Unter Secure Boot muss zudem jedes lokal gebaute Modul mit einem lokal eingeschriebenen Schlüssel signiert werden.

Dieses Paket dreht das um:

• Die Module werden vorab für genau einen Kernel-ABI gebaut, signiert und auf einer VM getestet (Boot, Pool, verschlüsselter raw send/recv).
• Das Metapaket bashclub-zfs-kernel ersetzt linux-image-amd64. Es hängt am Kernel-ABI und an genau diesen Modulen. Ein Kernel mit neuem ABI kommt erst auf die Server, wenn bashclub die Module dafür gebaut und getestet hat. Sicherheitsupdates mit gleichem ABI laufen durch, denn die Module passen weiter.
• Userland aus demselben OpenZFS-Tag (openzfs-zfsutils, -zfs-zed, -zfs-initramfs, Bibliotheken). Die Pakete verdrängen Debians zfsutils-linux und zfs-dkms.

Bauen

Mit Podman, in einem Container debian:<suite>. Der Bau-Rechner braucht nur Podman; neue Debian-Versionen wie forky brauchen nur eine andere Suite und deren Kernel-ABI:

keys.sh /root/keys                                   # NUR TEST: Signierschlüssel erzeugen
build.sh trixie 2.4.4 6.12.113+deb13-amd64 /root/keys /root/out

build-in-container.sh installiert die Build-Abhängigkeiten aus OpenZFS' eigener contrib/debian/control (mk-build-deps) und baut dann.

• Der Tarball wird gegen versions/zfs-<version>.sha256 geprüft (Wert aus der veröffentlichten zfs-<version>.sha256.asc).
• Grundlage ist der Paketbau von OpenZFS selbst (make native-deb-utils, make native-deb-kmod KVERS=…). Die Module signiert build.sh danach mit sign-file aus linux-kbuild passend zum Kernel.
• Versionen tragen die Debian-Hauptversion, damit Pakete mehrerer Suiten im selben apt-Repo nicht kollidieren: OpenZFS 2.4.4-1+deb13, Metapaket <Kernel-Paketversion>+zfs<OpenZFS-Version>+deb13, z. B. 6.12.113-1+zfs2.4.4+deb13.

Testen

test/vm.sh /root/out 2.4.4 6.12.113+deb13-amd64     # auf dem Proxmox-Host der Sandbox

Frische VM aus der Vorlage von freehold-vm (Debian 13 mit Debians zfs-dkms). Geprüft werden:

• Installation verdrängt linux-image-amd64 und Debians ZFS; apt full-upgrade will keinen anderen Kernel.
• Nach dem Neustart: richtiger Kernel, Modul und Userland in der gebauten Version, Modul mit dem bashclub-Schlüssel signiert.
• Pool anlegen, exportieren, importieren; verschlüsselter raw send/recv voll und inkrementell, Prüfsummen gleich, Scrub ohne Fehler.

Secure Boot (Modul lädt nur mit eingeschriebenem Schlüssel) prüft der Test von bashclub-zfsbootmenu.

Stand 2026-10-23 ✅: OpenZFS 2.4.4 für Kernel 6.12.113+deb13-amd64, im Container gebaut (4 vCPU: 7,5 min), alle Prüfungen von test/vm.sh grün (Sandbox, Proxmox).

Offen

• Upstream-Beitrag OpenZFS: contrib/debian/control braucht unter Debian 13 zusätzlich dh-dkms als Build-Abhängigkeit (das Addon liegt nicht mehr in dkms).
• CI auf Forgejo-Runnern: neuer Debian-Kernel → Bau → VM-Test → Freigabe im apt-Repo; arm64.
• Echte Signierschlüssel und ihre Verwahrung (bis dahin nur Testschlüssel).
• Rechtliche Bewertung vor der ersten öffentlichen Veröffentlichung: Auslieferung vorgebauter CDDL-Module zum GPL-2-Kernel (Debian liefert nur DKMS-Quellen, Ubuntu vorgebaute Module).

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). OpenZFS: CDDL-1.0.