Release v1.3.89 — Falle 2 lehnte das einzige Abbild ab, für das sie gedacht war
tests / pest (push) Failing after 9m49s Details
tests / assets (push) Successful in 25s Details
tests / release (push) Has been skipped Details

Der erste echte Vorlagenbau brach ab mit:

  Die Root-Partition (/dev/sda1) ist nicht die letzte auf der Platte
  (/dev/sda15).

Das Abbild war in Ordnung, die Prüfung nicht. Sie verglich Partitions-NAMEN und
hielt für die letzte, was `sort -V` nach hinten sortiert. Debians Cloud-Abbild
legt die BIOS-Boot- und die EFI-Partition aber an den ANFANG der Platte und
nummeriert sie als 14 und 15; die Wurzel ist Nummer 1 und liegt physisch
dahinter. Gemessen: sda15 beginnt bei 4 MB, sda1 bei 128 MB.

Das ist kein Zufall dieses Abbilds, sondern genau die Eigenschaft, die Falle 2
verlangt — nur so kann growpart die Wurzel über den freien Rest ausdehnen. Die
Prüfung verweigerte also ein Abbild, weil es ihre Bedingung erfüllte.

Jetzt wird nach dem ANFANG auf der Platte gefragt statt nach der Nummer, über
`guestfish part-list`, das Offsets in Bytes liefert. "Nichts liegt dahinter" ist
eine Aussage über die Platte, nicht über die Benennung.

Die Auswertung steht in zwei eigenen Funktionen (last_partition_number,
partition_start), damit sie sich ohne Proxmox und ohne libguestfs gegen
aufgezeichnete part-list-Ausgaben durchspielen lässt — gemacht, in beide
Richtungen: Debians Anordnung besteht, eine Platte mit etwas hinter der Wurzel
fällt durch. Genau diese Gegenprobe fehlte, weshalb der Fehler bis auf echte
Hardware durchkam.

Und die Fehlermeldung trägt jetzt die Byte-Offsets beider Partitionen mit.
Scheitert das je wieder, steht die Platte im Protokoll statt einer Vermutung.

Nebenbei bestätigt: der VPN-Aussetzer vor dem Bau hat zweimal
"could not ask Proxmox about the VM templates" gemeldet und wiederholt, statt
einen Neubau auszulösen — der Codex-P1-Fix aus v1.3.88 hat am ersten Tag
verhindert, dass ein Netzausfall qm destroy --purge auslöst.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
main v1.3.89
nexxo 2026-08-01 09:21:54 +02:00
parent db125781ed
commit 88dadf759a
2 changed files with 69 additions and 10 deletions

View File

@ -1 +1 @@
1.3.88
1.3.89

View File

