From 3a7cdf47adb5798d4e13e8becd1e17341a1fa1af Mon Sep 17 00:00:00 2001 From: Thomas Stallinger Date: Thu, 23 Jul 2026 13:45:37 +0200 Subject: [PATCH] docs: refine ADR-0009 ultima ratio with a generic staged-ISO bootstrap medium Instead of customers flashing a different physical stick per workspace/ distro combination, one slim generic bootstrap medium (no live desktop needed) stages the server-built personalized distro ISO into a small partition on the target disk and boots it directly via GRUB loopback/ iso-scan (the same pattern Ventoy uses in production). The staging partition is deliberately ephemeral - the real install's own partitioning step wipes it along with the rest of the disk, keeping Tuxflotte's own disk-touching code to a throwaway staging area only, clearly inside the boundary already drawn against reimplementing the actual install logic. Also records the assessment that this is a genuine architectural simplification, not just an Anaconda-specific workaround: it removes the entire class of live-desktop/EROFS friction from recent days and fits the project's own "orchestrate native installers" philosophy better than the live-kiosk approach did. Co-Authored-By: Claude Sonnet 5 --- adr/0009-anaconda-live-kickstart-verworfen.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/adr/0009-anaconda-live-kickstart-verworfen.md b/adr/0009-anaconda-live-kickstart-verworfen.md index 1dbfbc6..74b3f6d 100644 --- a/adr/0009-anaconda-live-kickstart-verworfen.md +++ b/adr/0009-anaconda-live-kickstart-verworfen.md @@ -62,3 +62,15 @@ Der Kunde legt sich im (künftigen) Self-Service-Portal auf Workspace, Backend/D 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.