diff --git a/adr/0009-anaconda-live-kickstart-verworfen.md b/adr/0009-anaconda-live-kickstart-verworfen.md new file mode 100644 index 0000000..9029522 --- /dev/null +++ b/adr/0009-anaconda-live-kickstart-verworfen.md @@ -0,0 +1,41 @@ +# 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=`, 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. +- Nächster Schritt: Ubuntu/Debian-basierte Installer-Medien (Debian-Installer/Preseed oder Subiquity/Autoinstall) neu bewerten — beide kennen diese Live-Kickstart-Einschränkung nicht, und ein Ubuntu-basiertes Live-Medium war ohnehin schon als Prüfpunkt vorgemerkt (`13-live-provisioning-boot.md`, EROFS-Vermeidung). +- Ultima Ratio, falls auch das nicht überzeugt: Umstieg auf den offiziell unterstützten Anaconda-Kickstart-Weg (separates Netinstall-/Boot-Medium, `inst.ks=` am Kernel-Cmdline, `liveimg --url=` in der Kickstart-Datei) — ein strukturell größerer Rückschritt gegenüber dem aktuellen "alles läuft in einer gebooteten Live-Sitzung"-Modell. Dabei stünde auch zur Debatte, ob der interaktive Modus (mangels grafischer Sitzung ohne echte lokale Bedienbarkeit) zugunsten eines reinen Auto-Modus mit Portal-Bestätigung (ADR-0008) und rein beobachtbarer Fortschrittsanzeige aufgegeben würde. +- 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. diff --git a/architecture/13-live-provisioning-boot.md b/architecture/13-live-provisioning-boot.md index 3e13e9b..4ed16d7 100644 --- a/architecture/13-live-provisioning-boot.md +++ b/architecture/13-live-provisioning-boot.md @@ -92,6 +92,8 @@ Stattdessen ruft `backend_launch()` (siehe `06-backend-api.md`) den nativen Inst Die statische Kickstart-Datei sowie ihr Server-Endpoint (`GET /installers/fedora-workstation/ks.cfg`) entfallen damit. +**Für das Fedora-Backend widerlegt (23.07.2026, ADR-0009):** Anaconda verarbeitet Kickstart-Direktiven aus der laufenden Live-Sitzung heraus nachweislich nicht zuverlässig (`rootpw`/`user`/Partitionierung bleiben unvollständig, real getestet). Der tatsächliche Weg für das Fedora-Backend ist noch offen — Details und Alternativen in ADR-0009. + --- ## WLAN-Zugangsdaten