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).
64 lines
3.2 KiB
Bash
Executable File
64 lines
3.2 KiB
Bash
Executable File
#!/usr/bin/env bash
|
|
set -Eeuo pipefail
|
|
|
|
# Wird von tuxflotte-installer.service beim Boot direkt auf tty1 gestartet -
|
|
# unabhaengig davon, ob config/installer.conf einen Auto-Modus-
|
|
# Aktivierungscode mitbringt (personalisierte Kunden-ISO, siehe
|
|
# scripts/build_customer_iso.sh) oder nicht (generisches Test-/
|
|
# Entwicklungsabbild): installer.sh fragt in letzterem Fall selbst
|
|
# interaktiv nach (12_enrollment_auth.sh, 05_network.sh-WLAN-Auswahl), auf
|
|
# genau dieser Konsole - der Service leitet dafuer TTYPath=/dev/tty1 durch.
|
|
#
|
|
# Schreibt zusaetzlich zur journal-Ausgabe (StandardOutput=journal+console
|
|
# im systemd-Unit) in eine Logdatei - per SSH/Konsole nachtraeglich
|
|
# einsehbar, ohne journalctl zu brauchen.
|
|
LOG_FILE="/var/log/tuxflotte-installer.log"
|
|
BANNER_FILE="/opt/tuxflotte/banner.txt"
|
|
|
|
# Begruessungsbanner (Tuxflotte-Schriftzug + Flotten-Grafik, 80 Spalten) -
|
|
# reine Optik, ins Logfile mitschreiben schadet nicht, aber nicht fatal
|
|
# wenn die Datei mal fehlt (set -e: "if" statt "&&", sonst wuerde ein
|
|
# fehlendes Banner das ganze Skript beenden).
|
|
if [[ -r "${BANNER_FILE}" ]]; then
|
|
{ cat "${BANNER_FILE}"; echo; } | tee -a "${LOG_FILE}"
|
|
fi
|
|
|
|
# TUXFLOTTE_TTY_LIVE steuert, ob log_module_ok()/log_module_failed()
|
|
# (logging.sh) Kreisel/Haken mit ANSI-Fettschrift/Farbe zeigen oder einen
|
|
# reinen Klartext-Fallback. "-t 1" selbst ist hier IMMER falsch: das
|
|
# systemd-Unit setzt "StandardOutput=journal+console" (siehe
|
|
# tuxflotte-installer.service) - fd1 dieses Prozesses ist deshalb ein
|
|
# Journal-Socket, kein rohes tty-Zeichengeraet, ganz unabhaengig von der
|
|
# "installer.sh | tee"-Pipe weiter unten. journald spiegelt die Bytes
|
|
# trotzdem unveraendert (inkl. ANSI-Escapes) auf die echte Konsole - live
|
|
# gefunden (01.09.2026, QEMU-Regressionstest): mit "-t 1" als Kriterium
|
|
# blieb die geplante Fettschrift/Kreisel-Darstellung auf der echten Konsole
|
|
# deshalb IMMER inaktiv (Klartext-Fallback), obwohl ein Mensch am Geraet
|
|
# echte ANSI-Codes zu sehen bekommen haette. Da dieses Skript ausschliesslich
|
|
# ueber genau dieses systemd-Unit gestartet wird, ist "immer aktiv" hier die
|
|
# richtige, zuverlaessige Antwort - "-t 1" bleibt in logging.sh als Fallback
|
|
# fuer andere Aufrufkontexte (z.B. installer.sh manuell per SSH-Pty).
|
|
export TUXFLOTTE_TTY_LIVE=true
|
|
export TUXFLOTTE_LOG_FILE="${LOG_FILE}"
|
|
|
|
/opt/tuxflotte/scripts/installer.sh 2>&1 | tee -a "${LOG_FILE}"
|
|
STATUS="${PIPESTATUS[0]}"
|
|
|
|
# Live gefunden (31.08.2026): ein ExecStopPost, der beim Dienstende
|
|
# getty@tty1.service neu startet, ist unzuverlaessig (Race mit dem eigenen
|
|
# TTY-Teardown dieses Dienstes - der Job wurde angestossen, blieb aber
|
|
# "inactive/dead"). Stattdessen: diese Konsole faellt nach installer.sh
|
|
# (egal ob Erfolg, kontrollierter Abbruch an einem Commit-Gate, oder
|
|
# Fehler) deterministisch in eine interaktive Root-Shell - kein Race,
|
|
# garantiert nutzbare Konsole fuer Fehlersuche/manuellen Neustart. Im
|
|
# Erfolgsfall mit tatsaechlichem Deployment loest 40_backend.sh ohnehin
|
|
# selbst einen Reboot aus, wodurch diese Shell nie sichtbar wird.
|
|
{
|
|
echo
|
|
echo "Tuxflotte-Installer beendet (Exit-Code: ${STATUS})."
|
|
echo "Diese Konsole steht fuer Fehlersuche/manuellen Neustart zur Verfuegung."
|
|
echo
|
|
} | tee -a "${LOG_FILE}"
|
|
|
|
exec /bin/bash --login
|