platform-docs/adr/0009-anaconda-live-kickstart-verworfen.md

ADR-0009: Anaconda-Kickstart aus der laufenden Live-Sitzung heraus verworfen

Status: Beschlossen Datum: 23.07.2026

Kontext

13-live-provisioning-boot.md (Abschnitt "Nativer Installer aus der Live-Sitzung") legt fest, dass backend_launch() den nativen Installer explizit aus der bereits gebooteten Live-Sitzung heraus aufruft, mit der von backend_generate_config() erzeugten Kickstart-Datei. Für das Fedora-Backend hieße das: anaconda (bzw. liveinst) innerhalb der laufenden Cinnamon-Sitzung mit der generierten Kickstart-Datei starten.

Vor der Implementierung wurde recherchiert und real getestet, ob das funktioniert.

Untersuchung

Der liveinst-Wrapper (/usr/bin/liveinst, Teil des anaconda-Pakets) lehnt ks=/kickstart=-Argumente laut eigenem Quellcode aktiv ab und erzwingt stattdessen den interaktiven Modus — Zitat aus der Anaconda-Projektdokumentation: "anaconda developers really, really do not want to support kickstart from liveinst!". Auch die eigene anaconda --help-Ausgabe dokumentiert --kickstart KICKSTART_PATH explizit als "not supported for live installations".

Direkter Test am Wrapper vorbei (anaconda --liveinst --kickstart=<datei>, auf echtem Fedora 44 / Anaconda 44.30-2.fc44) bestätigte das empirisch, mit einer noch ungünstigeren Fehlerart als "klar abgelehnt":

• Mit -T (Text-Modus): Anaconda startet, übernimmt Sprache/Zeitzone/Partitionierungsart (autopart) korrekt aus der Kickstart-Datei, ignoriert aber rootpw und user kommentarlos — beide Felder mussten vollständig manuell nachgetragen werden ("Root-Konto ist deaktiviert", "Es wird kein Benutzer erstellt", trotz korrekter Kickstart-Zeilen). Kein Fehler, keine Warnung — nur eine leise, unvollständige Übernahme.
• Mit -C (Cmdline-Modus, laut Hilfetext für nicht-interaktive Automatisierung gedacht): sauberer, aber ebenso eindeutiger Abbruch, Exit-Code 1, mit explizitem Log-Eintrag:

  pyanaconda.errors.CmdlineError: Die folgenden obligatorischen Speichen sind nicht beendet:
  Installation Destination
  Root password
  User creation
  

  Anaconda selbst bewertet also autopart/rootpw/user aus der Kickstart-Datei als nicht abgeschlossen — trotz syntaktisch korrekter Angabe.

Der zusätzlich dokumentierte Flag --ks (ohne die "not supported for live"-Einschränkung im Hilfetext) erwies sich als Sackgasse: in dieser Anaconda-Version nimmt --ks in der direkten Kommandozeilen-Nutzung keinen Wert entgegen (error: argument --ks: ignored explicit argument) — die Beschreibung im Hilfetext bezieht sich vermutlich auf den inst.ks=-Boot-Parameter, nicht auf diesen CLI-Flag bei direktem Programmaufruf.

Entscheidung

Der native Installer wird nicht per Kickstart aus der laufenden Live-Sitzung heraus gestartet. Diese Umsetzung des in 13-live-provisioning-boot.md beschriebenen Modells ("Nativer Installer aus der Live-Sitzung") ist für das Fedora-Backend nicht tragfähig.

Ausdrücklich nicht gewählt: Anaconda umgehen und Partitionierung/Dateisystem/Bootloader selbst nachbauen (parted/mkfs/rsync/grub2-install) — zu hoher Wartungsaufwand, Verlust von Anacondas ausgereifter Partitionierungs-/Verschlüsselungs-/Secure-Boot-Logik.

Konsequenzen

• 13-live-provisioning-boot.md (Abschnitt "Nativer Installer aus der Live-Sitzung") muss überarbeitet werden, sobald der tatsächliche Weg feststeht — noch nicht Teil dieser Entscheidung.
• Betroffene Anaconda-Version zur Einordnung: 44.30-2.fc44 ("bluesky", Pre-Release, neue WebUI-basierte Oberfläche) — die "Kickstart auf Live-Medien nicht unterstützt"-Haltung selbst ist aber laut Anaconda-Projektdokumentation langjährig und nicht auf diese Version beschränkt.

Update (23.07.2026): Muster erkannt, verfeinerter Prüfplan

Weitere Recherche zeigt: das Problem ist nicht Fedora-spezifisch. Ubuntu/Subiquity (autoinstall) und Ubiquity (Preseed, älterer Mint-Installer) sind laut Dokumentation ebenfalls ausschließlich für eine Auslösung per Kernel-Boot-Parameter gebaut, nicht für einen Aufruf aus einer bereits laufenden Live-Sitzung heraus — dasselbe Muster wie bei Anaconda. Calamares (Basis einiger Mint-Editionen) hat dagegen unabhängig vom Zeitpunkt grundsätzlich keinen eingebauten unbeaufsichtigten Modus.

Daraus folgt ein vielversprechenderer Ansatz als ein Distro-Wechsel: zweistufiger Boot statt Aufruf aus der laufenden Sitzung. Die Live-Sitzung macht weiterhin alles wie bisher (Netzwerk, Hardware, Handshake, interaktive/Auto-Entscheidung), löst am Ende aber keinen direkten Installer-Aufruf mehr aus, sondern setzt den passenden Boot-Parameter (inst.ks=, autoinstall, Preseed-Äquivalent) für den nächsten Boot und startet neu. Der native Installer läuft dann in genau der Betriebsart, für die er gebaut ist — kein Live-Sitzungs-Umweg. Das würde bedeuten, dass Fedora/Anaconda eventuell gar nicht aufgegeben werden muss.

