From 8a7ea7192f561bbdc88d6c106c6194e2a69df91c Mon Sep 17 00:00:00 2001 From: Thomas Stallinger Date: Mon, 20 Jul 2026 15:01:23 +0200 Subject: [PATCH] docs: record first successful end-to-end live-ISO provisioning run Replaces the stale "not yet implemented" note for installer.sh autostart with the actual mechanism (dracut's official 20-apply-live-updates.sh pre-pivot hook via a top-level /updates/ directory, not squashfs/EROFS remastering - that image is EROFS despite the filename, and hit a reproducible erofs-utils extraction bug even freshly built from source). Adds the milestone entry for the first clean end-to-end run through every module, live in Proxmox. --- architecture/13-live-provisioning-boot.md | 19 +++++++++++-- roadmap/milestones.md | 34 +++++++++++++++++++++++ 2 files changed, 51 insertions(+), 2 deletions(-) diff --git a/architecture/13-live-provisioning-boot.md b/architecture/13-live-provisioning-boot.md index 4a0eef1..4e3e940 100644 --- a/architecture/13-live-provisioning-boot.md +++ b/architecture/13-live-provisioning-boot.md @@ -105,7 +105,7 @@ Zwei getrennte Anwendungsfälle: 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` soll den gewählten Modus zur Laufzeit aus `/proc/cmdline` lesen (siehe „Noch nicht umgesetzt" unten). +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`) sowie `vconsole.keymap=de`. `installer.sh` soll den gewählten Modus zur Laufzeit aus `/proc/cmdline` lesen (siehe „Noch nicht umgesetzt" unten) — aktuell durchläuft es unabhängig vom Flag immer den vollständigen interaktiven Ablauf. 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). @@ -113,7 +113,22 @@ Das GRUB-Menü verwendet einen Countdown von 10 Sekunden; der Auto-Eintrag ist I Das Menü verwendet ein Farbschema in Markenblau (`color_normal=blue/white`, `color_highlight=white/blue`, angelehnt an `rgb(52,101,164)` aus `pics/tuxflotte-beschriftet-schatten.svg`). Das Logo selbst lässt sich darin nicht darstellen: Klassisches `gfxterm` malt bei jeder Zeichenzelle einen deckenden Hintergrund, wodurch ein `background_image` vollständig verdeckt wird — geprüft durch tatsächliches Booten der Variante mit Logo in QEMU. Ein sichtbares Logo bräuchte die GRUB-Theme-Engine (`gfxmenu`/`theme.txt`), die diese Live-ISO nicht mitbringt (leeres `/boot/grub2/themes`, kein `x86_64-efi`-Modulverzeichnis). Das Logo ist deshalb für den Plymouth-Bootsplash oder den Live-Desktop-Hintergrund vorgesehen, nicht für das GRUB-Menü. -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. +### Autostart von installer.sh + +Das Installer-Payload wird **nicht** in `/LiveOS/squashfs.img` integriert — dieses Image ist trotz des Namens EROFS statt SquashFS, und die einzige verfügbare `erofs-utils`-Tooling-Version (auch frisch aus dem Quellcode gebaut) extrahiert das gepackte/fragmentierte Inode dieses konkreten Images fehlerhaft. + +Stattdessen nutzt der Build den offiziellen Dracut-Hook `20-apply-live-updates.sh` (`var/lib/dracut/hooks/pre-pivot/`): Ein `updates/`-Verzeichnis direkt auf dem Boot-Medium (nicht im komprimierten Image) wird von Dracut automatisch vollständig in das Live-Root kopiert, bevor die Live-Sitzung startet — ganz ohne Image-Remastering. + +`scripts/build.sh` (`prepare_updates()`) baut dieses Verzeichnis zur Build-Zeit aus `scripts/`, `backends/`, `config/` (unter `/opt/tuxflotte`) sowie `live-updates/etc/` zusammen: + +- `etc/xdg/autostart/tuxflotte-installer.desktop` — startet beim Anmelden von `liveuser` automatisch ein Terminal mit `installer.sh` als root. +- `etc/sudoers.d/90-tuxflotte` — `liveuser` erhält passwortloses sudo (angemessen für diese Wegwerf-Live-Umgebung). + +xorriso übernimmt beim `-map` die Berechtigungen der lokalen Quelldateien in die ISO. Da `liveuser`s uid (1000) sonst mitkopiert würde und `sudo` root-fremde `sudoers.d`-Dateien verweigert, setzt der Build `-chown_r 0 /updates -- -chgrp_r 0 /updates --` explizit auf das gesamte `updates/`-Verzeichnis — ganz ohne lokales root beim Bauen. + +Verifiziert per vollständigem Live-Boot in Proxmox: Autostart-Terminal öffnet sich zuverlässig, `installer.sh` durchläuft alle Module bis zum sauberen Exit (siehe `roadmap/milestones.md`, 2026-07-20). + +Noch nicht umgesetzt: `installer.sh` liest `tuxflotte.mode` noch nicht aus und durchläuft deshalb immer den vollständigen interaktiven Ablauf, unabhängig vom gewählten Bootmenüeintrag. `backend_launch()`/`backend_postinstall()` bleiben Phase-1-Stubs — der native Installer wird noch nicht tatsächlich gestartet. --- diff --git a/roadmap/milestones.md b/roadmap/milestones.md index 77e6de6..64ba64c 100644 --- a/roadmap/milestones.md +++ b/roadmap/milestones.md @@ -1,5 +1,39 @@ # Milestones +## 2026-07-20 + +### First successful end-to-end interactive provisioning run on the live ISO + +The full interactive provisioning pipeline ran successfully for the first time inside the live-ISO boot chain introduced in ADR-0003, from GRUB through `installer.sh` to a clean exit — tested live in Proxmox. + +Boot flow: + +GRUB (Tuxflotte entry, live medium) +→ Cinnamon live session autostarts a terminal (dracut pre-pivot `/updates` hook, no squashfs/EROFS modification) +→ installer.sh runs every module in sequence: +00_preflight → 05_network → 10_hardware → 12_enrollment_auth → 15_server_handshake → 17_device_status → 20_profile_selection → 25_installation_confirm → 30_runtime_blueprint → 40_backend (full Fedora backend lifecycle) → 20_storage → 99_finish + +Verified components: + +* Live-ISO boot with the GRUB auto/interactive entries (ADR-0003) +* Dracut `20-apply-live-updates.sh` hook injecting `/opt/tuxflotte` and autostart/sudoers config, no image remastering +* Device activation and enrollment against the real provisioning server +* Bereitstellungsvorlage selection and Commit Point confirmation +* Runtime Blueprint resolution against the real server (`fedora`/`schulcomputer` keys, not UUIDs) +* Full Fedora backend lifecycle (`backend_init` → `validate` → `generate_config` → `launch` → `postinstall`) +* Disk detection (`20_storage.sh`) + +Bugs found and fixed only by this live run (none reproducible from isolated testing): + +* `05_network.sh` crashed on live/ephemeral NetworkManager connections without a backing keyfile +* `20_storage.sh` was a pre-existing stub that never sourced the functions it called +* Missing execute bit on `backend.sh`, `30_runtime_blueprint.sh`, `40_backend.sh` (only ever tested via manually-chmod'd copies) +* sudoers.d drop-in needs explicit root ownership set via `xorriso -chown_r`/`-chgrp_r`, since the build has no local root + +Result: + +The live-ISO architecture from ADR-0003 is validated end-to-end, not just at the boot-menu level. `backend_launch()`/`backend_postinstall()` remain Phase 1 stubs — the native installer is not yet actually started. + ## 2026-06-16 ### First successful unattended Fedora installation