Thomas Stallinger 7f910a9033 docs: record concrete live-ISO implementation details

Fedora Cinnamon Live 44 chosen as the concrete base (interchangeable
with Workstation Live for this purpose), tuxflotte.mode kernel cmdline
flag name, 10s countdown with auto as default entry, and the
xorriso-based build.sh/extract.sh that no longer needs root. Checks
off 'Boot from local disk' in the installer roadmap, now verified
end-to-end in QEMU/KVM.

2026-07-18 11:26:35 +02:00

6.7 KiB

Raw Blame History

Live-Provisionierung und Boot-Modi

Status: Beschlossen Datum: 18.07.2026

Zweck dieses Dokuments

Dieses Dokument beschreibt, wie die Provisionierungs-ISO bootet, wie der automatisierte und der interaktive Ablauf sich unterscheiden, und wie der native Installer aus der Live-Umgebung heraus gestartet wird.

Es ergänzt 10-interactive-provisioning-flow.md (F-005), das den interaktiven Ablauf selbst beschreibt, um die Boot-Ebene davor.

Siehe ADR-0003 für die Entscheidung und ihre Begründung.

Ausgangslage

Die bisherige ISO basiert auf einer Fedora-DVD/Netinst-Struktur ohne Live-Umgebung. GRUB startet Anaconda direkt, mit einer über inst.ks= fest verdrahteten Kickstart-URL. Der gesamte in F-005 beschriebene Ablauf hat darauf keinen Einstiegspunkt.

Die neue ISO basiert stattdessen auf einem echten Live-Medium (erkennbar an /LiveOS/squashfs.img). scripts/installer.sh läuft als gewöhnliche Anwendung innerhalb dieser Live-Sitzung, mit vollem Zugriff auf Netzwerk (NetworkManager, WLAN), Bildschirm und Tastatur.

Boot-Ablauf

Boot
 ↓
GRUB-Menü (Countdown)
 ├── Zeitüberschreitung oder Standardeintrag
 │     ↓
 │   Live-Umgebung startet mit tuxflotte.mode=auto
 │
 └── manuelle Auswahl des zweiten Eintrags
       ↓
     Live-Umgebung startet mit tuxflotte.mode=interactive
 ↓
installer.sh liest tuxflotte.mode
 ↓
Netzwerk, Hardware, Aktivierung (wie bisher, "always"-Module)
 ↓
Moduswahl
 ├── auto
 │     ↓
 │   device.registration_status prüfen
 │     ├── existing    → Bereitstellungsvorlage automatisch wählen (is_default), Commit Point automatisch bestätigen
 │     └── registered  → Fail-Closed-Abbruch, Verweis auf interaktiven Ablauf
 │
 └── interactive
       ↓
     bisheriger F-005-Ablauf (Bereitstellungsvorlage-Auswahl, explizite Bestätigung)
 ↓
Runtime Blueprint erzeugen → Backend laden → backend_generate_config()
 ↓
backend_launch() startet den nativen Installer explizit aus der Live-Sitzung heraus

Beide Moduspfade laufen ab „Runtime Blueprint erzeugen" identisch weiter. Der Unterschied liegt ausschließlich davor: in der Frage, ob eine Bereitstellungsvorlage interaktiv gewählt und der Commit Point interaktiv bestätigt wird, oder ob beides automatisch anhand vorhandener Daten geschieht.

Auto-Modus-Gate

Der automatisierte Ablauf ersetzt keine Sicherheitsprüfung, sondern ersetzt nur, wer die Bestätigung gibt: statt einer Benutzereingabe entscheidet ein bereits bestehender, geprüfter Zustand.

Voraussetzung für den automatisierten Ablauf ist ausschließlich:

device.registration_status == "existing" in der Antwort von POST /api/v1/activate.

Ein unbekanntes Gerät (registration_status == "registered") durchläuft niemals den automatisierten Ablauf, unabhängig vom gewählten Bootmenüeintrag. Die Geräteaufnahme bleibt gemäß 11-device-enrollment.md an eine explizite, interaktive Bestätigung gebunden.

Das Fail-Closed-Prinzip aus 10-interactive-provisioning-flow.md gilt unverändert: Fehlt eine gültige Grundlage für die automatische Bestätigung (zum Beispiel eine unerwartete oder unlesbare Serverantwort), bricht der Ablauf ab, statt ersatzweise eine Bestätigung anzunehmen.