@ -237,10 +237,51 @@ fetch_cloud_image() {
return 0
}
# Aus der Ausgabe von `guestfish … part-list`: die Nummer der Partition, die am
# WEITESTEN HINTEN auf der Platte beginnt.
#
# Eigene Funktion, damit sie sich ohne Proxmox und ohne libguestfs gegen
# aufgezeichnete Ausgaben durchspielen lässt — sie ist der Kern von Falle 2 und
# hat schon einmal das Falsche gesagt.
last_partition_number() {
awk '
/part_num:/ { num = $2 }
/part_start:/ { if ($2 + 0 > max + 0) { max = $2 + 0; last = num } }
END { print last }
'
}
# Aus derselben Ausgabe: wo eine bestimmte Partition beginnt (für die Meldung).
partition_start() {
awk -v want="$1" '
/part_num:/ { num = $2 }
/part_start:/ { if (num == want) { print $2; exit } }
'
}
# FALLE 2, geprüft statt angenommen.
#
# Zwei Aussagen: kein LVM, und die Root-Partition ist die letzte auf der Platte.
# `virt-filesystems` beantwortet beide, ohne das Abbild einzuhängen.
# Zwei Aussagen: kein LVM, und hinter der Root-Partition liegt nichts mehr.
#
# ---------------------------------------------------------------------------
# Warum nach dem ANFANG gefragt wird und nicht nach der Nummer
# ---------------------------------------------------------------------------
#
# Hier stand ein Vergleich der Partitions-NAMEN: die letzte war die, die
# `sort -V` nach hinten sortiert. Das ist bei Debians Cloud-Abbild genau falsch
# herum und hat es am 1. August 2026 abgelehnt — dem einzigen Abbild, für das
# diese Prüfung je gedacht war.
#
# Debian legt die BIOS-Boot- und die EFI-Partition an den ANFANG der Platte und
# nummeriert sie als 14 und 15; die Wurzel ist Nummer 1 und liegt physisch
# dahinter. Das ist Absicht und ist genau die Eigenschaft, die Falle 2 verlangt:
# nur so kann `growpart` die Wurzel über den freien Rest ausdehnen. Nach Namen
# sortiert sah `/dev/sda15` wie die letzte aus, und die Prüfung verweigerte ein
# Abbild, das ihre Bedingung erfüllte.
#
# `guestfish part-list` gibt Anfangs-Offsets in Bytes. Danach wird gefragt,
# weil das die Frage IST — „nichts liegt dahinter" ist eine Aussage über die
# Platte, nicht über die Benennung.
verify_image_layout() {
_image="$1"
@ -255,17 +296,35 @@ verify_image_layout() {
return 1
fi
# Die Wurzel ist die Partition mit der höchsten Nummer, wenn sie die letzte
# ist. Anders gefragt: gibt es hinter der Root-Partition noch eine?
_last_part="$(printf '%s\n' "$_fs" | awk '/^\/dev\/[a-z]+[0-9]+/ { print $1 }' | sort -V | tail -1)"
_root_part="$(virt-filesystems --long -a "$_image" 2>/dev/null | awk '$0 !~ /swap/ && /ext4|xfs|btrfs/ { print $1; }' | sort -V | tail -1)"
if [ -n "$_last_part" ] && [ -n "$_root_part" ] && [ "$_last_part" != "$_root_part" ]; then
log "Die Root-Partition (${_root_part}) ist nicht die letzte auf der Platte (${_last_part}). GrowGuestFilesystem wächst nur die letzte."
if [ -z "$_root_part" ]; then
log 'Keine Wurzel im Abbild gefunden (kein ext4/xfs/btrfs) — Abbildaufbau nicht prüfbar'
return 1
fi
log "Abbildaufbau in Ordnung: kein LVM, Wurzel auf ${_root_part:-(unbestimmt)} als letzte Partition"
_root_num="$(printf '%s' "$_root_part" | sed 's/.*[^0-9]\([0-9][0-9]*\)$/\1/')"
_parts="$(guestfish --ro -a "$_image" run : part-list /dev/sda 2>/dev/null)"
if [ -z "$_parts" ]; then
log 'guestfish part-list liefert nichts — die Lage der Partitionen ist nicht prüfbar'
return 1
fi
_last_num="$(printf '%s\n' "$_parts" | last_partition_number)"
if [ -z "$_last_num" ]; then
log 'part-list liefert keine Partitionen — Abbildaufbau nicht prüfbar'
return 1
fi
if [ "$_last_num" != "$_root_num" ]; then
# Die Zahlen mit in die Meldung: scheitert das je wieder, soll die
# nächste Person die Platte im Protokoll sehen und nicht raten müssen.
log "Hinter der Wurzel (Partition ${_root_num}, Beginn $(printf '%s\n' "$_parts" | partition_start "$_root_num") Bytes) beginnt noch Partition ${_last_num} (Beginn $(printf '%s\n' "$_parts" | partition_start "$_last_num") Bytes). GrowGuestFilesystem vergrößert nur, was nichts hinter sich hat."
return 1
fi
log "Abbildaufbau in Ordnung: kein LVM, Wurzel auf ${_root_part} und nichts dahinter"
return 0
}