mint-image/hardware: Boot-Medium-Platte in gemeinsame lib ausgelagert

_mint_image_boot_medium_disk() aus backend.sh nach scripts/lib/boot_medium.sh
verschoben (tuxflotte_boot_medium_disk()) - build_storage_devices_json()
(hardware_collectors.sh) braucht dieselbe Ausschluss-Logik jetzt ebenfalls.

Nutzer-Feedback (01.09.2026, echter Hardware-Test): der Installations-
USB-Stick selbst tauchte in der Kundenplattform unter Flotte -> Aktionen ->
Hardware-Info -> Datenträger auf - fuer den Kunden irrefuehrend, da dieser
Datentraeger nach der Installation gar nicht mehr existiert. Gleiche
Ursache wie der parted-Bug (Commit fa54461): lsblk liefert das Boot-Medium
auf echter USB-Stick-Hardware als normalen TYPE="disk" zurueck.
This commit is contained in:
Thomas Stallinger 2026-09-01 15:45:25 +02:00
parent fa54461cae
commit 3739da37dc
8 changed files with 200 additions and 62 deletions

View File

@ -21,6 +21,13 @@ BACKEND_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
REPO_DIR="$(cd "${BACKEND_DIR}/../.." && pwd)"
POSTINSTALL_SCRIPT="${BACKEND_DIR}/postinstall.sh"
IMAGE_DEPLOY_LIB="${REPO_DIR}/scripts/lib/image_deploy.sh"
BOOT_MEDIUM_LIB="${REPO_DIR}/scripts/lib/boot_medium.sh"
# Vom Netzwerkmodul geschuetzt abgelegtes WLAN-/Ethernet-Verbindungsprofil
# (siehe export_connection_profile() in 05_network.sh) - existiert nur,
# wenn das Provisionierungsinterface ueber ein aktives NetworkManager-
# Profil lief (z.B. WLAN mit PSK).
NETWORK_PROFILE_EXPORT="/run/tuxflotte/network/connection.nmconnection"
RUNTIME_BLUEPRINT_FILE="/run/tuxflotte/runtime/runtime_blueprint.json"
SERVER_RESPONSE_FILE="/run/tuxflotte/server/response.json"
@ -52,38 +59,15 @@ backend_fatal() {
return 1
}
# Live auf echter USB-Stick-Hardware gefunden (01.09.2026): auf einem
# CD-ROM (wie in allen bisherigen QEMU-Tests) ist das Boot-Medium ein
# eigener Geraetetyp ("rom"), der von der lsblk-Filterung unten schon
# ausgeschlossen wird - auf einem echten USB-Stick ist das Boot-Medium
# selbst aber ein ganz normales "disk"-Blockgeraet, genau wie die interne
# Zielplatte. Ohne Ausschluss kann die Erkennung darunter den Stick selbst
# waehlen (abhaengig von der Aufzaehlungsreihenfolge) - "parted mklabel"
# darauf schlaegt dann IMMER fehl ("...have been unable to inform the
# Kernel of the change, probably because it/they are in use"), weil man
# nicht die Platte partitionieren kann, von der man gerade lebt. Der
# vorherige Fix (Zielplatte freigeben + Neueinlesen wiederholen) half
# deshalb nicht - das war die falsche Diagnose fuer dieses Problem.
_mint_image_boot_medium_disk() {
local medium_source parent
medium_source="$(findmnt --noheadings --output SOURCE /run/live/medium 2>/dev/null)" || return 1
[[ -n "${medium_source}" ]] || return 1
parent="$(lsblk --noheadings --output PKNAME "${medium_source}" 2>/dev/null | head -n1)"
[[ -n "${parent}" ]] || return 1
printf '/dev/%s\n' "${parent}"
}
# Analog zu _tuxflotte_detect_target_disk() in backends/mint/backend.sh -
# bewusst hier dupliziert statt geteilt, um dieses Backend unabhaengig vom
# Mint-Referenzbackend zu halten (siehe Modul-Kommentar oben). Ein Umzug in
# eine gemeinsame lib waere ein sinnvolles spaeteres Aufraeumen, sobald
# mehr als zwei Backends dieselbe Logik brauchen.
# Zieldatentraeger-Erkennung - schliesst das Boot-Medium selbst aus (siehe
# tuxflotte_boot_medium_disk() in scripts/lib/boot_medium.sh: auf echter
# USB-Stick-Hardware enumeriert das Medium als normales "disk"-Blockgeraet,
# genau wie die Zielplatte - ohne Ausschluss schlaegt "parted mklabel"
# darauf IMMER fehl, weil man nicht die Platte partitionieren kann, von der
# man gerade lebt).
_mint_image_detect_target_disk() {
local boot_medium_disk
boot_medium_disk="$(_mint_image_boot_medium_disk || true)"
boot_medium_disk="$(tuxflotte_boot_medium_disk || true)"
lsblk --nodeps --noheadings --bytes --output NAME,TYPE,SIZE --paths |
awk -v exclude="${boot_medium_disk}" '
@ -119,6 +103,11 @@ backend_init() {
# shellcheck source=../../scripts/lib/image_deploy.sh
source "${IMAGE_DEPLOY_LIB}"
[[ -r "${BOOT_MEDIUM_LIB}" ]] ||
{ backend_fatal "Boot-Medium-Bibliothek nicht gefunden: ${BOOT_MEDIUM_LIB}"; return 1; }
# shellcheck source=../../scripts/lib/boot_medium.sh
source "${BOOT_MEDIUM_LIB}"
[[ -r "${POSTINSTALL_SCRIPT}" ]] ||
{ backend_fatal "Postinstall-Skript nicht gefunden: ${POSTINSTALL_SCRIPT}"; return 1; }
@ -241,6 +230,16 @@ backend_launch() {
backend_log "Mounte unter ${TARGET_DIR}"
image_deploy_mount "${TARGET_DIR}" "${boot_part}" "${root_part}" || return 1
# Live gefunden (01.09.2026, echter Hardware-Test): export_connection_profile()
# in 05_network.sh legt das aktive WLAN-/Ethernet-Profil zwar geschuetzt unter
# /run/tuxflotte/network/connection.nmconnection ab, aber bis hierhin holte es
# nie jemand von dort ab - das frisch installierte System stand deshalb beim
# ersten Boot ohne gespeichertes WLAN-Profil da und fragte den PSK erneut ab.
if [[ -f "${NETWORK_PROFILE_EXPORT}" ]]; then
backend_log "Übernehme WLAN-/Netzwerkverbindungsprofil ins Zielsystem"
image_deploy_install_network_profile "${TARGET_DIR}" "${NETWORK_PROFILE_EXPORT}" || return 1
fi
# Live gefunden (31.08.2026, erster echter End-to-End-Lauf mit dem vollen
# Referenz-VM-Archiv): "erst nach /run/tuxflotte/... herunterladen, dann
# entpacken" scheiterte an /run (RAM-Tmpfs, viel kleiner als das
@ -335,6 +334,19 @@ backend_postinstall() {
umount --recursive "${TARGET_DIR}" ||
{ backend_fatal "${TARGET_DIR} konnte nicht ausgehängt werden."; return 1; }
# Nutzer-Feedback (01.09.2026, echter Hardware-Test): akustischer Hinweis
# + klare Ansage, dass der USB-Stick jetzt gefahrlos gezogen werden kann
# (ab hier wird nur noch von der Zielplatte gebootet) - Bestaetigung mit
# ENTER, sonst automatischer Neustart nach 5 Minuten (kein Warten auf
# eine Person, die vielleicht schon weitergegangen ist). "\a" (BEL) statt
# eines externen Tonwerkzeugs - funktioniert auf jeder PC-Lautsprecher-
# Hardware ohne zusaetzliches Paket.
printf '\a\a\a'
echo
echo "Fertig! Sie können den USB-Stick jetzt entfernen."
echo "Weiter mit ENTER, oder automatischer Neustart in 5 Minuten."
read -r -t 300 _ || true
backend_log "Starte neu - kein Rücksprung erwartet, ab hier läuft das frisch installierte System."
reboot
}

View File

@ -21,6 +21,13 @@ BACKEND_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
REPO_DIR="$(cd "${BACKEND_DIR}/../.." && pwd)"
POSTINSTALL_SCRIPT="${BACKEND_DIR}/postinstall.sh"
IMAGE_DEPLOY_LIB="${REPO_DIR}/scripts/lib/image_deploy.sh"
BOOT_MEDIUM_LIB="${REPO_DIR}/scripts/lib/boot_medium.sh"
# Vom Netzwerkmodul geschuetzt abgelegtes WLAN-/Ethernet-Verbindungsprofil
# (siehe export_connection_profile() in 05_network.sh) - existiert nur,
# wenn das Provisionierungsinterface ueber ein aktives NetworkManager-
# Profil lief (z.B. WLAN mit PSK).
NETWORK_PROFILE_EXPORT="/run/tuxflotte/network/connection.nmconnection"
RUNTIME_BLUEPRINT_FILE="/run/tuxflotte/runtime/runtime_blueprint.json"
SERVER_RESPONSE_FILE="/run/tuxflotte/server/response.json"
@ -52,38 +59,15 @@ backend_fatal() {
return 1
}
# Live auf echter USB-Stick-Hardware gefunden (01.09.2026): auf einem
# CD-ROM (wie in allen bisherigen QEMU-Tests) ist das Boot-Medium ein
# eigener Geraetetyp ("rom"), der von der lsblk-Filterung unten schon
# ausgeschlossen wird - auf einem echten USB-Stick ist das Boot-Medium
# selbst aber ein ganz normales "disk"-Blockgeraet, genau wie die interne
# Zielplatte. Ohne Ausschluss kann die Erkennung darunter den Stick selbst
# waehlen (abhaengig von der Aufzaehlungsreihenfolge) - "parted mklabel"
# darauf schlaegt dann IMMER fehl ("...have been unable to inform the
# Kernel of the change, probably because it/they are in use"), weil man
# nicht die Platte partitionieren kann, von der man gerade lebt. Der
# vorherige Fix (Zielplatte freigeben + Neueinlesen wiederholen) half
# deshalb nicht - das war die falsche Diagnose fuer dieses Problem.
_mint_image_boot_medium_disk() {
local medium_source parent
medium_source="$(findmnt --noheadings --output SOURCE /run/live/medium 2>/dev/null)" || return 1
[[ -n "${medium_source}" ]] || return 1
parent="$(lsblk --noheadings --output PKNAME "${medium_source}" 2>/dev/null | head -n1)"
[[ -n "${parent}" ]] || return 1
printf '/dev/%s\n' "${parent}"
}
# Analog zu _tuxflotte_detect_target_disk() in backends/mint/backend.sh -
# bewusst hier dupliziert statt geteilt, um dieses Backend unabhaengig vom
# Mint-Referenzbackend zu halten (siehe Modul-Kommentar oben). Ein Umzug in
# eine gemeinsame lib waere ein sinnvolles spaeteres Aufraeumen, sobald
# mehr als zwei Backends dieselbe Logik brauchen.
# Zieldatentraeger-Erkennung - schliesst das Boot-Medium selbst aus (siehe
# tuxflotte_boot_medium_disk() in scripts/lib/boot_medium.sh: auf echter
# USB-Stick-Hardware enumeriert das Medium als normales "disk"-Blockgeraet,
# genau wie die Zielplatte - ohne Ausschluss schlaegt "parted mklabel"
# darauf IMMER fehl, weil man nicht die Platte partitionieren kann, von der
# man gerade lebt).
_mint_image_detect_target_disk() {
local boot_medium_disk
boot_medium_disk="$(_mint_image_boot_medium_disk || true)"
boot_medium_disk="$(tuxflotte_boot_medium_disk || true)"
lsblk --nodeps --noheadings --bytes --output NAME,TYPE,SIZE --paths |
awk -v exclude="${boot_medium_disk}" '
@ -119,6 +103,11 @@ backend_init() {
# shellcheck source=../../scripts/lib/image_deploy.sh
source "${IMAGE_DEPLOY_LIB}"
[[ -r "${BOOT_MEDIUM_LIB}" ]] ||
{ backend_fatal "Boot-Medium-Bibliothek nicht gefunden: ${BOOT_MEDIUM_LIB}"; return 1; }
# shellcheck source=../../scripts/lib/boot_medium.sh
source "${BOOT_MEDIUM_LIB}"
[[ -r "${POSTINSTALL_SCRIPT}" ]] ||
{ backend_fatal "Postinstall-Skript nicht gefunden: ${POSTINSTALL_SCRIPT}"; return 1; }
@ -241,6 +230,16 @@ backend_launch() {
backend_log "Mounte unter ${TARGET_DIR}"
image_deploy_mount "${TARGET_DIR}" "${boot_part}" "${root_part}" || return 1
# Live gefunden (01.09.2026, echter Hardware-Test): export_connection_profile()
# in 05_network.sh legt das aktive WLAN-/Ethernet-Profil zwar geschuetzt unter
# /run/tuxflotte/network/connection.nmconnection ab, aber bis hierhin holte es
# nie jemand von dort ab - das frisch installierte System stand deshalb beim
# ersten Boot ohne gespeichertes WLAN-Profil da und fragte den PSK erneut ab.
if [[ -f "${NETWORK_PROFILE_EXPORT}" ]]; then
backend_log "Übernehme WLAN-/Netzwerkverbindungsprofil ins Zielsystem"
image_deploy_install_network_profile "${TARGET_DIR}" "${NETWORK_PROFILE_EXPORT}" || return 1
fi
# Live gefunden (31.08.2026, erster echter End-to-End-Lauf mit dem vollen
# Referenz-VM-Archiv): "erst nach /run/tuxflotte/... herunterladen, dann
# entpacken" scheiterte an /run (RAM-Tmpfs, viel kleiner als das
@ -335,6 +334,19 @@ backend_postinstall() {
umount --recursive "${TARGET_DIR}" ||
{ backend_fatal "${TARGET_DIR} konnte nicht ausgehängt werden."; return 1; }
# Nutzer-Feedback (01.09.2026, echter Hardware-Test): akustischer Hinweis
# + klare Ansage, dass der USB-Stick jetzt gefahrlos gezogen werden kann
# (ab hier wird nur noch von der Zielplatte gebootet) - Bestaetigung mit
# ENTER, sonst automatischer Neustart nach 5 Minuten (kein Warten auf
# eine Person, die vielleicht schon weitergegangen ist). "\a" (BEL) statt
# eines externen Tonwerkzeugs - funktioniert auf jeder PC-Lautsprecher-
# Hardware ohne zusaetzliches Paket.
printf '\a\a\a'
echo
echo "Fertig! Sie können den USB-Stick jetzt entfernen."
echo "Weiter mit ENTER, oder automatischer Neustart in 5 Minuten."
read -r -t 300 _ || true
backend_log "Starte neu - kein Rücksprung erwartet, ab hier läuft das frisch installierte System."
reboot
}

View File

@ -0,0 +1,35 @@
#!/usr/bin/env bash
# Gemeinsame Hilfsfunktion rund um das Boot-Medium selbst (nicht das
# Zielsystem). Wird an mehreren Stellen gebraucht:
# - backends/mint-image/backend.sh (_mint_image_detect_target_disk):
# verhindert, dass das Boot-Medium selbst als Zieldatentraeger gewaehlt
# und dann partitioniert wird.
# - scripts/lib/hardware_collectors.sh (build_storage_devices_json):
# verhindert, dass das Boot-Medium in der an den Server gemeldeten
# Datentraeger-Liste auftaucht (dort fuer den Kunden irrefuehrend, siehe
# Hardware-Info in der Kundenplattform).
#
# Urspruenglich in backend.sh dupliziert (siehe Commit fa54461) - mit dem
# zweiten Verwendungsort (Hardware-Erfassung) lohnt sich jetzt der Umzug in
# eine gemeinsame lib, wie im urspruenglichen Kommentar dort schon vermerkt.
# Live auf echter USB-Stick-Hardware gefunden (01.09.2026): auf einem
# CD-ROM (wie in allen bisherigen QEMU-Tests) ist das Boot-Medium ein
# eigener lsblk-Geraetetyp ("rom"), der von reinen "disk"-Filtern schon
# ausgeschlossen wird - auf einem echten USB-Stick ist das Boot-Medium
# selbst aber ein ganz normales "disk"-Blockgeraet, genau wie die interne
# Zielplatte. Ohne expliziten Ausschluss kann eine Datentraeger-Erkennung
# darunter den Stick selbst waehlen (abhaengig von der Aufzaehlungs-
# reihenfolge).
tuxflotte_boot_medium_disk() {
local medium_source parent
medium_source="$(findmnt --noheadings --output SOURCE /run/live/medium 2>/dev/null)" || return 1
[[ -n "${medium_source}" ]] || return 1
parent="$(lsblk --noheadings --output PKNAME "${medium_source}" 2>/dev/null | head -n1)"
[[ -n "${parent}" ]] || return 1
printf '/dev/%s\n' "${parent}"
}

View File

@ -24,16 +24,28 @@ get_memory_bytes() {
' /proc/meminfo
}
# Live gefunden (01.09.2026, echter Hardware-Test): auf einem echten
# USB-Stick enumeriert das Boot-Medium selbst als normales "disk"-
# Blockgeraet (siehe tuxflotte_boot_medium_disk() in boot_medium.sh) - ohne
# Ausschluss tauchte der Installations-Stick selbst in der an den Server
# gemeldeten Datentraeger-Liste auf und war dort fuer den Kunden
# irrefuehrend sichtbar (Hardware-Info in der Kundenplattform).
build_storage_devices_json() {
local boot_medium_disk boot_medium_name
boot_medium_disk="$(tuxflotte_boot_medium_disk 2>/dev/null || true)"
boot_medium_name="${boot_medium_disk#/dev/}"
lsblk \
--bytes \
--json \
--nodeps \
--output NAME,TYPE,MODEL,SERIAL,SIZE,TRAN |
jq '
jq --arg exclude "${boot_medium_name}" '
[
.blockdevices[]
| select(.type == "disk")
| select($exclude == "" or .name != $exclude)
| {
name: .name,
model: (

View File

@ -23,6 +23,7 @@ SCRIPT_DIR="$(
readonly SCRIPT_DIR
readonly COLLECTORS_FILE="${SCRIPT_DIR}/../lib/hardware_collectors.sh"
readonly BOOT_MEDIUM_FILE="${SCRIPT_DIR}/../lib/boot_medium.sh"
if [[ ! -r "${COLLECTORS_FILE}" ]]; then
printf '[%s] FEHLER: Collector-Library nicht gefunden: %s\n' \
@ -31,8 +32,17 @@ if [[ ! -r "${COLLECTORS_FILE}" ]]; then
exit 1
fi
if [[ ! -r "${BOOT_MEDIUM_FILE}" ]]; then
printf '[%s] FEHLER: Boot-Medium-Library nicht gefunden: %s\n' \
"${0##*/}" \
"${BOOT_MEDIUM_FILE}" >&2
exit 1
fi
# shellcheck source=../lib/hardware_collectors.sh
source "${COLLECTORS_FILE}"
# shellcheck source=../lib/boot_medium.sh
source "${BOOT_MEDIUM_FILE}"
readonly SCRIPT_NAME="${0##*/}"

View File

@ -0,0 +1,35 @@
#!/usr/bin/env bash
# Gemeinsame Hilfsfunktion rund um das Boot-Medium selbst (nicht das
# Zielsystem). Wird an mehreren Stellen gebraucht:
# - backends/mint-image/backend.sh (_mint_image_detect_target_disk):
# verhindert, dass das Boot-Medium selbst als Zieldatentraeger gewaehlt
# und dann partitioniert wird.
# - scripts/lib/hardware_collectors.sh (build_storage_devices_json):
# verhindert, dass das Boot-Medium in der an den Server gemeldeten
# Datentraeger-Liste auftaucht (dort fuer den Kunden irrefuehrend, siehe
# Hardware-Info in der Kundenplattform).
#
# Urspruenglich in backend.sh dupliziert (siehe Commit fa54461) - mit dem
# zweiten Verwendungsort (Hardware-Erfassung) lohnt sich jetzt der Umzug in
# eine gemeinsame lib, wie im urspruenglichen Kommentar dort schon vermerkt.
# Live auf echter USB-Stick-Hardware gefunden (01.09.2026): auf einem
# CD-ROM (wie in allen bisherigen QEMU-Tests) ist das Boot-Medium ein
# eigener lsblk-Geraetetyp ("rom"), der von reinen "disk"-Filtern schon
# ausgeschlossen wird - auf einem echten USB-Stick ist das Boot-Medium
# selbst aber ein ganz normales "disk"-Blockgeraet, genau wie die interne
# Zielplatte. Ohne expliziten Ausschluss kann eine Datentraeger-Erkennung
# darunter den Stick selbst waehlen (abhaengig von der Aufzaehlungs-
# reihenfolge).
tuxflotte_boot_medium_disk() {
local medium_source parent
medium_source="$(findmnt --noheadings --output SOURCE /run/live/medium 2>/dev/null)" || return 1
[[ -n "${medium_source}" ]] || return 1
parent="$(lsblk --noheadings --output PKNAME "${medium_source}" 2>/dev/null | head -n1)"
[[ -n "${parent}" ]] || return 1
printf '/dev/%s\n' "${parent}"
}

View File

@ -24,16 +24,28 @@ get_memory_bytes() {
' /proc/meminfo
}
# Live gefunden (01.09.2026, echter Hardware-Test): auf einem echten
# USB-Stick enumeriert das Boot-Medium selbst als normales "disk"-
# Blockgeraet (siehe tuxflotte_boot_medium_disk() in boot_medium.sh) - ohne
# Ausschluss tauchte der Installations-Stick selbst in der an den Server
# gemeldeten Datentraeger-Liste auf und war dort fuer den Kunden
# irrefuehrend sichtbar (Hardware-Info in der Kundenplattform).
build_storage_devices_json() {
local boot_medium_disk boot_medium_name
boot_medium_disk="$(tuxflotte_boot_medium_disk 2>/dev/null || true)"
boot_medium_name="${boot_medium_disk#/dev/}"
lsblk \
--bytes \
--json \
--nodeps \
--output NAME,TYPE,MODEL,SERIAL,SIZE,TRAN |
jq '
jq --arg exclude "${boot_medium_name}" '
[
.blockdevices[]
| select(.type == "disk")
| select($exclude == "" or .name != $exclude)
| {
name: .name,
model: (

View File

@ -23,6 +23,7 @@ SCRIPT_DIR="$(
readonly SCRIPT_DIR
readonly COLLECTORS_FILE="${SCRIPT_DIR}/../lib/hardware_collectors.sh"
readonly BOOT_MEDIUM_FILE="${SCRIPT_DIR}/../lib/boot_medium.sh"
if [[ ! -r "${COLLECTORS_FILE}" ]]; then
printf '[%s] FEHLER: Collector-Library nicht gefunden: %s\n' \
@ -31,8 +32,17 @@ if [[ ! -r "${COLLECTORS_FILE}" ]]; then
exit 1
fi
if [[ ! -r "${BOOT_MEDIUM_FILE}" ]]; then
printf '[%s] FEHLER: Boot-Medium-Library nicht gefunden: %s\n' \
"${0##*/}" \
"${BOOT_MEDIUM_FILE}" >&2
exit 1
fi
# shellcheck source=../lib/hardware_collectors.sh
source "${COLLECTORS_FILE}"
# shellcheck source=../lib/boot_medium.sh
source "${BOOT_MEDIUM_FILE}"
readonly SCRIPT_NAME="${0##*/}"