Thomas Stallinger 5223f8a13c docs: concretize ADR-0009 ultima ratio as a pre-decided personalized ISO

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>

2026-07-23 12:30:56 +02:00

8.2 KiB

Raw Blame History

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:

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.
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).
Nur falls Schritt 2 scheitert: dasselbe Reboot-Muster mit dem in Schritt 1 geklärten Ubuntu/Mint-Mechanismus.
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.

8.2 KiB Raw Blame History