Thomas Stallinger
5223f8a13c
Replaces the vague "separate netinstall media" fallback with a concrete design: move the workspace/backend decision to the self-service portal, before boot, and bake the finished kickstart/ autoinstall/preseed config into a personalized, distro-specific, much smaller installer ISO at build time. Sidesteps the live-session vs. native-installer-automation tension entirely, and the open early-boot networking question from the two-stage-reboot plan, since no runtime config fetch is needed. Consistent with backend_postinstall() already being scoped to the installed system's first boot, not the install phase. Names the real cost honestly: demotes the interactive kiosk mode to an optional secondary path, and requires real per-distro ISO-build infrastructure server-side. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
65 lines
8.2 KiB
Markdown
65 lines
8.2 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.
|
|
- 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.
|