boot-medium: Konsolen-Rauschen bei 40_backend.sh verbergen, toram, neues Banner
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.
This commit is contained in:
parent
d496adad09
commit
8b47751b31
@ -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=""
|
||||
|
||||
@ -1,16 +1,14 @@
|
||||
_______ _ ___ ________ _ ____ _______ _______ ______
|
||||
|__ __| | | \ \ / / ____| | / __ \__ __|__ __| ____|
|
||||
| | | | | |\ V /| |__ | | | | | | | | | | | |__
|
||||
| | | | | | > < | __| | | | | | | | | | | | __|
|
||||
| | | |__| |/ . \| | | |___| |__| | | | | | | |____
|
||||
|_| \____//_/ \_\_| |______\____/ |_| |_| |______|
|
||||
|
||||
|
||||
_______ _ _ __ __ ______ _ ____ _____ _____ ______
|
||||
|__ __|| | | | \ \ / / | ____|| | / __ \ |_ _||_ _|| ____|
|
||||
| | | | | | \ V / | |__ | | | | | | | | | | | |__
|
||||
| | | | | | > < | __| | | | | | | | | | | | __|
|
||||
| | | |__| | / . \ | | | |__ | |__| | | | | | | |____
|
||||
|_| \____/ /_/ \_\ |_| |____| \____/ |_| |_| |______|
|
||||
|
||||
##########
|
||||
#### ###
|
||||
### ###
|
||||
## ##
|
||||
## ### ##
|
||||
## ## ##
|
||||
## ### ########
|
||||
## # ######
|
||||
## ###
|
||||
@ -19,18 +17,19 @@
|
||||
# ##########
|
||||
########### # ###
|
||||
### ### # ###
|
||||
## ### ## #
|
||||
# ## ## ###########
|
||||
######### ## # ### ##
|
||||
#### ## ## ## ##
|
||||
## ### ##
|
||||
# # ## # ########
|
||||
######### ### # # ## ##
|
||||
#### ## ## # ##
|
||||
## ### ####
|
||||
# ### #########
|
||||
# ## #########
|
||||
############### ##
|
||||
### ##
|
||||
## ##############
|
||||
# ####
|
||||
## ##
|
||||
## ###
|
||||
## ###
|
||||
## ##
|
||||
# #
|
||||
# ##
|
||||
## #
|
||||
# #
|
||||
# #
|
||||
|
||||
|
||||
@ -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}"
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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}"
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user