Thomas Stallinger
8615d9fde1
Nutzer-Feedback (01.09.2026, echter Hardware-Test) mit mehreren
zusammenhaengenden Konsolen-UX-Punkten:
- "Die Darstellung des Abarbeitens der Skripte und Module ist noch nicht
schön... Modul XY läuft (kreiselnde Symbole)... gründer Haken als
erledigt" - neue run_module_quiet() (utils.sh) fuehrt ein Modul im
Hintergrund aus, zeigt waehrenddessen einen Kreisel auf derselben Zeile,
am Ende [OK] (gruen) oder [FEHLER] (rot) + volle mitgeschnittene Ausgabe
bei einem Fehlschlag. Nur im echten Auto-Modus aktiv (dort fragt kein
Modul interaktiv nach) - 40_backend.sh bleibt bewusst verbose
(TUXFLOTTE_VERBOSE_MODULES), da dort der neue Download-Fortschrittsbalken
sichtbar bleiben soll.
- "Bei Entpacken und schreiben des Archivs, kann man das einen
Fortschrittsbalken... anzeigen lassen?" - curl "--silent" durch
"--progress-bar" ersetzt (image_deploy.sh).
- "Der Kernel Zeitstempel ist für den Kunden nicht interessant, sondern
nur verwirrend." - eigentliche Ursache war nicht der GRUB-Splash
(separater Commit), sondern StandardOutput=journal+console im
systemd-Unit: journald spiegelt Konsolenausgaben im kmsg-Stil mit
monotonem "[ 12.345678]"-Zeitstempel, sah aus wie ein Kernel-Log.
Jetzt "StandardOutput/Error=console" (direkt an /dev/tty1, kein
journald) - journalctl zeigt dadurch nur noch Dienst-Lebenszyklus-
Meldungen, die volle Ausgabe bleibt vollstaendig in
/var/log/tuxflotte-installer.log (bereits der dokumentierte Weg).
Zwei echte Bugs beim eigenen Boot-Test dieser Aenderung gefunden+behoben:
(1) log_module_title() gab den Titel per Command-Substitution zurueck -
lief dadurch in einer Subshell, der TUXFLOTTE_STEP_COUNT-Zaehler blieb
immer bei 1 stehen ("[1/12]" bei jedem Modul). Jetzt ueber eine globale
TUXFLOTTE_CURRENT_TITLE-Variable statt Command-Substitution.
(2) Unicode-Kreisel (⠋⠙...) und Haken (✓/✗) wurden von der
vt-Konsolenschriftart nicht abgedeckt, zeigten nur einen generischen
Ersatz-Kasten - auf reines ASCII (|/-\, "[OK]"/"[FEHLER]") umgestellt,
garantiert auf jeder Konsolenschriftart lesbar.
Ausserdem: Beep + "Stick jetzt entfernen"-Hinweis + ENTER-Bestaetigung
(oder automatischer Neustart nach 5 Minuten) direkt vor dem finalen
Reboot in backend.sh (separater Commit, siehe backend_postinstall()).
Live in QEMU boot-getestet (Zaehler/Farben/Kreisel im Rohlog verifiziert,
kompletter Auto-Modus-Durchlauf inkl. Fehlerfall-Dump getestet, voller
End-to-End-Durchlauf bis zum echten Mint-Cinnamon-Login-Bildschirm nach
Reboot bestaetigt).
Tuxflotte Installer
Dieses Repository erzeugt die Tuxflotte-Provisioning-ISO.
Die ISO dient als universelles Installationsmedium für Tuxflotte Provisioning.
Ziele:
- automatischer Start der Installation
- Unterstützung mehrerer Distributionen
- einheitlicher Bootstrap
- WLAN-Unterstützung
- Rescue-Modus
- lokaler Festplattenstart
Die eigentliche Provisionierung erfolgt über den Tuxflotte Provisioning Server.
Boot-Medium (Mint)
Das Mint-Boot-Medium ist ein eigenständiges, per Debian live-build
gebautes Image (boot-medium/, siehe ADR-0025) - kein gepatchter
Distributions-Installer mehr. Es enthält nur Tuxflottes eigenen,
headless-tauglichen Code (Module scripts/modules/00-40,
backends/mint-image/) und bootet direkt in einen systemd-Dienst, der
installer.sh startet.
scripts/build_boot_medium.sh [--dev]baut das Basis-Image (boot-medium/live-image-amd64.hybrid.iso).--devaktiviert einen SSH-Debug-Zugang (tuxflotte/test123); ohne--devbleibt SSH deaktiviert (Produktiv-Default).scripts/build_customer_iso.sh <source.iso> <output.iso> <activation_code> [wifi_ssid] [wifi_psk] [volid]personalisiert ein bereits gebautes Basis-Image für eine konkrete Kundenorganisation (Aktivierungscode + WLAN-Zugangsdaten).
Fedora nutzt weiterhin das ältere Kickstart/Anaconda-Muster
(scripts/build.sh <source.iso> fedora) - noch nicht auf dasselbe
Boot-Medium-Muster umgestellt.