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.

## 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.