Release v1.3.90 — nach dem Paket fragen, nicht nach dem Pfad

Der zweite Bau auf echter Hardware brach ab mit "qemu-guest-agent ist NICHT im
Abbild". Es war im Abbild. Die Prüfung suchte /usr/bin/qemu-ga, Debian legt den
Gastagenten nach /usr/sbin/qemu-ga.

Dass das Paket eingebaut war, stand im selben Protokoll: customise_cloud_image
ruft --install und danach --run-command 'systemctl enable qemu-guest-agent'. Ein
fehlgeschlagenes --run-command lässt virt-customize abbrechen, und systemctl
kann keine Unit aktivieren, die es nicht gibt. Der Lauf ging durch — also war
das Paket da.

Das ist zum zweiten Mal derselbe Fehler in dieser Datei: eine Eigenschaft über
einen NAMEN behauptet statt über die Sache. Erst die Partitionsnummer statt der
Lage auf der Platte (v1.3.89), jetzt ein Pfad statt der Verpackung. Ein Pfad ist
eine Vermutung darüber, wie ein Paket seine Dateien verteilt.

Gefragt wird jetzt /var/lib/dpkg/info/<paket>.list — die Aussage des Pakets über
sich selbst, und genau die Frage, die hier gestellt gehört: hat apt es still
übergangen? Ein einziges Verzeichnis-Listing für alle vier Pakete, weil jeder
virt-ls-Aufruf eine eigene Appliance startet.

Geprüft werden damit qemu-guest-agent (Falle 3), cloud-guest-utils für growpart
(Falle 4), docker-compose-plugin und docker-ce. Der Vergleich ist grep -qx: ein
vorhandenes docker-ce-cli.list darf nicht als docker-ce durchgehen —
durchgespielt, zusammen mit einem vollständigen und einem lückenhaften Listing.

Falle 1 bleibt eine Inhaltsprüfung, weil sie eine ist: user: www-data steht in
einer Datei, die wir selbst hineinkopieren, nicht in einem Paket.

Und die Meldung nennt jetzt die fehlenden Pakete beim Namen statt nur die Falle.

Bestätigt aus demselben Lauf: Falle 2 besteht seit v1.3.89 ("Wurzel auf
/dev/sda1 und nichts dahinter"), und der Umbau selbst — Docker, Compose,
Gastagent — lief in 38 Sekunden durch.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

VERSION

@@ -1 +1 @@
-1.3.89
+1.3.90

deploy/bootstrap/lib/template.sh

@@ -387,15 +387,52 @@ customise_cloud_image() {
     return 0
 }
 
-# Prüft im fertigen Abbild nach, dass die drei Fallen wirklich zu sind.
+# Welche Pakete aus einer Liste im Abbild NICHT installiert sind.
+#
+# Gefragt wird die dpkg-Datenbank, nicht ein Pfad — und das ist der Unterschied,
+# der den ersten Bau auf echter Hardware abgebrochen hat. Die Prüfung suchte
+# `/usr/bin/qemu-ga`; Debian legt den Gastagenten nach `/usr/sbin/qemu-ga`. Das
+# Paket WAR eingebaut (`systemctl enable qemu-guest-agent` im selben Lauf hätte
+# eine fehlende Unit nicht aktivieren können), die Prüfung sah nur an der
+# falschen Stelle nach.
+#
+# Ein Pfad ist eine Vermutung darüber, wie ein Paket seine Dateien verteilt.
+# `/var/lib/dpkg/info/<paket>.list` ist die Aussage des Pakets selbst — und
+# genau die Frage, die hier gestellt gehört: hat apt es still übergangen?
+#
+# Ein Verzeichnis-Listing für alle Pakete zusammen, nicht eines pro Paket: jeder
+# virt-ls-Aufruf startet eine eigene Appliance.
+missing_packages() {
+    _installed="$1"
+    shift
+
+    for _package in "$@"; do
+        printf '%s\n' "$_installed" | grep -qx "${_package}.list" || printf '%s ' "$_package"
+    done
+}
+
+# Prüft im fertigen Abbild nach, dass die vier Fallen wirklich zu sind.
 #
 # Nach dem Einbauen, nicht davor: `virt-customize` meldet auch dann Erfolg, wenn
 # apt ein Paket stillschweigend nicht installiert hat.
 verify_image_contents() {
     _image="$1"
 
-    if ! virt-ls -a "$_image" /usr/bin 2>/dev/null | grep -q '^qemu-ga$'; then
-        log 'qemu-guest-agent ist NICHT im Abbild (Falle 3) — jede Bereitstellung hinge an WaitForGuestAgent'
+    _installed="$(virt-ls -a "$_image" /var/lib/dpkg/info 2>/dev/null)"
+    if [ -z "$_installed" ]; then
+        log 'Die dpkg-Datenbank im Abbild ist nicht lesbar — der Inhalt ist nicht prüfbar'
+        return 1
+    fi
+
+    # FALLE 3 (qemu-guest-agent — sonst hängt jede Bereitstellung an
+    # WaitForGuestAgent bis zum Zeitablauf) und FALLE 4 (cloud-guest-utils
+    # bringt growpart — ohne das läge jedes gekaufte Kontingent über einem
+    # Dateisystem, das nie gewachsen ist), dazu das Compose-Plugin, ohne das
+    # `docker compose up` im Gast kein Kommando ist.
+    _missing="$(missing_packages "$_installed" qemu-guest-agent cloud-guest-utils docker-compose-plugin docker-ce)"
+
+    if [ -n "$_missing" ]; then
+        log "Diese Pakete sind NICHT im Abbild: ${_missing}— apt hat sie still übergangen (Falle 3/4)"
         return 1
     fi
 
@@ -405,27 +442,14 @@ verify_image_contents() {
         return 1
     fi
 
+    # FALLE 1, und die einzige, die kein Paket ist: es geht um den INHALT der
+    # Datei, die wir selbst hineinkopiert haben.
     if ! printf '%s' "$_compose_in_image" | grep -qE '^[[:space:]]*user:[[:space:]]*www-data[[:space:]]*$'; then
         log 'Die Compose-Datei im Abbild hat kein `user: www-data` (Falle 1) — alle occ-Aufrufe schlügen fehl'
         return 1
     fi
 
-    if ! virt-ls -a "$_image" /usr/libexec/docker/cli-plugins 2>/dev/null | grep -q 'docker-compose'; then
-        if ! virt-ls -a "$_image" /usr/lib/docker/cli-plugins 2>/dev/null | grep -q 'docker-compose'; then
-            log 'Das Compose-Plugin ist nicht im Abbild'
-            return 1
-        fi
-    fi
-
-    # FALLE 4. Siehe die Paketliste oben: das Kontingent, das der Kunde bezahlt
-    # hat, wird über ein Dateisystem geschrieben, das growpart vorher vergrößert
-    # haben muss. Fehlt es, tut die Vergrößerung still nichts.
-    if ! virt-ls -a "$_image" /usr/bin 2>/dev/null | grep -q '^growpart$'; then
-        log 'growpart ist NICHT im Abbild (Falle 4) — GrowGuestFilesystem liefe ins Leere und jedes gekaufte Kontingent läge über einem Dateisystem, das nie gewachsen ist'
-        return 1
-    fi
-
-    log 'Abbildinhalt in Ordnung: qemu-guest-agent, growpart, Compose-Plugin, user: www-data'
+    log 'Abbildinhalt in Ordnung: qemu-guest-agent, cloud-guest-utils, Docker samt Compose-Plugin, user: www-data'
     return 0
 }