Thomas Stallinger
72e6fa7c2a
Real hardware test (Intel AX210) shows the tested Fedora Everything netinstall initrd ships no iwlwifi driver at all -- three kickstart variants all hung identically at dracut-initqueue regardless of syntax, confirming the cause was never the kickstart itself. Documents the kexec test series (ADR-0009), the DB-driven kickstart success on netinstall, and the resulting architecture: a personalized installer ISO per workspace/backend/media-variant with the kickstart baked in, no live-session/kexec transition, WLAN and blueprint application moved to the Provisioning Agent's first boot on the fully installed target system instead of the constrained installer environment. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
140 lines
24 KiB
Markdown
140 lines
24 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.
|
||
|
||
## Update (29.–30.07.2026): Schritt 2 real getestet und gescheitert — direkter Wechsel zur Ultima Ratio
|
||
|
||
Schritt 2 (Fedora + Kickstart per Reboot) wurde real in einer Proxmox-VM getestet, nicht per Firmware-Reboot, sondern per `kexec` (siehe Begründung unten) — mit eindeutig negativem, aber sauber erklärbarem Ergebnis.
|
||
|
||
**Testaufbau:** `kexec -l`/`kexec -e` aus der laufenden Live-Sitzung heraus, um denselben Kernel mit neuer Kernel-Cmdline zu starten, ohne den Umweg über GRUB — das reguläre Live-Medium ist bewusst nicht dauerhaft beschreibbar, GRUB liest seine Config also bei jedem echten Reboot ohnehin nur wieder vom unveränderten Medium. `kexec` umgeht dieses Problem vollständig, da kein Firmware-/GRUB-Durchlauf nötig ist.
|
||
|
||
**Versuch 1:** `root=live:CDLABEL=TUXFLOTTE rd.live.image ... inst.ks=file:/tuxflotte-ks.cfg` (Kickstart-Datei direkt als zusätzliches cpio-Archiv ans Initrd angehängt). Ergebnis: kexec-Sprung fand nachweislich statt (kein Firmware-/GRUB-Screen, X-Server brach weg, neue Boot-Infozeilen), landete aber unverändert im normalen Live-Desktop (Epiphany) — `inst.ks=` wurde ignoriert.
|
||
|
||
**Versuch 2:** dieselbe Cmdline, aber Kickstart-Zustellung per `inst.ks=https://...` (bestehender Endpunkt auf `anode`, s.u.) statt per Initrd-Anhang, um eine mögliche Ursache (fehlerhafte cpio-Verkettung) auszuschließen. Vorher wurde tatsächlich ein Initrd-Verkettungsfehler beobachtet (`initramfs unpacking failed: invalid magic at start of compressed archive` — vermutlich weil das Basis-Initrd xz-/zstd-komprimiert ist und sich anders als ein Gzip-Initrd nicht einfach per `cat` verketten lässt); die Zustellung per HTTPS umgeht dieses Nebenproblem vollständig, ändert am Kernbefund aber nichts.
|
||
|
||
**Versuch 3:** `inst.stage2=hd:LABEL=TUXFLOTTE:/ ... inst.ks=https://...` **ohne** `root=live`/`rd.live.image`, in der Annahme, dass Letzteres Dracuts `dmsquash-live`-Pfad erzwingt und `inst.ks=` dabei grundsätzlich übergangen wird. Ergebnis: Dracut Emergency Shell, `Warning: Can't mount root-filesystem` — ohne `root=live` gab es gar keine auflösbare Root-Definition mehr, `inst.stage2=hd:LABEL=...` konnte sie nicht ersetzen.
|
||
|
||
**Entscheidender Befund:** `lsinitrd /run/initramfs/live/boot/x86_64/loader/initrd | grep -i anaconda` liefert **keinen Treffer**. Das `anaconda`-Dracut-Modul, das `inst.ks=`/`inst.stage2=` überhaupt erst auswerten und auf `anaconda.service` statt auf den normalen Live-Desktop umschalten würde, ist in diesem Initrd schlicht nicht enthalten. Das erklärt beide Fehlschläge ursächlich und einheitlich: keine Kombination von Boot-Parametern kann etwas bewirken, das im Initrd gar nicht als Auswertungslogik vorhanden ist. Dies ist keine Cmdline-Syntax-Frage, sondern eine strukturelle Eigenschaft des Fedora-Cinnamon-Live-Images (vermutlich, weil Live-Spins mit `dmsquash-live` gebaut werden, aber nicht zwangsläufig mit dem für Netinst-/DVD-Medien gedachten `anaconda`-Modul).
|
||
|
||
**Entscheidung (30.07.2026):** Schritt 3 (Mint/Ubuntu-Reboot-Test) wird bewusst ausgelassen, nicht aus Zeitmangel, sondern weil dieselbe strukturelle Ursache dort ebenfalls plausibel erscheint (Ubuntu-Desktop-Live-Images/Casper und Mint-Editionen bringen ihre unbeaufsichtigten Installationswege (Subiquity/Preseed) typischerweise auf einem separaten Server-/Netinst-Image, nicht im Desktop-Live-ISO) — diese Vermutung wurde nicht empirisch geprüft, ist aber Grundlage der Entscheidung, direkt zur unten stehenden Ultima Ratio überzugehen, statt einen strukturell vermutlich gleich ausgehenden Test zu wiederholen.
|
||
|
||
Nebenbefund ohne Bezug zum eigentlichen Test: Für die Zustellung in Versuch 2/3 wurde vorübergehend der bestehende, bereits produktiv genutzte Endpunkt `https://anode.tuxflotte.de/installers/fedora-workstation/ks.cfg` mit einer Testdatei überschrieben (Original gesichert unter `ks.cfg.bak-2026-07-29`) und muss vor einer erneuten Nutzung dieses Endpunkts wiederhergestellt werden.
|
||
|
||
## Update (30.07.2026): Ultima Ratio, Schritt 1a real bestätigt
|
||
|
||
Erster kleinster Ausschnitt der Ultima Ratio (siehe unten) real getestet, nicht mit synthetischen Testwerten, sondern mit den tatsächlichen DB-Daten: `POST /api/v1/activate` mit dem echten Aktivierungscode `LAB-2026-START` gegen die laufende `provisioning-server`-Instanz auf `anode`, danach `POST /api/v1/templates/{id}/resolve` für die Fedora-Bereitstellungsvorlage (`Schulcomputer (Fedora)`) — liefert den echten `runtime_blueprint` mit den drei realen Blueprints (`guest-session-ephemeral`/`guest-session`, `browser-brave`/`brave-fedora`, `office-onlyoffice`/`onlyoffice-fedora`).
|
||
|
||
Dieser `runtime_blueprint` wurde mit derselben `envsubst`-Logik wie `backend_generate_config()` (nur serverseitig statt geräteseitig ausgeführt) in `kickstart.tpl` eingesetzt und testweise wieder über `https://anode.tuxflotte.de/installers/fedora-workstation/ks.cfg` ausgeliefert (Original erneut gesichert und danach wiederhergestellt). Boot-Medium diesmal ein reguläres **Fedora-Netinstall-ISO** (nicht das Live-/Cinnamon-Image), `inst.ks=https://...` klassisch über die GRUB-Bootzeile gesetzt — derselbe Weg, der schon beim Meilenstein vom 16.06.2026 funktioniert hat, jetzt aber mit aktuellem DB-Stand statt der alten `config.json`.
|
||
|
||
**Ergebnis:** vollautomatischer Durchlauf, Login danach funktioniert, `rootpw`/`user` vollständig übernommen — genau der Fehler, an dem die live-Session-Variante in diesem ADR ursprünglich gescheitert ist, tritt hier nicht auf. Damit ist die Kernannahme der Ultima Ratio bestätigt: der native Installer lässt sich zuverlässig unattended betreiben, wenn er über seinen offiziell unterstützten Weg (Netinstall-Medium + `inst.ks=`) und nicht aus einer Live-Sitzung heraus gestartet wird.
|
||
|
||
Schritt 1 (Mint-Installer-Typ klären) aus dem ursprünglichen Prüfplan bleibt weiterhin offen, ist für die Ultima Ratio aber ohnehin separat zu klären (jede Distribution bekommt ihr eigenes Backend/ihre eigene Installer-Logik).
|
||
|
||
**Offen, nächster Schritt:** Dieser Test lief auf einer Proxmox-VM mit virtio/DHCP — die reale Zielhardware (Pilotschulen) hat vermutlich nur WLAN. `inst.ks=https://...` erfordert Netzwerk bereits im frühen Dracut-Boot der Netinstall-Umgebung, bevor die Kickstart-Datei geladen werden kann — ob und wie WPA/WLAN dort ohne bereits laufendes NetworkManager funktioniert, ist exakt dieselbe unbeantwortete Frage wie schon beim ursprünglichen Live-Boot-Ansatz, hier nur erneut aufgeschoben statt gelöst. Als Nächstes vereinbart: WLAN-Autoprovisionierung (Baken der NetworkManager-Zugangsdaten ins Image, siehe „WLAN-Zugangsdaten" oben) real auf echter Hardware (Notebook) testen.
|
||
|
||
## Update (30.07.2026): WLAN-Test auf echter Hardware — Ursache gefunden, kein Kickstart-Problem
|
||
|
||
Realer WLAN-Test auf einem Notebook (Intel-Hardware) mit einem angepassten Fedora-Everything-Netinstall-ISO, `ks.cfg` direkt auf dem Medium (`inst.ks=cdrom:/ks.cfg`, keine Netz-Zustellung nötig). Drei Kickstart-Varianten der Reihe nach real getestet, alle mit identischem Ergebnis (`dracut-initqueue.service` hängt unbegrenzt):
|
||
|
||
1. `network --device=wlan0 --essid=... --wpakey=... --activate`
|
||
2. Dieselbe Zeile ohne `--activate`
|
||
3. Gar keine WLAN-Angabe mehr in der `network`-Zeile, stattdessen `nmcli device wifi connect ...` in einem `%pre`-Skript (das laut Kickstart-Ablauf erst in Anacondas vollerem `install.img`-Environment läuft, nach dem Stage2-Laden)
|
||
|
||
Da auch Versuch 3 identisch hängt, obwohl er gar kein WLAN mehr in der Dracut-verarbeiteten Kickstart-Direktive referenziert, war die Ursache nie die genaue Kickstart-Syntax.
|
||
|
||
**Diagnose per `rd.break=initqueue`** (Dracut-Haltepunkt, öffnet eine Shell direkt auf der Hauptkonsole, kein Konsolenwechsel nötig — relevant, weil auf diesem Notebook `Strg+Alt+F2` nicht funktionierte): `ip link show` zeigt nur Loopback und die kabelgebundene Ethernet-Schnittstelle, **kein WLAN-Interface**. `nmcli device status` zeigt konsequent kein WLAN-Gerät. Über `/sys/bus/pci/devices/` und `/sys/bus/usb/devices/` wurde die Hardware identifiziert: Intel AX210 (PCI `8086:2725`, Wi-Fi 6E), Bluetooth-Teil per USB (`8087:0032`) — ein verbreiteter, unter Linux gut unterstützter Chip.
|
||
|
||
**Root cause:** Das Boot-Initrd dieses Fedora-Everything-Netinstall-ISOs (`images/pxeboot/initrd.img`) enthält **keinen `iwlwifi`-Treiber** (kein `iwlwifi.ko` im gesamten Initrd, keine zugehörige Firmware) — die einzigen enthaltenen WLAN-Treiber sind aus der MediaTek-`mt76`-Familie (`mt7921`/`mt76-sdio` etc.). `cfg80211`/`mac80211` (der generische 802.11-Stack) sind vorhanden, aber ohne passenden Hardware-Treiber wirkungslos. Das ist eine Lücke im offiziellen Fedora-Netinstall-Image selbst, nicht Folge irgendeiner eigenen Anpassung — kein Kickstart- oder Boot-Parameter-Trick kann einen im Initrd schlicht fehlenden Kernel-Treiber ersetzen.
|
||
|
||
**Einordnung:** Alle drei Kickstart-Versuche waren strukturell zum Scheitern verurteilt, unabhängig von ihrer jeweiligen Begründung — das Problem lag nie in der Kickstart-Syntax, sondern eine Ebene tiefer, im Treiberumfang des Boot-Mediums selbst. Damit bleibt die Kernaussage des vorherigen Updates unverändert gültig (Kickstart-getriebene, unattended Installation über den offiziellen Netinstall-Weg funktioniert, siehe DB-Blueprint-Test), aber die WLAN-Frage ist auf einer anderen Ebene offen als angenommen.
|
||
|
||
**Nicht mitgetestet, aber relevant:** Ob das Intel-AX210-Beispiel repräsentativ für tatsächliche Pilotschul-Hardware ist, ist unbekannt — dieser Test lief auf dem persönlichen Notebook des Nutzers, nicht auf Zielhardware. Möglich, dass andere Geräte (z.B. mit MediaTek-Chips) mit genau diesem Image bereits funktionieren würden.
|
||
|
||
**Optionen für den nächsten Schritt (noch nicht entschieden):**
|
||
1. `iwlwifi`-Treiber und passende Firmware nachträglich ins Netinstall-Initrd einbauen (echte Lösung der Ursache, aber Initrd-Chirurgie mit eigenem Risiko — das naive Anhängen eines weiteren Initrd-Segments per `cat` scheiterte schon einmal an Kompressionsformat-Fragen, siehe Update vom 29.–30.07.2026 oben; ein sauberer Fix müsste entpacken/ergänzen/neu komprimieren statt nur anhängen).
|
||
2. Ein anderes Fedora-Installationsmedium mit breiterer Treiberabdeckung testen (z.B. eine reguläre Fedora-Workstation-Netinstall/DVD-Variante, die ggf. großzügiger bestückt ist).
|
||
3. Klären, welche WLAN-Chips die tatsächliche Pilotschul-Hardware mitbringt, bevor weiter am Treiberumfang gearbeitet wird — falls diese Hardware ohnehin andere Chips hat, wäre dieser konkrete Fund für die Praxis nicht blockierend.
|
||
|
||
## 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.
|
||
|
||
### Verfeinerung (23.07.2026): ein generisches Bootstrap-Medium statt N physischer ISOs
|
||
|
||
Damit Kunden nicht für jede Workspace-/Distributions-Kombination einen eigenen Stick flashen müssen, lässt sich die Zustellung der personalisierten Installer-ISO vom physischen Medium entkoppeln:
|
||
|
||
Ein **einziges, generisches, deutlich schlankeres Bootstrap-Medium** (keine volle Live-Desktop-Umgebung nötig — nur genug Logik für Netzwerk, Server-Handshake und minimale Disk-Vorbereitung) legt beim Boot eine kleine Partition auf der Zieldisk an, lädt die vom Server für diesen Kunden/dieses Gerät gebaute, distributionsspezifische Installer-ISO herunter, schreibt sie in diese Partition und richtet per GRUB `loopback`/`iso-scan` (bzw. `findiso=` bei Ubuntu/Debian) einen Boot-Eintrag ein, der direkt aus der ISO-Datei bootet — ein etabliertes, produktiv genutztes Muster (siehe z. B. Ventoy), keine Neuerfindung. Nach dem Reboot läuft der jeweilige native Installer genau in seiner offiziell unterstützten, automatisierten Betriebsart — die Konfiguration liegt bereits lokal, kein Netzwerk-Zustellungsproblem beim zweiten Boot.
|
||
|
||
Die Staging-Partition ist dabei bewusst **kein dauerhafter Sonderbereich**: Sobald die eigentliche Workspace-Installation von dort aus läuft, überschreibt deren eigene Partitionierungslogik (`clearpart --all`/`zerombr` bzw. das Autoinstall-/Preseed-Äquivalent) die komplette Zieldisk inklusive der Staging-Partition selbst — am Ende sieht die Platte genauso aus wie bei einer normalen Direktinstallation, kein Restartefakt. Das bewahrt die bereits getroffene Abgrenzung zu Option B (siehe oben): Tuxflotte legt nur eine schmale, wegwerfbare Zwischenablage an, die eigentliche Installationslogik (Partitionierung, Dateisystem, Bootloader, Pakete) bleibt vollständig beim nativen Installer.
|
||
|
||
Für einen späteren Workspace-/Distributionswechsel muss die Staging-Partition nicht dauerhaft bestehen bleiben — sie wird beim nächsten Wechsel einfach neu angelegt. Sobald der Provisioning Agent existiert, könnte dieser das komplett von innerhalb des laufenden, installierten Systems selbst anstoßen (neue ISO laden, Partition neu befüllen, Boot-Eintrag setzen, Reboot auslösen) — echte Remote-Reprovisionierung ganz ohne erneuten physischen Medienzugriff.
|
||
|
||
**Einordnung:** dieser verfeinerte Weg ist mehr als nur eine Umgehung des Anaconda-Live-Problems — er vereinfacht die Gesamtarchitektur spürbar. Die gesamte Kategorie an Problemen der letzten Tage (Cinnamon-Panel-Defaults, Epiphany-Versionsunterschiede, dconf-Wettlaufbedingungen, EROFS-Umgehung für ein volles Live-Image) entsteht ausschließlich dadurch, dass eine volle Live-Desktop-Umgebung betrieben werden muss — ein schlankes Bootstrap-Medium braucht das nicht. Er passt zudem besser zur Grundphilosophie ("Tuxflotte installiert keine Distributionen, sondern orchestriert die nativen Installer") als der bisherige Ansatz: Tuxflottes eigener Code bleibt distributionsunabhängig (ISO holen, staging, per Loopback booten), alles Distributionsspezifische bleibt beim jeweiligen nativen Installer in dessen eigener, offiziell unterstützter Automatisierung.
|
||
|
||
### Präzisierung (30.07.2026): Bootstrap-Medium muss hardwaretechnisch breit sein, nicht nur schlank
|
||
|
||
Der reale WLAN-Test oben deckt eine unausgesprochene, falsche Gleichsetzung in der Verfeinerung auf: „schlank" und „hardwaretechnisch breit aufgestellt" wurden implizit als dasselbe behandelt, sind aber zwei unabhängige Eigenschaften. Das schmal gebaute Fedora-Netinstall-Initrd spart Größe gerade durch Verzicht auf breite Treiber-/Firmware-Abdeckung (`iwlwifi` fehlt komplett, siehe oben) — für ein Bootstrap-Medium, dessen einziger Zweck „auf möglichst jeder Hardware ein Netzwerkinterface finden" ist, ist genau das fatal.
|
||
|
||
**Präzisierte Anforderung:** Das Bootstrap-Medium sollte auf einem hardwaretechnisch breit ausgestatteten Live-Image basieren (Fedora- oder Ubuntu-Live-artig, mit vollem Firmware-/Treiberumfang), nicht auf einem schlanken Netinstall-Image. Das widerspricht der ursprünglichen Verfeinerung nicht in der Sache, sondern korrigiert nur eine unausgesprochene Annahme darin: „schlank" sollte sich von Anfang an nur auf die UI-Schicht beziehen (kein Fenstermanager, kein Kiosk-Browser, kein Panel, kein dconf) — genau die Problemklasse, die die Verfeinerung zurecht vermeiden wollte, bleibt vermieden, solange das Bootstrap-Medium headless/terminal-only läuft. Das ist orthogonal zur Treiberbreite, nicht identisch damit.
|
||
|
||
**Konkrete Anknüpfung:** Das bestehende, real geprüfte Fedora-Cinnamon-Live-Image ist ein plausibler Ausgangspunkt für das Bootstrap-Medium selbst — WLAN, Server-Handshake, Aktivierung und Bereitstellungsvorlage-Auflösung laufen darauf bereits nachweislich (siehe `milestones.md`). Zu entfernen wäre nur die Kiosk-UI-Ebene (Epiphany-Autostart, Panel-Anpassungen) — die wird für den reinen Bootstrap-Zweck nicht gebraucht. Neu zu bauen ist ausschließlich der Übergangsmechanismus selbst: personalisierte Ziel-ISO vom Server laden, in eine Staging-Partition schreiben, per GRUB `loopback`/`iso-scan` dorthin booten (siehe oben) — dieser Teil existiert bisher nur als Idee, nicht als Code. Der frühere Ansatz (Kickstart aus der laufenden Live-Sitzung heraus starten, per `kexec` oder sonstwie) bleibt verworfen (siehe ADR-Titel und Updates oben).
|
||
|
||
Die Basis-Distribution des Bootstrap-Mediums ist dabei unabhängig von der später installierten Ziel-Distribution wählbar — Fedora-Live zur Wiederverwendung des bereits Vorhandenen, oder Ubuntu-Live wegen möglicherweise noch breiterer Hardwareunterstützung. Offene Frage, noch nicht entschieden.
|