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: Ultima Ratio wie oben — separates Netinstall-/Boot-Medium, inklusive der Grundsatzfrage, ob der interaktive Modus mangels grafischer Sitzung zugunsten von reinem Auto-Modus mit Portal-Bestätigung (ADR-0008) aufgegeben wird.