Debian ne publie aucune image cloud s390x — verifie sur le miroir :
bookworm et trixie ne servent que amd64, arm64, ppc64el et riscv64. Le
port existe pourtant, « binary-s390x » repond 200, et l'installateur
livre kernel + initrd pour les deux versions.
D'ou une seconde voie de deploiement, choisie par uses_installer() :
disque VIERGE au lieu d'un qcow2 converti, amorcage kernel+initrd au
lieu de --import, et un preseed a la place du seed cloud-init. Le
preseed refait ce que fait cloud-init — nom d'hote, utilisateur, cles
SSH, sudo, fuseau, paquets — sinon d-i pose la question sur une console
que personne ne regarde.
Le preseed voyage DANS l'initrd : pas de serveur HTTP a maintenir
pendant l'installation, et rien qui depende du moment ou le reseau
monte.
Verifie contre l'initrd s390x reel : preseed.cfg relu a la racine des
966 entrees, 1807 octets identiques a l'ecriture. Les voies image cloud
sont inchangees — amd64, arm64 et Ubuntu s390x gardent --import.
--- EN ---
Debian publishes no s390x cloud image — checked against the mirror:
bookworm and trixie only serve amd64, arm64, ppc64el and riscv64. Yet
the port exists, "binary-s390x" returns 200, and the installer ships
kernel + initrd for both versions.
Hence a second deployment path, picked by uses_installer(): a BLANK
disk instead of a converted qcow2, kernel+initrd boot instead of
--import, and a preseed in place of the cloud-init seed. The preseed
redoes what cloud-init does — hostname, user, SSH keys, sudo, timezone,
packages — otherwise d-i asks on a console nobody watches.
The preseed travels INSIDE the initrd: no HTTP server to keep alive
during the install, and nothing depending on when the network comes up.
Verified against the real s390x initrd: preseed.cfg read back at the
root of 966 entries, 1807 bytes identical to what was written. Cloud
image paths are unchanged — amd64, arm64 and Ubuntu s390x keep --import.
Assisted-by: Claude Opus 5
(cherry picked from commit d26ddee95bb5b3b3627950c33879155fb28bba58)
Mathieu Benoit
9641a5b749