Thomas Stallinger
7d1d39caac
Real test on Fedora 44 / Anaconda 44.30-2.fc44 (bypassing the liveinst wrapper, which explicitly rejects kickstart on live media) confirmed the documented restriction firsthand rather than just by reading about it: --liveinst --kickstart in text mode silently drops rootpw/ user directives (require full manual re-entry, no error), and cmdline mode exits cleanly with CmdlineError naming Installation Destination, Root password, and User creation as unfinished despite being fully specified in the kickstart. Reimplementing install logic to bypass Anaconda entirely was considered and explicitly rejected. Next step is re-evaluating Ubuntu/Debian-based installer media instead of Anaconda's live mode; switching Fedora to the officially supported inst.ks=/liveimg pattern (separate netinstall media) remains a last resort. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
42 lines
4.6 KiB
Markdown
42 lines
4.6 KiB
Markdown
# 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.
|
|
- 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=<squashfs>` 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.
|