From 8b47751b31500601915c81bfa8be8ad70e47dffc Mon Sep 17 00:00:00 2001 From: Thomas Stallinger Date: Tue, 1 Sep 2026 19:11:59 +0200 Subject: [PATCH] boot-medium: Konsolen-Rauschen bei 40_backend.sh verbergen, toram, neues Banner MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Drei zusammenhaengende Punkte aus dem zweiten echten Hardware-Test (02.09.2026): 1. "Das backend40-Script/Partitionierung zeigt viele Zeilen Ausgaben... Nach dem Entpacken kommen wieder sehr viele Zeilen Ausgaben" - neue run_module_backend() (utils.sh) faengt jetzt auch 40_backend.sh ab (Partitionieren/Formatieren/chroot-Fixup/Bootloader/Postinstall verborgen wie jedes andere Modul), OHNE animierten Kreisel (statischer Titel, da das Modul seinen eigenen Fortschritt zeigt). Der Download- Fortschrittsbalken selbst bleibt sichtbar: curl schreibt ihn bei aktivem TUXFLOTTE_TTY_LIVE direkt auf /dev/tty1, umgeht damit gezielt die stdout/stderr-Umleitung des Moduls (image_deploy.sh). 2. "Wenn ich... mit Enter den Neustart auslösen möchte, kommt es zu zahlreichen squashfs-Fehlern, weil das Dateisystem nicht mehr da ist." - "toram" im Bootappend (build_boot_medium.sh) kopiert das gesamte Boot-Medium beim Start einmalig in eine Tmpfs; danach ist der Stick fuer den laufenden Betrieb komplett irrelevant, ein Ziehen jederzeit gefahrlos moeglich - vorher blieb das laufende System per Squashfs+ Loop-Mount direkt vom physischen Medium abhaengig. 3. Neues Boot-Banner (pics/tuxflotte-terminal-80neu.txt). Beim eigenen Testen von Punkt 1 zwei echte Bugs gefunden+behoben (siehe Kommentare in image_deploy.sh): "pipeline || true" ueberschreibt PIPESTATUS mit dem einelementigen Ergebnis von "true", sobald die Pipeline fehlschlaegt - traf live bei einer echten Netzwerkunterbrechung waehrend des Downloads auf ("pipe_status[1]: unbound variable" unter "set -u"). Der Wechsel auf eine "if"-Bedingung (set -e-Ausnahme ohne ein zweites Kommando) reichte allein nicht, PIPESTATUS blieb bei einem echten, mitten im Transfer abgebrochenen curl|tar manchmal trotzdem unvollstaendig - jetzt zusaetzlich robust mit ":-1"-Fallback direkt auf den einzelnen Indizes statt einer vorausgesetzten vollstaendigen Kopie. Live in QEMU verifiziert: neues Banner + verborgenes Partitionier-Rauschen + sichtbarer Fortschrittsbalken bestaetigt (Screenshot). Eine echte, waehrend des Testens aufgetretene Netzwerk-Durchsatzverschlechterung (anode nur noch ~4,6 MB/s, unabhaengig von diesem Code) verhinderte einen weiteren vollstaendigen Erfolgsdurchlauf in dieser Session - der pipe_status-Fix selbst wurde aber genau durch diese Unterbrechung bestaetigt (sauberer [FEHLER]-Abbruch mit klarer Meldung statt Bash-Crash). toram selbst (Boot bis zum Auto-Modus-Start, Konfiguration/Partitionierung liefen durch) und die Rauschen-Unterdrueckung sind bestaetigt; die volle Stick-waehrend-Reboot-Sequenz bleibt fuer den naechsten echten Hardware-Test zu bestaetigen. --- boot-medium/config/binary | 2 +- .../includes.chroot/opt/tuxflotte/banner.txt | 37 +++++---- .../opt/tuxflotte/scripts/lib/image_deploy.sh | 55 ++++++++++---- .../opt/tuxflotte/scripts/lib/utils.sh | 76 ++++++++++++++++--- scripts/build_boot_medium.sh | 16 +++- scripts/lib/image_deploy.sh | 55 ++++++++++---- scripts/lib/utils.sh | 76 ++++++++++++++++--- 7 files changed, 242 insertions(+), 75 deletions(-) diff --git a/boot-medium/config/binary b/boot-medium/config/binary index 0fffd72..8b67488 100644 --- a/boot-medium/config/binary +++ b/boot-medium/config/binary @@ -10,7 +10,7 @@ LB_BINARY_FILESYSTEM="fat32" LB_APT_INDICES="true" # Set boot parameters -LB_BOOTAPPEND_LIVE="boot=live components quiet splash vconsole.keymap=de" +LB_BOOTAPPEND_LIVE="boot=live components toram quiet splash vconsole.keymap=de" # Set boot parameters LB_BOOTAPPEND_INSTALL="" diff --git a/boot-medium/config/includes.chroot/opt/tuxflotte/banner.txt b/boot-medium/config/includes.chroot/opt/tuxflotte/banner.txt index ec2ff4d..5a1b17a 100644 --- a/boot-medium/config/includes.chroot/opt/tuxflotte/banner.txt +++ b/boot-medium/config/includes.chroot/opt/tuxflotte/banner.txt @@ -1,16 +1,14 @@ - _______ _ ___ ________ _ ____ _______ _______ ______ -|__ __| | | \ \ / / ____| | / __ \__ __|__ __| ____| - | | | | | |\ V /| |__ | | | | | | | | | | | |__ - | | | | | | > < | __| | | | | | | | | | | | __| - | | | |__| |/ . \| | | |___| |__| | | | | | | |____ - |_| \____//_/ \_\_| |______\____/ |_| |_| |______| - - + _______ _ _ __ __ ______ _ ____ _____ _____ ______ + |__ __|| | | | \ \ / / | ____|| | / __ \ |_ _||_ _|| ____| + | | | | | | \ V / | |__ | | | | | | | | | | | |__ + | | | | | | > < | __| | | | | | | | | | | | __| + | | | |__| | / . \ | | | |__ | |__| | | | | | | |____ + |_| \____/ /_/ \_\ |_| |____| \____/ |_| |_| |______| ########## - #### ### + ### ### ## ## - ## ### ## + ## ## ## ## ### ######## ## # ###### ## ### @@ -19,18 +17,19 @@ # ########## ########### # ### ### ### # ### - ## ### ## # - # ## ## ########### - ######### ## # ### ## - #### ## ## ## ## + ## ### ## + # # ## # ######## + ######### ### # # ## ## + #### ## ## # ## ## ### #### - # ### ######### + # ## ######### ############### ## ### ## ## ############## # #### - ## ## - ## ### + ## ### + ## ## # # - # ## - ## # + # # + # # + diff --git a/boot-medium/config/includes.chroot/opt/tuxflotte/scripts/lib/image_deploy.sh b/boot-medium/config/includes.chroot/opt/tuxflotte/scripts/lib/image_deploy.sh index 5a8e435..e530320 100644 --- a/boot-medium/config/includes.chroot/opt/tuxflotte/scripts/lib/image_deploy.sh +++ b/boot-medium/config/includes.chroot/opt/tuxflotte/scripts/lib/image_deploy.sh @@ -215,28 +215,53 @@ image_deploy_extract_image() { image_deploy_extract_image_from_url() { local url="$1" local target="$2" - local pipe_status # "--progress-bar" statt "--silent": mit Abstand der laengste Schritt # der ganzen Installation (Minuten statt Sekunden) - Nutzer-Feedback # (01.09.2026, echter Hardware-Test) wollte hier ausdruecklich eine - # sichtbare Fortschrittsanzeige statt einer stillen Wartezeit. Der - # Balken geht an stderr, unabhaengig vom stdout/stderr-Umleiten des - # restlichen Moduls (siehe TUXFLOTTE_VERBOSE_MODULES in utils.sh - - # 40_backend.sh bleibt deshalb bewusst von der Kreisel-Kompaktdarstellung - # ausgenommen, sonst waere dieser Balken fuer die Person vor dem Geraet - # unsichtbar). + # sichtbare Fortschrittsanzeige statt einer stillen Wartezeit. # - # "|| true" verhindert, dass "set -e" hier sofort abbricht - der - # eigentliche Fehlerfall wird gleich anhand von PIPESTATUS gezielt - # ausgewertet, statt die Pipeline roh durchschlagen zu lassen. - curl --progress-bar --show-error --fail --location "${url}" | - tar --zstd -xpf - -C "${target}" || true - pipe_status=("${PIPESTATUS[@]}") + # run_module_backend() (utils.sh) faengt inzwischen auch die Ausgabe von + # 40_backend.sh ab (Partitionieren/Formatieren/chroot-Fixup/... sollen + # wie jedes andere Modul verborgen bleiben, zweites Nutzer-Feedback + # 01.09.2026) - der Fortschrittsbalken selbst soll trotzdem sichtbar + # bleiben, deshalb schreibt curl ihn hier direkt auf /dev/tty1, statt + # ueber die normale stderr-Umleitung des Moduls zu laufen (die landet + # sonst nur in der Logdatei, nicht auf der Konsole). Nur wenn + # TUXFLOTTE_TTY_LIVE gesetzt ist UND /dev/tty1 tatsaechlich beschreibbar + # ist (z.B. nicht bei einem manuellen Testlauf per SSH) - sonst normaler + # stderr-Weg. Nebenwirkung: curls eigene Fehlermeldung ("curl: (22)...") + # landet im Fehlerfall dann ebenfalls direkt auf der Konsole statt im + # Fehlschlag-Dump - image_deploy_fatal() liefert trotzdem einen klaren + # eigenen Fehlertext. + local progress_target="/dev/stderr" + if [[ "${TUXFLOTTE_TTY_LIVE:-}" == "true" && -w /dev/tty1 ]]; then + progress_target="/dev/tty1" + fi - [[ "${pipe_status[0]}" -eq 0 ]] || + # Echter Bug, zweimal live gefunden (02.09.2026, durch eine echte + # Netzwerkunterbrechung waehrend des Downloads aufgedeckt): "pipeline || + # true" laesst "true" als eigene Ein-Kommando-Pipeline laufen, sobald die + # linke Seite fehlschlaegt - das ueberschreibt PIPESTATUS mit "(0)". Der + # Wechsel auf "if pipeline; then :; fi" (set -e-Ausnahme ohne ein + # zweites Kommando dazwischen) reichte allein aber NICHT aus: bei einem + # echten, mitten im Transfer abgebrochenen curl|tar blieb PIPESTATUS + # trotzdem manchmal unvollstaendig (genauer Mechanismus nicht abschliessend + # geklaert - vermutlich eine Rennsituation zwischen curls eigenem + # Fehler-Reporting und tars sofortigem "Unexpected EOF"-Abbruch). Deshalb + # jetzt zusaetzlich mit ":-1"-Fallback direkt auf den einzelnen + # PIPESTATUS-Indizes statt eine komplette Kopie vorauszusetzen - robust + # unabhaengig davon, wie viele Elemente PIPESTATUS tatsaechlich liefert. + if curl --progress-bar --show-error --fail --location "${url}" 2>"${progress_target}" | + tar --zstd -xpf - -C "${target}"; then + : + fi + local curl_status="${PIPESTATUS[0]:-1}" + local tar_status="${PIPESTATUS[1]:-1}" + + [[ "${curl_status}" -eq 0 ]] || { image_deploy_fatal "Golden Image konnte nicht geladen werden: ${url}"; return 1; } - [[ "${pipe_status[1]}" -eq 0 ]] || + [[ "${tar_status}" -eq 0 ]] || { image_deploy_fatal "Golden Image konnte nicht nach ${target} entpackt werden"; return 1; } image_deploy_restore_excluded_dirs "${target}" diff --git a/boot-medium/config/includes.chroot/opt/tuxflotte/scripts/lib/utils.sh b/boot-medium/config/includes.chroot/opt/tuxflotte/scripts/lib/utils.sh index 09fea4e..287d909 100644 --- a/boot-medium/config/includes.chroot/opt/tuxflotte/scripts/lib/utils.sh +++ b/boot-medium/config/includes.chroot/opt/tuxflotte/scripts/lib/utils.sh @@ -12,20 +12,20 @@ load_config() { fi } -# Module, die auch im Auto-Modus verbose bleiben (keine Kreisel/Haken- -# Kompaktdarstellung, siehe run_module_quiet()): 40_backend.sh ist der mit -# Abstand langlaeufigste Schritt (Minuten statt Sekunden, Golden-Image- -# Download+Extraktion) - hier bleibt die eigene Schritt-fuer-Schritt- -# Ausgabe (Partitionieren/Formatieren/... + der Download-Fortschrittsbalken, -# siehe image_deploy_extract_image_from_url()) sichtbar, statt hinter einem -# einzelnen Kreisel zu verschwinden. -declare -a TUXFLOTTE_VERBOSE_MODULES=(40_backend.sh) +# Module mit einem eigenen Modus (weder die generische Kreisel/Haken- +# Kompaktdarstellung noch voll verbose): 40_backend.sh ist der mit Abstand +# langlaeufigste Schritt (Minuten statt Sekunden) - Partitionieren/ +# Formatieren/chroot-Fixup/Bootloader/Postinstall sind fuer den Kunden +# ebenso uninteressant wie bei jedem anderen Modul, ABER der Download- +# Fortschrittsbalken (image_deploy_extract_image_from_url()) soll trotzdem +# sichtbar bleiben - siehe run_module_backend(). +declare -a TUXFLOTTE_BACKEND_MODULES=(40_backend.sh) -_tuxflotte_module_is_verbose() { +_tuxflotte_module_is_backend() { local module_name="$1" local candidate - for candidate in "${TUXFLOTTE_VERBOSE_MODULES[@]}"; do + for candidate in "${TUXFLOTTE_BACKEND_MODULES[@]}"; do [[ "${candidate}" == "${module_name}" ]] && return 0 done @@ -87,6 +87,54 @@ run_module_quiet() { return "${status}" } +# Wie run_module_quiet(), aber ohne animierten Kreisel: der Titel wird +# einmalig mit Zeilenumbruch ausgegeben (nicht per "\r" ueberschrieben) und +# das Modul laeuft im Vordergrund (kein Hintergrundprozess noetig, da kein +# Kreisel dagegen ankaempft). Grund: image_deploy_extract_image_from_url() +# schreibt den Download-Fortschrittsbalken bei aktivem TUXFLOTTE_TTY_LIVE +# direkt auf /dev/tty1 (siehe dort) - das umgeht die stdout/stderr- +# Umleitung dieser Funktion bewusst, landet also auf einer eigenen, +# unbenutzten Zeile direkt unter dem Titel, statt mit einem "\r"-Kreisel +# um dieselbe Zeile zu konkurrieren. +# +# Nutzer-Feedback (01.09.2026, zweiter echter Hardware-Test): "Das +# backend40-Script/Partitionierung zeigt viele Zeilen Ausgaben... Der +# Fortschrittsbalken ist super! Nach dem Entpacken kommen wieder sehr +# viele Zeilen Ausgaben" - Partitionieren/Formatieren/chroot-Fixup/ +# Bootloader/Postinstall sollen wie jedes andere Modul verborgen bleiben, +# nur der Fortschrittsbalken bleibt sichtbar. +run_module_backend() { + local module="$1" + local module_name + module_name="$(basename "${module}")" + + log_module_title "${module_name}" + local title="${TUXFLOTTE_CURRENT_TITLE}" + printf '%s ...\n' "${title}" + + local output_file + output_file="$(mktemp)" + + local status=0 + # shellcheck disable=SC1090 + "${module}" >"${output_file}" 2>&1 || status=$? + + if [[ "${status}" -eq 0 ]]; then + printf '%s \033[1;32m[OK]\033[0m\n' "${title}" + else + printf '%s \033[1;31m[FEHLER]\033[0m\n' "${title}" + echo + cat "${output_file}" + echo + fi + + [[ -n "${TUXFLOTTE_LOG_FILE:-}" ]] && cat "${output_file}" >>"${TUXFLOTTE_LOG_FILE}" 2>/dev/null + + rm -f "${output_file}" + + return "${status}" +} + run_module() { local module="$1" local mode="${2:-normal}" @@ -107,8 +155,12 @@ run_module() { # pruefen TUXFLOTTE_AUTO_MODE selbst und ueberspringen ihre Prompts) - # ein Prompt-Text waere sonst zusammen mit der restlichen Ausgabe in # output_file gefangen und fuer die Person vor dem Geraet unsichtbar. - if [[ "${TUXFLOTTE_AUTO_MODE:-false}" == "true" ]] && ! _tuxflotte_module_is_verbose "${module_name}"; then - run_module_quiet "$module" + if [[ "${TUXFLOTTE_AUTO_MODE:-false}" == "true" ]]; then + if _tuxflotte_module_is_backend "${module_name}"; then + run_module_backend "$module" + else + run_module_quiet "$module" + fi return "$?" fi diff --git a/scripts/build_boot_medium.sh b/scripts/build_boot_medium.sh index 09153f1..e0d8fe3 100755 --- a/scripts/build_boot_medium.sh +++ b/scripts/build_boot_medium.sh @@ -17,6 +17,20 @@ set -Eeuo pipefail # SSH deaktiviert, keine gebackenen Zugangsdaten (Produktiv-Default, # konsistent damit, dass auch das Golden Image selbst keine Zugangsdaten # enthaelt). Siehe boot-medium/config/hooks/live/0900-tuxflotte-ssh-mode.hook.chroot. +# +# "toram" im Bootappend (02.09.2026, echter Hardware-Test): ohne dieses +# Flag bleibt das laufende System ueber Squashfs+Loop-Mount direkt vom +# physischen Boot-Medium abhaengig - zieht der Kunde den USB-Stick, sobald +# er dazu aufgefordert wird (siehe "Fertig!"-Hinweis in backend.sh), noch +# WAEHREND des anschliessenden Reboot-Shutdowns, verliert das noch +# laufende System mitten im Herunterfahren seine eigene Root-Partition - +# Ergebnis waren zahlreiche Squashfs-I/O-Fehler. "toram" kopiert das ganze +# Boot-Medium beim Start einmalig in eine Tmpfs (RAM) - danach ist der Stick +# fuer den laufenden Betrieb komplett irrelevant, ein Ziehen jederzeit +# gefahrlos moeglich. Kostet etwas Bootzeit (das ganze Medium, ~700 MB, +# muss zuerst einmal komplett gelesen werden) und etwas mehr RAM +# waehrenddessen - auf jeder Zielhardware, die ueberhaupt Linux Mint +# Cinnamon stemmen soll, unproblematisch. usage() { echo "Usage: $0 [--dev]" >&2 @@ -71,7 +85,7 @@ lb config \ --binary-images iso-hybrid \ --bootloaders "grub-efi,syslinux" \ --debian-installer none \ - --bootappend-live "boot=live components quiet splash vconsole.keymap=de" + --bootappend-live "boot=live components toram quiet splash vconsole.keymap=de" echo "==> lb build" lb build diff --git a/scripts/lib/image_deploy.sh b/scripts/lib/image_deploy.sh index 5a8e435..e530320 100644 --- a/scripts/lib/image_deploy.sh +++ b/scripts/lib/image_deploy.sh @@ -215,28 +215,53 @@ image_deploy_extract_image() { image_deploy_extract_image_from_url() { local url="$1" local target="$2" - local pipe_status # "--progress-bar" statt "--silent": mit Abstand der laengste Schritt # der ganzen Installation (Minuten statt Sekunden) - Nutzer-Feedback # (01.09.2026, echter Hardware-Test) wollte hier ausdruecklich eine - # sichtbare Fortschrittsanzeige statt einer stillen Wartezeit. Der - # Balken geht an stderr, unabhaengig vom stdout/stderr-Umleiten des - # restlichen Moduls (siehe TUXFLOTTE_VERBOSE_MODULES in utils.sh - - # 40_backend.sh bleibt deshalb bewusst von der Kreisel-Kompaktdarstellung - # ausgenommen, sonst waere dieser Balken fuer die Person vor dem Geraet - # unsichtbar). + # sichtbare Fortschrittsanzeige statt einer stillen Wartezeit. # - # "|| true" verhindert, dass "set -e" hier sofort abbricht - der - # eigentliche Fehlerfall wird gleich anhand von PIPESTATUS gezielt - # ausgewertet, statt die Pipeline roh durchschlagen zu lassen. - curl --progress-bar --show-error --fail --location "${url}" | - tar --zstd -xpf - -C "${target}" || true - pipe_status=("${PIPESTATUS[@]}") + # run_module_backend() (utils.sh) faengt inzwischen auch die Ausgabe von + # 40_backend.sh ab (Partitionieren/Formatieren/chroot-Fixup/... sollen + # wie jedes andere Modul verborgen bleiben, zweites Nutzer-Feedback + # 01.09.2026) - der Fortschrittsbalken selbst soll trotzdem sichtbar + # bleiben, deshalb schreibt curl ihn hier direkt auf /dev/tty1, statt + # ueber die normale stderr-Umleitung des Moduls zu laufen (die landet + # sonst nur in der Logdatei, nicht auf der Konsole). Nur wenn + # TUXFLOTTE_TTY_LIVE gesetzt ist UND /dev/tty1 tatsaechlich beschreibbar + # ist (z.B. nicht bei einem manuellen Testlauf per SSH) - sonst normaler + # stderr-Weg. Nebenwirkung: curls eigene Fehlermeldung ("curl: (22)...") + # landet im Fehlerfall dann ebenfalls direkt auf der Konsole statt im + # Fehlschlag-Dump - image_deploy_fatal() liefert trotzdem einen klaren + # eigenen Fehlertext. + local progress_target="/dev/stderr" + if [[ "${TUXFLOTTE_TTY_LIVE:-}" == "true" && -w /dev/tty1 ]]; then + progress_target="/dev/tty1" + fi - [[ "${pipe_status[0]}" -eq 0 ]] || + # Echter Bug, zweimal live gefunden (02.09.2026, durch eine echte + # Netzwerkunterbrechung waehrend des Downloads aufgedeckt): "pipeline || + # true" laesst "true" als eigene Ein-Kommando-Pipeline laufen, sobald die + # linke Seite fehlschlaegt - das ueberschreibt PIPESTATUS mit "(0)". Der + # Wechsel auf "if pipeline; then :; fi" (set -e-Ausnahme ohne ein + # zweites Kommando dazwischen) reichte allein aber NICHT aus: bei einem + # echten, mitten im Transfer abgebrochenen curl|tar blieb PIPESTATUS + # trotzdem manchmal unvollstaendig (genauer Mechanismus nicht abschliessend + # geklaert - vermutlich eine Rennsituation zwischen curls eigenem + # Fehler-Reporting und tars sofortigem "Unexpected EOF"-Abbruch). Deshalb + # jetzt zusaetzlich mit ":-1"-Fallback direkt auf den einzelnen + # PIPESTATUS-Indizes statt eine komplette Kopie vorauszusetzen - robust + # unabhaengig davon, wie viele Elemente PIPESTATUS tatsaechlich liefert. + if curl --progress-bar --show-error --fail --location "${url}" 2>"${progress_target}" | + tar --zstd -xpf - -C "${target}"; then + : + fi + local curl_status="${PIPESTATUS[0]:-1}" + local tar_status="${PIPESTATUS[1]:-1}" + + [[ "${curl_status}" -eq 0 ]] || { image_deploy_fatal "Golden Image konnte nicht geladen werden: ${url}"; return 1; } - [[ "${pipe_status[1]}" -eq 0 ]] || + [[ "${tar_status}" -eq 0 ]] || { image_deploy_fatal "Golden Image konnte nicht nach ${target} entpackt werden"; return 1; } image_deploy_restore_excluded_dirs "${target}" diff --git a/scripts/lib/utils.sh b/scripts/lib/utils.sh index 09fea4e..287d909 100644 --- a/scripts/lib/utils.sh +++ b/scripts/lib/utils.sh @@ -12,20 +12,20 @@ load_config() { fi } -# Module, die auch im Auto-Modus verbose bleiben (keine Kreisel/Haken- -# Kompaktdarstellung, siehe run_module_quiet()): 40_backend.sh ist der mit -# Abstand langlaeufigste Schritt (Minuten statt Sekunden, Golden-Image- -# Download+Extraktion) - hier bleibt die eigene Schritt-fuer-Schritt- -# Ausgabe (Partitionieren/Formatieren/... + der Download-Fortschrittsbalken, -# siehe image_deploy_extract_image_from_url()) sichtbar, statt hinter einem -# einzelnen Kreisel zu verschwinden. -declare -a TUXFLOTTE_VERBOSE_MODULES=(40_backend.sh) +# Module mit einem eigenen Modus (weder die generische Kreisel/Haken- +# Kompaktdarstellung noch voll verbose): 40_backend.sh ist der mit Abstand +# langlaeufigste Schritt (Minuten statt Sekunden) - Partitionieren/ +# Formatieren/chroot-Fixup/Bootloader/Postinstall sind fuer den Kunden +# ebenso uninteressant wie bei jedem anderen Modul, ABER der Download- +# Fortschrittsbalken (image_deploy_extract_image_from_url()) soll trotzdem +# sichtbar bleiben - siehe run_module_backend(). +declare -a TUXFLOTTE_BACKEND_MODULES=(40_backend.sh) -_tuxflotte_module_is_verbose() { +_tuxflotte_module_is_backend() { local module_name="$1" local candidate - for candidate in "${TUXFLOTTE_VERBOSE_MODULES[@]}"; do + for candidate in "${TUXFLOTTE_BACKEND_MODULES[@]}"; do [[ "${candidate}" == "${module_name}" ]] && return 0 done @@ -87,6 +87,54 @@ run_module_quiet() { return "${status}" } +# Wie run_module_quiet(), aber ohne animierten Kreisel: der Titel wird +# einmalig mit Zeilenumbruch ausgegeben (nicht per "\r" ueberschrieben) und +# das Modul laeuft im Vordergrund (kein Hintergrundprozess noetig, da kein +# Kreisel dagegen ankaempft). Grund: image_deploy_extract_image_from_url() +# schreibt den Download-Fortschrittsbalken bei aktivem TUXFLOTTE_TTY_LIVE +# direkt auf /dev/tty1 (siehe dort) - das umgeht die stdout/stderr- +# Umleitung dieser Funktion bewusst, landet also auf einer eigenen, +# unbenutzten Zeile direkt unter dem Titel, statt mit einem "\r"-Kreisel +# um dieselbe Zeile zu konkurrieren. +# +# Nutzer-Feedback (01.09.2026, zweiter echter Hardware-Test): "Das +# backend40-Script/Partitionierung zeigt viele Zeilen Ausgaben... Der +# Fortschrittsbalken ist super! Nach dem Entpacken kommen wieder sehr +# viele Zeilen Ausgaben" - Partitionieren/Formatieren/chroot-Fixup/ +# Bootloader/Postinstall sollen wie jedes andere Modul verborgen bleiben, +# nur der Fortschrittsbalken bleibt sichtbar. +run_module_backend() { + local module="$1" + local module_name + module_name="$(basename "${module}")" + + log_module_title "${module_name}" + local title="${TUXFLOTTE_CURRENT_TITLE}" + printf '%s ...\n' "${title}" + + local output_file + output_file="$(mktemp)" + + local status=0 + # shellcheck disable=SC1090 + "${module}" >"${output_file}" 2>&1 || status=$? + + if [[ "${status}" -eq 0 ]]; then + printf '%s \033[1;32m[OK]\033[0m\n' "${title}" + else + printf '%s \033[1;31m[FEHLER]\033[0m\n' "${title}" + echo + cat "${output_file}" + echo + fi + + [[ -n "${TUXFLOTTE_LOG_FILE:-}" ]] && cat "${output_file}" >>"${TUXFLOTTE_LOG_FILE}" 2>/dev/null + + rm -f "${output_file}" + + return "${status}" +} + run_module() { local module="$1" local mode="${2:-normal}" @@ -107,8 +155,12 @@ run_module() { # pruefen TUXFLOTTE_AUTO_MODE selbst und ueberspringen ihre Prompts) - # ein Prompt-Text waere sonst zusammen mit der restlichen Ausgabe in # output_file gefangen und fuer die Person vor dem Geraet unsichtbar. - if [[ "${TUXFLOTTE_AUTO_MODE:-false}" == "true" ]] && ! _tuxflotte_module_is_verbose "${module_name}"; then - run_module_quiet "$module" + if [[ "${TUXFLOTTE_AUTO_MODE:-false}" == "true" ]]; then + if _tuxflotte_module_is_backend "${module_name}"; then + run_module_backend "$module" + else + run_module_quiet "$module" + fi return "$?" fi