Offener Punkt dabei: das Medium ist laut WLAN-Autoprovisionierungs-Entscheidung (13-live-provisioning-boot.md) bewusst nicht dauerhaft beschreibbar — die generierte Konfigurationsdatei muss dem zweiten Boot also vermutlich über eine Server-URL zugestellt werden (inst.ks=https://..., passend zu ADR-0003), nicht über eine lokale Datei. Ob die frühe Dracut-Boot-Netzwerkumgebung dafür ausreicht (sie ist nicht dieselbe wie die volle NetworkManager-/WLAN-Konfiguration der laufenden Live-Sitzung), ist ungeklärt und Teil der folgenden Prüfschritte, nicht vorab gelöst.

Vereinbarter Prüfplan, in dieser Reihenfolge:

1. Klären, welchen Installer Linux Mint (Cinnamon) tatsächlich mitbringt (Ubiquity/Preseed oder Subiquity/Autoinstall) — die Seed-Daten (installer_type: 'autoinstall') sind dahingehend noch unbestätigt, evtl. falsch benannt.
2. Fedora + Kickstart per Reboot zuerst testen, nicht Distro wechseln — geringste Kosten, da ISO/VM/die gesamte Kiosk-Arbeit (Epiphany, Panel) erhalten bleiben, falls es funktioniert. Test: aus der laufenden Live-Sitzung heraus gezielt mit inst.ks=<URL> am Cmdline neu booten, beobachten ob Anaconda diesmal vollständig automatisiert durchläuft (inklusive der Zustellungsfrage oben).
3. Nur falls Schritt 2 scheitert: dasselbe Reboot-Muster mit dem in Schritt 1 geklärten Ubuntu/Mint-Mechanismus.
4. Nur falls auch das scheitert: die unten konkretisierte Ultima Ratio.

Update (29.–30.07.2026): Schritt 2 real getestet und gescheitert — direkter Wechsel zur Ultima Ratio

Schritt 2 (Fedora + Kickstart per Reboot) wurde real in einer Proxmox-VM getestet, nicht per Firmware-Reboot, sondern per kexec (siehe Begründung unten) — mit eindeutig negativem, aber sauber erklärbarem Ergebnis.

Testaufbau: kexec -l/kexec -e aus der laufenden Live-Sitzung heraus, um denselben Kernel mit neuer Kernel-Cmdline zu starten, ohne den Umweg über GRUB — das reguläre Live-Medium ist bewusst nicht dauerhaft beschreibbar, GRUB liest seine Config also bei jedem echten Reboot ohnehin nur wieder vom unveränderten Medium. kexec umgeht dieses Problem vollständig, da kein Firmware-/GRUB-Durchlauf nötig ist.

Versuch 1: root=live:CDLABEL=TUXFLOTTE rd.live.image ... inst.ks=file:/tuxflotte-ks.cfg (Kickstart-Datei direkt als zusätzliches cpio-Archiv ans Initrd angehängt). Ergebnis: kexec-Sprung fand nachweislich statt (kein Firmware-/GRUB-Screen, X-Server brach weg, neue Boot-Infozeilen), landete aber unverändert im normalen Live-Desktop (Epiphany) — inst.ks= wurde ignoriert.

Versuch 2: dieselbe Cmdline, aber Kickstart-Zustellung per inst.ks=https://... (bestehender Endpunkt auf anode, s.u.) statt per Initrd-Anhang, um eine mögliche Ursache (fehlerhafte cpio-Verkettung) auszuschließen. Vorher wurde tatsächlich ein Initrd-Verkettungsfehler beobachtet (initramfs unpacking failed: invalid magic at start of compressed archive — vermutlich weil das Basis-Initrd xz-/zstd-komprimiert ist und sich anders als ein Gzip-Initrd nicht einfach per cat verketten lässt); die Zustellung per HTTPS umgeht dieses Nebenproblem vollständig, ändert am Kernbefund aber nichts.

Versuch 3: inst.stage2=hd:LABEL=TUXFLOTTE:/ ... inst.ks=https://... ohne root=live/rd.live.image, in der Annahme, dass Letzteres Dracuts dmsquash-live-Pfad erzwingt und inst.ks= dabei grundsätzlich übergangen wird. Ergebnis: Dracut Emergency Shell, Warning: Can't mount root-filesystem — ohne root=live gab es gar keine auflösbare Root-Definition mehr, inst.stage2=hd:LABEL=... konnte sie nicht ersetzen.

Entscheidender Befund: lsinitrd /run/initramfs/live/boot/x86_64/loader/initrd | grep -i anaconda liefert keinen Treffer. Das anaconda-Dracut-Modul, das inst.ks=/inst.stage2= überhaupt erst auswerten und auf anaconda.service statt auf den normalen Live-Desktop umschalten würde, ist in diesem Initrd schlicht nicht enthalten. Das erklärt beide Fehlschläge ursächlich und einheitlich: keine Kombination von Boot-Parametern kann etwas bewirken, das im Initrd gar nicht als Auswertungslogik vorhanden ist. Dies ist keine Cmdline-Syntax-Frage, sondern eine strukturelle Eigenschaft des Fedora-Cinnamon-Live-Images (vermutlich, weil Live-Spins mit dmsquash-live gebaut werden, aber nicht zwangsläufig mit dem für Netinst-/DVD-Medien gedachten anaconda-Modul).

Entscheidung (30.07.2026): Schritt 3 (Mint/Ubuntu-Reboot-Test) wird bewusst ausgelassen, nicht aus Zeitmangel, sondern weil dieselbe strukturelle Ursache dort ebenfalls plausibel erscheint (Ubuntu-Desktop-Live-Images/Casper und Mint-Editionen bringen ihre unbeaufsichtigten Installationswege (Subiquity/Preseed) typischerweise auf einem separaten Server-/Netinst-Image, nicht im Desktop-Live-ISO) — diese Vermutung wurde nicht empirisch geprüft, ist aber Grundlage der Entscheidung, direkt zur unten stehenden Ultima Ratio überzugehen, statt einen strukturell vermutlich gleich ausgehenden Test zu wiederholen.

Nebenbefund ohne Bezug zum eigentlichen Test: Für die Zustellung in Versuch 2/3 wurde vorübergehend der bestehende, bereits produktiv genutzte Endpunkt https://anode.tuxflotte.de/installers/fedora-workstation/ks.cfg mit einer Testdatei überschrieben (Original gesichert unter ks.cfg.bak-2026-07-29) und muss vor einer erneuten Nutzung dieses Endpunkts wiederhergestellt werden.

Update (30.07.2026): Ultima Ratio, Schritt 1a real bestätigt

Erster kleinster Ausschnitt der Ultima Ratio (siehe unten) real getestet, nicht mit synthetischen Testwerten, sondern mit den tatsächlichen DB-Daten: POST /api/v1/activate mit dem echten Aktivierungscode LAB-2026-START gegen die laufende provisioning-server-Instanz auf anode, danach POST /api/v1/templates/{id}/resolve für die Fedora-Bereitstellungsvorlage (Schulcomputer (Fedora)) — liefert den echten runtime_blueprint mit den drei realen Blueprints (guest-session-ephemeral/guest-session, browser-brave/brave-fedora, office-onlyoffice/onlyoffice-fedora).

Dieser runtime_blueprint wurde mit derselben envsubst-Logik wie backend_generate_config() (nur serverseitig statt geräteseitig ausgeführt) in kickstart.tpl eingesetzt und testweise wieder über https://anode.tuxflotte.de/installers/fedora-workstation/ks.cfg ausgeliefert (Original erneut gesichert und danach wiederhergestellt). Boot-Medium diesmal ein reguläres Fedora-Netinstall-ISO (nicht das Live-/Cinnamon-Image), inst.ks=https://... klassisch über die GRUB-Bootzeile gesetzt — derselbe Weg, der schon beim Meilenstein vom 16.06.2026 funktioniert hat, jetzt aber mit aktuellem DB-Stand statt der alten config.json.

Ergebnis: vollautomatischer Durchlauf, Login danach funktioniert, rootpw/user vollständig übernommen — genau der Fehler, an dem die live-Session-Variante in diesem ADR ursprünglich gescheitert ist, tritt hier nicht auf. Damit ist die Kernannahme der Ultima Ratio bestätigt: der native Installer lässt sich zuverlässig unattended betreiben, wenn er über seinen offiziell unterstützten Weg (Netinstall-Medium + inst.ks=) und nicht aus einer Live-Sitzung heraus gestartet wird.

Schritt 1 (Mint-Installer-Typ klären) aus dem ursprünglichen Prüfplan bleibt weiterhin offen, ist für die Ultima Ratio aber ohnehin separat zu klären (jede Distribution bekommt ihr eigenes Backend/ihre eigene Installer-Logik).

Offen, nächster Schritt: Dieser Test lief auf einer Proxmox-VM mit virtio/DHCP — die reale Zielhardware (Pilotschulen) hat vermutlich nur WLAN. inst.ks=https://... erfordert Netzwerk bereits im frühen Dracut-Boot der Netinstall-Umgebung, bevor die Kickstart-Datei geladen werden kann — ob und wie WPA/WLAN dort ohne bereits laufendes NetworkManager funktioniert, ist exakt dieselbe unbeantwortete Frage wie schon beim ursprünglichen Live-Boot-Ansatz, hier nur erneut aufgeschoben statt gelöst. Als Nächstes vereinbart: WLAN-Autoprovisionierung (Baken der NetworkManager-Zugangsdaten ins Image, siehe „WLAN-Zugangsdaten" oben) real auf echter Hardware (Notebook) testen.

Update (30.07.2026): WLAN-Test auf echter Hardware — Ursache gefunden, kein Kickstart-Problem

Realer WLAN-Test auf einem Notebook (Intel-Hardware) mit einem angepassten Fedora-Everything-Netinstall-ISO, ks.cfg direkt auf dem Medium (inst.ks=cdrom:/ks.cfg, keine Netz-Zustellung nötig). Drei Kickstart-Varianten der Reihe nach real getestet, alle mit identischem Ergebnis (dracut-initqueue.service hängt unbegrenzt):

1. network --device=wlan0 --essid=... --wpakey=... --activate
2. Dieselbe Zeile ohne --activate
3. Gar keine WLAN-Angabe mehr in der network-Zeile, stattdessen nmcli device wifi connect ... in einem %pre-Skript (das laut Kickstart-Ablauf erst in Anacondas vollerem install.img-Environment läuft, nach dem Stage2-Laden)

Da auch Versuch 3 identisch hängt, obwohl er gar kein WLAN mehr in der Dracut-verarbeiteten Kickstart-Direktive referenziert, war die Ursache nie die genaue Kickstart-Syntax.

Diagnose per rd.break=initqueue (Dracut-Haltepunkt, öffnet eine Shell direkt auf der Hauptkonsole, kein Konsolenwechsel nötig — relevant, weil auf diesem Notebook Strg+Alt+F2 nicht funktionierte): ip link show zeigt nur Loopback und die kabelgebundene Ethernet-Schnittstelle, kein WLAN-Interface. nmcli device status zeigt konsequent kein WLAN-Gerät. Über /sys/bus/pci/devices/ und /sys/bus/usb/devices/ wurde die Hardware identifiziert: Intel AX210 (PCI 8086:2725, Wi-Fi 6E), Bluetooth-Teil per USB (8087:0032) — ein verbreiteter, unter Linux gut unterstützter Chip.

Root cause: Das Boot-Initrd dieses Fedora-Everything-Netinstall-ISOs (images/pxeboot/initrd.img) enthält keinen iwlwifi-Treiber (kein iwlwifi.ko im gesamten Initrd, keine zugehörige Firmware) — die einzigen enthaltenen WLAN-Treiber sind aus der MediaTek-mt76-Familie (mt7921/mt76-sdio etc.). cfg80211/mac80211 (der generische 802.11-Stack) sind vorhanden, aber ohne passenden Hardware-Treiber wirkungslos. Das ist eine Lücke im offiziellen Fedora-Netinstall-Image selbst, nicht Folge irgendeiner eigenen Anpassung — kein Kickstart- oder Boot-Parameter-Trick kann einen im Initrd schlicht fehlenden Kernel-Treiber ersetzen.

Einordnung: Alle drei Kickstart-Versuche waren strukturell zum Scheitern verurteilt, unabhängig von ihrer jeweiligen Begründung — das Problem lag nie in der Kickstart-Syntax, sondern eine Ebene tiefer, im Treiberumfang des Boot-Mediums selbst. Damit bleibt die Kernaussage des vorherigen Updates unverändert gültig (Kickstart-getriebene, unattended Installation über den offiziellen Netinstall-Weg funktioniert, siehe DB-Blueprint-Test), aber die WLAN-Frage ist auf einer anderen Ebene offen als angenommen.

Nicht mitgetestet, aber relevant: Ob das Intel-AX210-Beispiel repräsentativ für tatsächliche Pilotschul-Hardware ist, ist unbekannt — dieser Test lief auf dem persönlichen Notebook des Nutzers, nicht auf Zielhardware. Möglich, dass andere Geräte (z.B. mit MediaTek-Chips) mit genau diesem Image bereits funktionieren würden.

Optionen für den nächsten Schritt (noch nicht entschieden):

1. iwlwifi-Treiber und passende Firmware nachträglich ins Netinstall-Initrd einbauen (echte Lösung der Ursache, aber Initrd-Chirurgie mit eigenem Risiko — das naive Anhängen eines weiteren Initrd-Segments per cat scheiterte schon einmal an Kompressionsformat-Fragen, siehe Update vom 29.–30.07.2026 oben; ein sauberer Fix müsste entpacken/ergänzen/neu komprimieren statt nur anhängen).
2. Ein anderes Fedora-Installationsmedium mit breiterer Treiberabdeckung testen (z.B. eine reguläre Fedora-Workstation-Netinstall/DVD-Variante, die ggf. großzügiger bestückt ist).
3. Klären, welche WLAN-Chips die tatsächliche Pilotschul-Hardware mitbringt, bevor weiter am Treiberumfang gearbeitet wird — falls diese Hardware ohnehin andere Chips hat, wäre dieser konkrete Fund für die Praxis nicht blockierend.

Update (30.07.2026): Fedora-Server-DVD ebenfalls real getestet — hängt aus ungeklärtem Grund, unabhängig von Netzwerk

Fedora-Server-DVD (nicht Netinstall, echtes Offline-Medium, siehe Präzisierung oben) real auf derselben Notebook-Hardware getestet, mit einem Kickstart ganz ohne network-Zeile (Hostname stattdessen per hostnamectl in %post, siehe „Wie kommen WLAN-Zugangsdaten ins installierte System"-Diskussion). Ergebnis: hängt an exakt derselben Stelle (dracut-initqueue.service, unbegrenzter Timer) wie die Netinstall-Versuche zuvor.

Getestete Eingrenzungsschritte, in dieser Reihenfolge:

1. network --hostname=... (kein WLAN) in der Kickstart-Datei → hängt.
2. Gar keine network-Zeile mehr → hängt identisch.
3. Notebook mit gestecktem Ethernet-Kabel neu gebootet → hängt weiterhin identisch.

Schritt 3 ist der wichtigste Befund: Eine funktionierende Kabelverbindung sollte, falls die Ursache tatsächlich „wartet auf Netzwerk, findet aber nur ein WLAN ohne Treiber" wäre, das Problem auflösen. Da das nicht der Fall ist, ist die Ursache an dieser Stelle nicht mehr eindeutig auf die bereits gefundene fehlende iwlwifi-Lücke zurückzuführen — es könnte sich um eine andere, noch nicht diagnostizierte Ursache handeln (z. B. Stage2-Geräteerkennung für dieses konkrete Medium, oder etwas völlig anderes). Eine rd.break=initqueue-Sitzung mit vollem journalctl-Log wurde vorbereitet, aber die Untersuchung an dieser Stelle bewusst abgebrochen (Nutzer-Entscheidung, 30.07.2026) — nicht mangels Möglichkeit, sondern weil der Aufwand für Fedora an diesem Punkt als nicht mehr verhältnismäßig eingeschätzt wurde.

Konsequenz: Fedora als Backend für die automatisierte Ersteinrichtung ist auf dieser konkreten Testhardware bislang in keiner geprüften Variante (Live+kexec, Netinstall, DVD) vollständig unbeaufsichtigt ans Ziel gekommen — bei klar unterschiedlichen, jeweils eigenständigen Ursachen (fehlendes Anaconda-Modul, fehlender wpa_supplicant, fehlender iwlwifi-Treiber, zuletzt ein noch ungeklärter Hänger auch mit Kabel). Naheliegender nächster Schritt, nicht mehr an dieser Stelle verfolgt: Ubuntu/Mint mit demselben Testaufbau (personalisierte ISO, Kickstart/Autoinstall auf dem Medium) probieren — andere Installer-Software (Subiquity/Ubiquity statt Anaconda), möglicherweise andere Treiberauswahl im jeweiligen Installer-Initrd.

Ultima Ratio (konkretisiert 23.07.2026): personalisierte, vorentschiedene Installer-ISO

Falls sich zeigt, dass sich der native Installer generell nicht zuverlässig aus einer Live-Sitzung heraus (auch nicht per Reboot mit dynamisch nachgeladener Konfiguration) automatisieren lässt, verschiebt dieser Weg die Workspace-/Backend-Entscheidung komplett vor den Boot-Vorgang, auf die zentrale Plattform:

Der Kunde legt sich im (künftigen) Self-Service-Portal auf Workspace, Backend/Distribution und WLAN-Zugangsdaten fest (Fortführung des bereits entschiedenen personalisierten-ISO-Modells, siehe „WLAN-Zugangsdaten" oben) und erzeugt sich darüber eine deutlich kleinere, auf die gewählte Distribution zugeschnittene Installer-ISO (Netinstall-artig, keine volle Live-Desktop-Umgebung) — mit der fertigen Kickstart-/Autoinstall-/Preseed-Konfiguration bereits eingebacken, nicht zur Laufzeit nachgeladen. Diese ISO wird mit dem ohnehin schon vorgesehenen Mechanismus gebootet und installiert komplett unbeaufsichtigt, in genau der Betriebsart, für die der jeweilige native Installer gebaut ist — keine Live-Sitzung, kein Late-Binding, keine offene Netzwerk-Zustellungsfrage mehr (die Konfiguration liegt bereits auf dem Medium).

Das ist konsistent mit der bereits dokumentierten Aufgabe von backend_postinstall() ("Registrierung am Provisioning-Server vorbereiten") — Geräteregistrierung war ohnehin für den ersten Boot des installierten Systems vorgesehen, nicht für die Install-Phase selbst.

Bewusster Preis dieses Wegs: der interaktive Kiosk-Modus (Epiphany, Panel-Anpassungen, die gesamte Kiosk-UI-Arbeit) würde für den primären Ablauf zur Nebensache — allenfalls noch als optionaler Sonderfall für spontane Vor-Ort-Entscheidungen ohne vorherige Portal-Konfiguration. Zusätzlich braucht dieser Weg serverseitig eine echte ISO-Bau-Infrastruktur pro Distribution, nicht nur das bisherige Überlagern von WLAN-Zugangsdaten auf ein festes Basis-Image.

Verfeinerung (23.07.2026): ein generisches Bootstrap-Medium statt N physischer ISOs

Damit Kunden nicht für jede Workspace-/Distributions-Kombination einen eigenen Stick flashen müssen, lässt sich die Zustellung der personalisierten Installer-ISO vom physischen Medium entkoppeln:

Ein einziges, generisches, deutlich schlankeres Bootstrap-Medium (keine volle Live-Desktop-Umgebung nötig — nur genug Logik für Netzwerk, Server-Handshake und minimale Disk-Vorbereitung) legt beim Boot eine kleine Partition auf der Zieldisk an, lädt die vom Server für diesen Kunden/dieses Gerät gebaute, distributionsspezifische Installer-ISO herunter, schreibt sie in diese Partition und richtet per GRUB loopback/iso-scan (bzw. findiso= bei Ubuntu/Debian) einen Boot-Eintrag ein, der direkt aus der ISO-Datei bootet — ein etabliertes, produktiv genutztes Muster (siehe z. B. Ventoy), keine Neuerfindung. Nach dem Reboot läuft der jeweilige native Installer genau in seiner offiziell unterstützten, automatisierten Betriebsart — die Konfiguration liegt bereits lokal, kein Netzwerk-Zustellungsproblem beim zweiten Boot.

Die Staging-Partition ist dabei bewusst kein dauerhafter Sonderbereich: Sobald die eigentliche Workspace-Installation von dort aus läuft, überschreibt deren eigene Partitionierungslogik (clearpart --all/zerombr bzw. das Autoinstall-/Preseed-Äquivalent) die komplette Zieldisk inklusive der Staging-Partition selbst — am Ende sieht die Platte genauso aus wie bei einer normalen Direktinstallation, kein Restartefakt. Das bewahrt die bereits getroffene Abgrenzung zu Option B (siehe oben): Tuxflotte legt nur eine schmale, wegwerfbare Zwischenablage an, die eigentliche Installationslogik (Partitionierung, Dateisystem, Bootloader, Pakete) bleibt vollständig beim nativen Installer.

Für einen späteren Workspace-/Distributionswechsel muss die Staging-Partition nicht dauerhaft bestehen bleiben — sie wird beim nächsten Wechsel einfach neu angelegt. Sobald der Provisioning Agent existiert, könnte dieser das komplett von innerhalb des laufenden, installierten Systems selbst anstoßen (neue ISO laden, Partition neu befüllen, Boot-Eintrag setzen, Reboot auslösen) — echte Remote-Reprovisionierung ganz ohne erneuten physischen Medienzugriff.

Einordnung: dieser verfeinerte Weg ist mehr als nur eine Umgehung des Anaconda-Live-Problems — er vereinfacht die Gesamtarchitektur spürbar. Die gesamte Kategorie an Problemen der letzten Tage (Cinnamon-Panel-Defaults, Epiphany-Versionsunterschiede, dconf-Wettlaufbedingungen, EROFS-Umgehung für ein volles Live-Image) entsteht ausschließlich dadurch, dass eine volle Live-Desktop-Umgebung betrieben werden muss — ein schlankes Bootstrap-Medium braucht das nicht. Er passt zudem besser zur Grundphilosophie ("Tuxflotte installiert keine Distributionen, sondern orchestriert die nativen Installer") als der bisherige Ansatz: Tuxflottes eigener Code bleibt distributionsunabhängig (ISO holen, staging, per Loopback booten), alles Distributionsspezifische bleibt beim jeweiligen nativen Installer in dessen eigener, offiziell unterstützter Automatisierung.

Präzisierung (30.07.2026): Bootstrap-Medium muss hardwaretechnisch breit sein, nicht nur schlank

Der reale WLAN-Test oben deckt eine unausgesprochene, falsche Gleichsetzung in der Verfeinerung auf: „schlank" und „hardwaretechnisch breit aufgestellt" wurden implizit als dasselbe behandelt, sind aber zwei unabhängige Eigenschaften. Das schmal gebaute Fedora-Netinstall-Initrd spart Größe gerade durch Verzicht auf breite Treiber-/Firmware-Abdeckung (iwlwifi fehlt komplett, siehe oben) — für ein Bootstrap-Medium, dessen einziger Zweck „auf möglichst jeder Hardware ein Netzwerkinterface finden" ist, ist genau das fatal.

Präzisierte Anforderung: Das Bootstrap-Medium sollte auf einem hardwaretechnisch breit ausgestatteten Live-Image basieren (Fedora- oder Ubuntu-Live-artig, mit vollem Firmware-/Treiberumfang), nicht auf einem schlanken Netinstall-Image. Das widerspricht der ursprünglichen Verfeinerung nicht in der Sache, sondern korrigiert nur eine unausgesprochene Annahme darin: „schlank" sollte sich von Anfang an nur auf die UI-Schicht beziehen (kein Fenstermanager, kein Kiosk-Browser, kein Panel, kein dconf) — genau die Problemklasse, die die Verfeinerung zurecht vermeiden wollte, bleibt vermieden, solange das Bootstrap-Medium headless/terminal-only läuft. Das ist orthogonal zur Treiberbreite, nicht identisch damit.

Konkrete Anknüpfung: Das bestehende, real geprüfte Fedora-Cinnamon-Live-Image ist ein plausibler Ausgangspunkt für das Bootstrap-Medium selbst — WLAN, Server-Handshake, Aktivierung und Bereitstellungsvorlage-Auflösung laufen darauf bereits nachweislich (siehe milestones.md). Zu entfernen wäre nur die Kiosk-UI-Ebene (Epiphany-Autostart, Panel-Anpassungen) — die wird für den reinen Bootstrap-Zweck nicht gebraucht. Neu zu bauen ist ausschließlich der Übergangsmechanismus selbst: personalisierte Ziel-ISO vom Server laden, in eine Staging-Partition schreiben, per GRUB loopback/iso-scan dorthin booten (siehe oben) — dieser Teil existiert bisher nur als Idee, nicht als Code. Der frühere Ansatz (Kickstart aus der laufenden Live-Sitzung heraus starten, per kexec oder sonstwie) bleibt verworfen (siehe ADR-Titel und Updates oben).

Die Basis-Distribution des Bootstrap-Mediums ist dabei unabhängig von der später installierten Ziel-Distribution wählbar — Fedora-Live zur Wiederverwendung des bereits Vorhandenen, oder Ubuntu-Live wegen möglicherweise noch breiterer Hardwareunterstützung. Offene Frage, noch nicht entschieden.

Entscheidung (30.07.2026): Weiter mit Mint auf Ubuntu-Basis statt Fedora

Nach drei unabhängigen, strukturell unterschiedlichen Sackgassen auf derselben Testhardware (fehlendes anaconda-Dracut-Modul im Live-Image, fehlender wpa_supplicant und fehlender iwlwifi-Treiber im Netinstall-Initrd, ein zuletzt nicht mehr diagnostizierter dracut-initqueue-Hänger auf der DVD-Variante, der auch mit gestecktem Ethernet-Kabel bestehen blieb) hat der Nutzer entschieden, das Fedora-Backend an dieser Stelle nicht weiterzuverfolgen und stattdessen mit Linux Mint auf Ubuntu-Basis weiterzumachen.

Das ist keine Entscheidung gegen Fedora als Backend grundsätzlich — die Fedora-Sackgassen sind spezifisch für die verwendete Testhardware und die verwendeten offiziellen Fedora-Medien, nicht notwendigerweise repräsentativ für andere Hardware oder für die eigentliche Pilotschul-Zielhardware. Das Fedora-Backend (backends/fedora/) bleibt im Code bestehen und ist nicht rückgebaut.

Für die Fortsetzung mit Mint/Ubuntu gilt dasselbe, in diesem ADR erarbeitete Architekturmodell (personalisierte ISO pro Workspace/Backend/Medienvariante, Kickstart/Autoinstall bereits eingebacken, network-Direktiven im Installationsschritt selbst vermeiden, Provisioning Agent übernimmt WLAN/Handshake/Blueprint-Anwendung beim ersten Boot des fertig installierten Systems) — nur mit Ubuntus/Mints eigenem Installer-Stack (Subiquity/Autoinstall oder Ubiquity/Preseed, siehe Prüfplan weiter oben, Schritt 1 „welchen Installer bringt Mint mit" ist damit jetzt wieder relevant und weiterhin ungeklärt) statt Anaconda/Kickstart.

Nächster Schritt: dasselbe empirische Vorgehen wie hier für Fedora — realer Test auf derselben Notebook-Hardware, sobald der Nutzer bereit ist weiterzumachen. Nicht proaktiv fortsetzen, ohne dass der Nutzer das wieder aufgreift.

Update (31.07.2026): Mint/Ubiquity real getestet — WLAN und Live-Kontakt zu anode funktionieren während der Installation

Schritt 1 aus dem ursprünglichen Prüfplan ist geklärt: Linux Mint (Cinnamon) nutzt Ubiquity (nicht Subiquity, das ist Ubuntu-Server-spezifisch), mit klassischem Debian-Installer-Preseed-Format (d-i <template> <type> <wert>). Automatisierter Modus über den Kernel-Parameter automatic-ubiquity zusammen mit file=/cdrom/preseed/<datei>.seed (Preseed-Datei direkt auf dem Medium, analog zu Fedoras inst.ks=cdrom:/ks.cfg).

Struktureller Unterschied zu Fedora, der sich als entscheidend herausstellte: Ubiquitys automatisierter Modus bootet weiterhin über boot=casper — dasselbe Live-Environment wie die normale interaktive Live-Sitzung, kein separates, abgespecktes Installer-Environment wie Anacondas Netinstall/DVD-Stage2. Damit entfällt die Fedora-typische Treiberlücke von vornherein: Das Boot-Medium (linuxmint-22.3-cinnamon-64bit.iso) hat außerdem keine versteckte zweite FAT-ESP-Partition mit eigenem grub.cfg — /boot/grub/grub.cfg im ISO9660-Baum ist die einzige, tatsächlich gelesene Konfigurationsdatei, kein Analogon zu Fedoras BOOT.conf-Falle.

Realer Test: Preseed-Datei mit ubiquity/success_command (läuft in-target/chrooted, nach Paketinstallation, vor Neustart) — der Befehl führt nmcli device wifi connect stallinux password ... aus und ruft danach https://anode.tuxflotte.de/health per curl auf. Ergebnis: WLAN verbindet sich erfolgreich (wlp9s0 → connected, echter Intel-AX210-Chip auf derselben Testhardware, die bei Fedora gar kein Interface fand), und curl liefert eine echte Antwort vom Provisioning-Server zurück ({"status":"ok","service":"provisioning-server","version":"0.1.0"}). Damit ist zum ersten Mal in dieser gesamten Untersuchung ein echter, funktionierender Live-Kontakt zur Plattform während der Installation demonstriert — nicht nur eine post-install Möglichkeit.

Beobachtung mit Konsequenz: Nach dem Neustart ins fertig installierte System war die WLAN-Verbindung nicht mehr vorhanden, der Nutzer musste sich erneut verbinden. Wahrscheinliche Ursache: in-target chrootet zwar die Dateisystem-Sicht des Kommandos, aber nmcli sprach dabei vermutlich weiterhin mit dem laufenden NetworkManager-Dienst der Live-Sitzung (über den gemeinsam gemounteten /run), nicht mit einer Instanz, die für das Zielsystem persistent schreibt — das Verbindungsprofil landete dadurch im flüchtigen Live-Medium, nicht auf der installierten Platte. Für Persistenz muss die .nmconnection-Datei zusätzlich direkt als Dateioperation ins gechrootete /etc/NetworkManager/system-connections/ geschrieben werden (dieselbe Technik, die für Fedora schon durchdacht, aber nie real getestet wurde) — reines nmcli connect reicht für die Installation selbst (bewiesen), aber nicht für Persistenz über den Reboot hinaus.

Einordnung: Das eröffnet für das Mint-Backend eine echte Alternative zum bisher erarbeiteten Modell (alles auf den Provisioning Agent nach dem ersten Boot verschieben) — Installationsvorgaben könnten dynamisch zur Installationszeit von anode geholt werden, statt vollständig vorab in die personalisierte ISO eingebacken zu sein. Ob das tatsächlich so umgesetzt wird, ist noch nicht entschieden, nur als real funktionierende Möglichkeit bestätigt.

Nachtrag (31.07.2026): Persistenz-Fix real getestet — mit einer wichtigen Nebenerkenntnis zu Debconf-Preseed selbst

Der direkte Dateischreib-Ansatz aus dem Absatz oben wurde als eigener, mehrzeiliger ubiquity/success_command-Preseed-Wert getestet (Aufbau, Berechtigungen setzen, .nmconnection-Inhalt per printf schreiben) — Ergebnis: kein Log, keine Datei, obwohl derselbe Bash-Code lokal fehlerfrei lief (bash -n/tatsächliche Ausführung geprüft). Der komplette success_command-Aufruf wurde also offenbar nie ausgeführt, nicht einmal die erste echo-Zeile — ein reiner Bash-Syntaxfehler war damit ausgeschlossen, die Ursache lag also vermutlich an Debconfs Preseed-Zeilenverkettung selbst (viele verschachtelte Anführungszeichen/eckige Klammern über mehrere per \ fortgesetzte Zeilen hinweg), nicht am Skriptinhalt.

Fix: Das komplette Skript Base64-kodiert, success_command reduziert auf eine einzige, kurze Zeile ohne jegliche Sonderzeichen: in-target bash -c 'echo <base64> | base64 -d | bash'. Damit lief alles fehlerfrei durch — WLAN verbindet sich per nmcli während der Installation, curl erreicht anode, und die .nmconnection-Datei landet korrekt (600, root:root, richtiger Inhalt) auf der Zielplatte unter /target/etc/NetworkManager/system-connections/ (verifiziert vor dem Reboot, da ubiquity/reboot boolean false gesetzt wurde, um genau das zu prüfen, bevor die Live-Sitzung verschwindet).

Für spätere success_command/late_command-Preseed-Werte festhalten: lange, mehrzeilige, stark verschachtelte Preseed-Werte sind riskant und scheitern ohne hilfreiche Fehlermeldung — Base64-Kodierung des eigentlichen Skripts ist der robustere, empfohlene Weg, nicht nur ein Notbehelf für diesen einen Fall.

Ob die WLAN-Verbindung nach einem echten Reboot ins fertig installierte System jetzt automatisch (ohne erneute Passworteingabe) steht, ist der letzte noch ausstehende Prüfschritt.

Bestätigt, nach echtem Reboot: WLAN verbindet sich im fertig installierten System automatisch, ohne erneute Passworteingabe. Damit ist die Persistenz-Kette vollständig real bewiesen, nicht nur einzelne Teile davon.

Abschluss dieser Untersuchung (31.07.2026)

Die Kernfrage dieses gesamten ADR ist damit vollständig und real beantwortet — nicht theoretisch, sondern auf echter Notebook-Hardware (Intel AX210, die bei Fedora in keiner Variante ein WLAN-Interface fand):

1. Personalisierte ISO mit eingebackenem Preseed installiert unbeaufsichtigt (Mint/Ubiquity).
2. WLAN funktioniert während der Installation (anders als bei jeder getesteten Fedora-Variante).
3. Echter Live-Kontakt zur Plattform (anode) während der Installation ist real möglich, nicht nur eine Idee.
4. Das WLAN-Verbindungsprofil übersteht den Reboot und verbindet sich im installierten System automatisch.

Bewusst offen gelassen, für später:

• Der Provisioning Agent existiert weiterhin nur als Architektur, nicht als Code.
• Ob produktiv live während der Installation mit anode gesprochen wird oder das dem Agenten beim ersten Boot überlassen bleibt, ist eine noch zu treffende Design-Entscheidung — technisch sind jetzt beide Wege nachweislich gangbar.
• Eine schlanke Debian-Netinstall-Variante für ein eigenständiges Backend („können wir irgendwann nachreichen", Nutzer-Entscheidung 31.07.2026).

Nicht proaktiv fortsetzen, ohne dass der Nutzer das wieder aufgreift.

Update (01.08.2026): d-i preseed/early_command bei Ubiquity real widerlegt, Architektur entsprechend vereinfacht

Aufbauend auf der Idee vom Vortag (Live-Kontakt zu anode während der Installation, um install-zeitlich fixe Vorgaben wie Partitionierung dynamisch statt vorab-eingebacken zu laden) wurde d-i preseed/early_command real getestet — läuft laut Debian-Installer-Dokumentation früh genug, um per debconf-set-selections noch vor der Partitionierung Werte zu setzen, und (anders als success_command) nicht gechrootet.

Ergebnis: kein Effekt, keinerlei Spur. Weder die vom Skript selbst erzeugte Logdatei noch irgendein Hinweis in /var/log/syslog oder /var/log/installer/debug — der Befehl wurde nie ausgeführt. Journal-Fund zur Erklärung: ubiquity: ['log-output', '-t', 'ubiquity', '--pass-stdout', '/usr/share/ubiquity/plugininstall.py'] exited with code 0 — Ubiquity führt seine Installationsschritte über ein eigenes Python-„Plugin"-System aus, nicht über die klassischen Shell-„Components" des Debian-Installers, an die early_command/late_command als Preseed-Sonderhaken gebunden sind. Kein Konfigurationsfehler, sondern eine andere Architektur — die anderen d-i-Direktiven (Partitionierung, Netzwerk, Nutzer) funktionierten ja bereits durchgehend, nur dieser Meta-Mechanismus nicht.

Entscheidung (01.08.2026): Kein eigenes Ubiquity-Plugin bauen, kein Vor-Ubiquity-Hook im Live-Dateisystem — der Aufwand steht für den Pilotbetrieb nicht im Verhältnis zum Nutzen. Stattdessen zurück zu einem einfacheren, schon einmal (23.07.2026) skizzierten Modell: Organisationsspezifische, install-zeitlich fixe Vorgaben (Partitionierung, Dateisystem, Corporate-Branding) kommen bereits beim ISO-Erzeugen im Self-Service-Portal in die personalisierte Preseed-Datei — kein Live-Nachladen zur Installationszeit nötig. Die Installation kann Kundenwünsche also auch ohne early_command vollständig erfüllen.

Bootmenü als eigentlicher Sicherheits-Gate, mit einer wichtigen Korrektur: Der bisher gebaute Test-Bootmenüs hatten „Tuxflotte Auto-Install" als Standardeintrag — bei Nichtstun wäre die destruktive Installation automatisch losgelaufen. Nutzer-Korrektur: richtig ist genau umgekehrt — Standard (Countdown-Ablauf) muss „von lokaler Festplatte booten" sein, die destruktive Installation nur bei aktiver, bewusster Auswahl aus dem Menü. Beide Testmenüs (boot-grub.cfg für UEFI, isolinux-live.cfg für BIOS) wurden entsprechend korrigiert und real verifiziert. Das ist jetzt der tatsächliche physische Bestätigungs-Mechanismus für ADR-0008s Auto-Modus-Gate — kein Zeitfenster zum Abbrechen, sondern eine bewusste Positiv-Auswahl, um überhaupt zu starten.