Thomas Stallinger
8b47751b31
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.
36 lines
2.2 KiB
Plaintext
36 lines
2.2 KiB
Plaintext
_______ _ _ __ __ ______ _ ____ _____ _____ ______
|
|
|__ __|| | | | \ \ / / | ____|| | / __ \ |_ _||_ _|| ____|
|
|
| | | | | | \ V / | |__ | | | | | | | | | | | |__
|
|
| | | | | | > < | __| | | | | | | | | | | | __|
|
|
| | | |__| | / . \ | | | |__ | |__| | | | | | | |____
|
|
|_| \____/ /_/ \_\ |_| |____| \____/ |_| |_| |______|
|
|
|
|
##########
|
|
### ###
|
|
## ##
|
|
## ## ##
|
|
## ### ########
|
|
## # ######
|
|
## ###
|
|
# ##
|
|
# #
|
|
# ##########
|
|
########### # ###
|
|
### ### # ###
|
|
## ### ##
|
|
# # ## # ########
|
|
######### ### # # ## ##
|
|
#### ## ## # ##
|
|
## ### ####
|
|
# ## #########
|
|
############### ##
|
|
### ##
|
|
## ##############
|
|
# ####
|
|
## ###
|
|
## ##
|
|
# #
|
|
# #
|
|
# #
|
|
|