Konsequenz für die Geräteregistrierung

Wer ein Gerät registriert, akzeptiert damit, dass dieses Gerät künftig ohne erneute interaktive Rückfrage automatisiert neu installiert werden kann, solange es über seinen Hardware-Fingerprint als bereits registriert erkannt wird.

Dies wird bei der Geräteregistrierung ausdrücklich kommuniziert (siehe 11-device-enrollment.md).

Nativer Installer aus der Live-Sitzung

Der native Installer wird nicht mehr über einen boot-zeitlichen Parameter gestartet.

Stattdessen ruft backend_launch() (siehe 06-backend-api.md) den nativen Installer explizit auf, mit der zuvor von backend_generate_config() erzeugten, lokal vorliegenden Konfiguration.

Die statische Kickstart-Datei sowie ihr Server-Endpoint (GET /installers/fedora-workstation/ks.cfg) entfallen damit.

WLAN-Zugangsdaten

Zwei getrennte Anwendungsfälle:

WLAN für die Live-Provisionierungsumgebung. Ohne Netzwerk ist der Provisioning-Server nicht erreichbar. Zugangsdaten für dieses Netzwerk müssen deshalb bereits im ISO-Build hinterlegt sein (zum Beispiel als NetworkManager-Verbindungsprofil in einem organisationsspezifischen ISO-Build), nicht dynamisch vom Server geladen werden.

WLAN für das installierte Zielsystem. Dies ist eine dauerhafte, organisationsweite Vorgabe und gehört zum noch unspezifizierten Network Profile-Modell der Organization (siehe 09-data-model-v1.md). Die Anwendung erfolgt wie andere organisationsweite Vorgaben, nicht als Teil der Provisionierungs-Bootphase.

Konkrete Umsetzung (Stand 18.07.2026)

Als konkrete Basis wird eine Fedora-Cinnamon-Live-ISO verwendet (Volume-Label Fedora-Cinn-Live-44), nicht Fedora Workstation Live. Für die Zwecke dieses Dokuments ist das austauschbar — entscheidend ist ausschließlich das Vorhandensein von /LiveOS/squashfs.img, nicht die konkrete Desktop-Umgebung.

Das in der Boot-Ablauf-Grafik oben genannte Kernel-Cmdline-Flag heißt konkret tuxflotte.mode und wird als tuxflotte.mode=auto beziehungsweise tuxflotte.mode=interactive an den Kernel übergeben, zusätzlich zu den vom Live-Medium ohnehin benötigten Parametern (root=live:CDLABEL=Fedora-Cinn-Live-44 rd.live.image). installer.sh liest den gewählten Modus zur Laufzeit aus /proc/cmdline.

Das GRUB-Menü verwendet einen Countdown von 10 Sekunden; der Auto-Eintrag ist Index 0 und damit Standardauswahl. Ein dritter Menüpunkt zum Booten des bereits installierten lokalen Systems bleibt erhalten (vormals in 01-layered-provisioning.md als Anforderung an das Bootmenü genannt).

scripts/build.sh und scripts/extract.sh extrahieren die Quell-ISO über xorriso -osirrox statt über einen Loop-Mount und benötigen dadurch keine Root-Rechte mehr für den Build selbst.

Noch nicht umgesetzt: installer.sh liest tuxflotte.mode noch nicht aus, und das Installer-Payload (scripts/, backends/, config/) ist noch nicht in das Live-Squashfs integriert — es gibt aktuell keinen Autostart-Mechanismus, der installer.sh innerhalb der Live-Sitzung startet.

Zusammenfassung

Die Live-ISO ersetzt das direkte Booten in Anaconda durch eine vorgeschaltete, frei gestaltbare Live-Sitzung, in der installer.sh läuft.

Ein Bootmenü mit Countdown unterscheidet zwischen automatisiertem und interaktivem Ablauf; beide münden ab der Runtime-Blueprint-Erzeugung in denselben Codepfad.

Automatisierung ersetzt keine Sicherheitsprüfung, sondern bindet die Bestätigung an eine bereits bestehende, geprüfte Gerätezuordnung statt an eine Benutzereingabe.

6.7 KiB Raw Blame History