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.
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.