Commit graph

56 commits

Author SHA1 Message Date
96ae77485c [FIX] déploiement qemu : reprendre une image périmée avant d'abandonner
Une image gardée vieillit : le répertoire « latest » d'une distribution avance
à chaque version mineure, et la somme publiée cesse de décrire celle du
disque. La vérification la supprimait puis sortait en erreur — une campagne
entière, trois VM, perdue pour une péremption qu'un seul téléchargement
répare. Un écart sur une image DÉJÀ présente la fait désormais reprendre une
fois ; un second écart porte sur des octets fraîchement téléchargés, et arrête
tout. Sans liste de miroirs, et pour des sommes injoignables, rien ne change.
Vérifié : quatre tests de comportement, deux mutations attrapées.

--- EN ---

A kept image ages: a distribution's « latest » directory moves with each point
release, and the published sum stops describing the one on disk. The check
deleted it and exited — a whole campaign, three VMs, lost to a staleness one
download repairs. A mismatch on an image ALREADY present now makes it fetched
once more; a second mismatch is on freshly downloaded bytes, and stops
everything. With no mirror list, and for unreachable sums, nothing changes.
Checked: four behaviour tests, two mutations caught.

Assisted-by: Claude Opus 5
2026-09-21 05:39:38 -04:00
ce1bf5f4d1 [FIX] motd : replier la glose au lieu de déborder de 80 colonnes
Le guide tenait dans 80 colonnes nu, et rendait 103 dès qu'une VM portait
ses outils et un bureau. Le cadre débordait alors, le terminal repliait où
il voulait, et l'alignement en deux colonnes — seule chose qui rend un
guide lisible d'un coup d'œil — disparaissait.
La mise en page porte désormais la règle, plutôt que la longueur des textes
qui n'aurait tenu que jusqu'au prochain outil : la glose se replie sous sa
colonne, et passe sous sa commande quand celle-ci ne laisse plus de quoi
écrire. L'épreuve de largeur ne couvrait que le guide nu ; elle couvre le
guide équipé, qui est celui où le débordement vivait.

--- EN ---

The guide fitted in 80 columns bare, and rendered 103 as soon as a VM
carried its tools and a desktop. The frame then overflowed, the terminal
wrapped wherever it liked, and the two-column alignment — the only thing
making a guide readable at a glance — was gone.
The layout now carries the rule, rather than the length of texts which would
have held only until the next tool: a gloss wraps under its column, and
moves below its command when that command leaves no room. The width check
covered only the bare guide; it now covers the equipped one, which is where
the overflow lived.

Assisted-by: Claude Opus 5
2026-09-17 09:31:44 -04:00
7c860ff047 [ADD] cache qemu : NixOS apprend l'autorité, et le hors ligne s'ouvre
NixOS était SOUSTRAIT du cache faute d'ancre de confiance par fichier, ce
qui lui fermait le hors ligne : le magasin est alors la seule source, et
l'exception ne laisse rien. Une déclaration arriverait trop tard, la
première reconstruction étant le premier téléchargement.
L'autorité est donc POINTÉE, consommateur par consommateur, et
l'environnement se perd à trois frontières : nix-daemon, activé par
socket, qu'un fragment sous /run/systemd/system atteint ; sudo, que
« env_keep » traverse — le nix de root parle droit au magasin local et
télécharge lui-même ; et la session ssh, ouverte une seconde avant que
cloud-init n'écrive le faisceau. Vérifié : installation complète, 0 refus.

--- EN ---

NixOS was EXEMPTED from the cache for want of a per-file trust anchor,
which closed offline deployment to it: the store is then the only source,
and an exemption leaves nothing. A declaration would come too late, the
first rebuild being the first download.
The authority is therefore POINTED AT, consumer by consumer, and the
environment is lost at three boundaries: nix-daemon, socket-activated,
reached by a drop-in under /run/systemd/system; sudo, crossed by
« env_keep » — root's nix talks straight to the local store and downloads
itself; and the ssh session, opened one second before cloud-init writes
the bundle. Checked: a complete install, 0 refusals.

Assisted-by: Claude Opus 5
2026-09-16 21:33:10 -04:00
0105cf16e5 [FIX] cache et guide : suivre la traduction du binaire et le hors ligne
Le rebase apporte trois choses auxquelles ce travail devait s'accorder.
Les messages du binaire se traduisent désormais : ceux du refus de place
et de l'aide de --oublie passent par T(), avec leur entrée au catalogue —
deux garde-fous refusent sinon un message sans traduction ou l'inverse.

Soustraire l'hôte au cache est REFUSÉ hors ligne : le magasin est alors la
seule source, et l'excepter ne le ferait pas télécharger en direct, cela
le priverait de tout, ses propres paquets compris.

Et le guide de connexion annonce les outils sur la voie Proxmox aussi ; il
n'y était plus écrit du tout, l'argument manquant étant avalé.

--- EN ---

The rebase brings three things this work had to align with. The binary's
messages are now translatable: the out-of-space refusal and the --oublie
help go through T(), with their catalogue entry — two guard rails
otherwise refuse a message without a translation, or the reverse.

Exempting the host from the cache is REFUSED offline: the store is then
the only source, and exempting it would not make it download directly, it
would leave it with nothing, its own packages included.

And the connection guide announces the tools on the Proxmox path too; it
was no longer written there at all, the missing argument being swallowed.

Assisted-by: Claude Opus 5
2026-09-16 21:32:22 -04:00
1f5bdceb2a [ADD] guide de connexion : les outils posés, et ce que NixOS change
On entrait en ssh sans savoir que nix, PyCharm ou la forge étaient là, ni
par quelle commande s'en servir : le guide ne connaissait que la
distribution, ERPLibre et la présence d'un bureau. La liste vient du menu
FILTRÉE par la machine — Android Studio n'existe qu'en x86_64, PyCharm
veut un bureau — et chaque ligne est confrontée au code qui l'installe.
Le bloc NixOS porte la racine du dépôt, seule ligne qui n'était ni absolue
ni commande, et trois lignes qu'on ne devine pas : « --rollback », qui
défait une déclaration fautive ; « nixos-version » ; et « ls /bin », vide
alors que /bin/bash s'exécute. Une recherche de paquet a été essayée puis
écartée, muette sur cette image.

--- EN ---

One logged in over ssh with no way to know nix, PyCharm or the forge were
there, nor which command to use: the guide knew only the distribution,
ERPLibre and whether a desktop was installed. The list comes from the menu
FILTERED by the machine — Android Studio is x86_64 only, PyCharm wants a
desktop — and every line is checked against the code that installs it.
The NixOS block carries the checkout root, its only line neither absolute
nor a command, and three lines nobody guesses: « --rollback », which
undoes a faulty declaration; « nixos-version »; and « ls /bin », empty
while /bin/bash runs. A package search was tried then dropped, silent on
this image.

Assisted-by: Claude Opus 5
2026-09-16 21:32:22 -04:00
3d0ed8915f [FIX] qemu images : vérifier les sommes publiées, partout et par défaut
La vérification existait sous un drapeau, et pour Ubuntu SEULEMENT : les
autres images arrivaient sans que rien ne les regarde, alors que leurs
éditeurs publient tous une somme. Six y entrent, relevées sur les dépôts
plutôt que devinées — Debian est en sha512, les familles RHEL nomment
« CHECKSUM », Rocky l'écrit en forme BSD, Arch et openSUSE posent une
somme par image. Fedora en reste dehors, son fichier portant un numéro de
construction que l'URL de l'image ne donne pas.

Injoignable n'arrête plus rien, un écart si. Le menu du cache sait aussi
oublier une URL, « --detient » faisant l'aperçu.

--- EN ---

Verification existed behind a flag, and for Ubuntu ONLY: the other images
arrived with nothing looking at them, though every publisher ships a sum.
Six now enter, read off the repositories rather than guessed — Debian is
sha512, the RHEL families name it "CHECKSUM", Rocky writes the BSD form,
Arch and openSUSE ship a sum per image. Fedora stays out, its file
carrying a build number the image URL does not give.

Unreachable no longer stops anything, a mismatch does. The cache menu can
also forget one URL, "--detient" serving as the preview.

Assisted-by: Claude Opus 5
2026-09-16 21:32:03 -04:00
dc878e30d0 [FIX] nixos : afficher le guide de connexion, appliquer la locale
Le déploiement écrit /etc/motd partout et compte sur pam_motd pour le
montrer — vrai des quatre images cloud, faux ici : sshd rend « printmotd
no » et le PAM n'en contient aucun. Le guide était écrit, complet, et
personne ne le lisait. Il gagne un bloc propre à NixOS, dont le piège
qu'il existe pour dire — /etc/nixos/erplibre.nix est réécrit par
« make install_os », et ce qu'on y ajoute disparaît sans un mot.

La locale demandée ne s'appliquait pas : cloud-init passe par locale-gen
et update-locale, absents ici. Mesuré — fr_CA demandé, en_US obtenu. Rien
n'est imposé à une NixOS qu'on avait déjà.

--- EN ---

Deployment writes /etc/motd everywhere and relies on pam_motd to show it —
true of the four cloud images, false here: sshd returns "printmotd no" and
the PAM stack holds none. The guide was written, complete, and nobody read
it. It gains a NixOS block, including the trap it exists to name —
/etc/nixos/erplibre.nix is rewritten by "make install_os", and what you
add there vanishes without a word.

The requested locale did not apply: cloud-init goes through locale-gen and
update-locale, absent here. Measured — fr_CA asked, en_US obtained.
Nothing is imposed on a NixOS one already had.

Assisted-by: Claude Opus 5
2026-09-16 21:32:03 -04:00
e0624d9aaa [ADD] cache : retirer une seule entrée du magasin, par URL
Rien n'invalidait une entrée dont la somme ne correspond pas : le magasin
continuait de la servir, et retélécharger ne changeait rien puisque c'est
lui qui répond. Les deux purges existantes ne l'atteignent pas — l'une
efface tout, l'autre saute ce qui est récent alors que chaque service
remet cette date, si bien qu'un objet empoisonné qui sert ne vieillit
jamais.

Symétrique de « --detient » : mêmes lignes, mêmes fonctions de clé, mêmes
refus, et un objet présent qui résiste est dit refusé plutôt qu'oublié.
Mesuré : garde, puis oublié 53080, puis absent.

--- EN ---

Nothing invalidated an entry whose checksum does not match: the store kept
serving it, and re-downloading changed nothing since the store is what
answers. Neither existing purge reaches it — one erases everything, the
other skips what is recent while every service resets that date, so a
poisoned object that serves never ages.

Symmetric to "--detient": same lines, same key functions, same refusals,
and a present object that resists is reported refused rather than
forgotten. Measured: held, then forgotten 53080, then absent.

Assisted-by: Claude Opus 5
2026-09-16 21:32:03 -04:00
83b9674176 [REF] qemu firmware : une table pour les deux voies, fuseau décodé
Deux tables opposées vivaient dans le même fichier : l'une forçait le
BIOS, l'autre l'UEFI, chacune lue d'un seul côté. Elles pouvaient se
contredire sans que rien ne le dise. FIRMWARE_IMPOSE les remplace, et les
deux suites passent inchangées. « --bios » l'emportait sur un fait
physique : forcé sur une image sans secteur d'amorçage, il donnait une VM
« running » à console muette. Il est ignoré, et l'appelant l'apprend.

Le fuseau était lu en UTF-8 strict sous un « except OSError » : un octet
qui n'en est pas faisait échouer tout le déploiement pour une traduction
de confort.

--- EN ---

Two opposing tables lived in one file: one forced BIOS, the other UEFI,
each read by one side only. They could contradict each other silently.
FIRMWARE_IMPOSE replaces both, and both suites pass unchanged. "--bios"
overrode a physical fact: forced on an image with no boot sector it gave a
"running" VM with a mute console. It is ignored now, and the caller is
told.

The timezone was read as strict UTF-8 under an "except OSError": a byte
that is not one failed the whole deployment for a convenience
translation.

Assisted-by: Claude Opus 5
2026-09-16 21:31:03 -04:00
4f4664f804 [FIX] cache qemu : soustraire l'invité qui n'a pas de magasin
Le détournement est TRANSPARENT et vaut pour tout le pont : ne pas donner
l'autorité à une VM ne la dispense pas d'être interceptée, elle échoue sur
« self-signed certificate in certificate chain ». NixOS n'a pas d'ancre de
confiance par fichier, et la poser par déclaration arriverait trop tard —
la première reconstruction EST le premier téléchargement. La VM est donc
exceptée par son adresse MAC, avant sa création, et cela se dit.

L'image Proxmox n'est mise en place qu'une fois complète : « wget -O »
écrivait dans la cible, et une coupure y figeait un fichier tronqué que
le test de présence acceptait à chaque déploiement suivant.

--- EN ---

Interception is TRANSPARENT and covers the whole bridge: withholding the
authority from a VM does not spare it, it fails on "self-signed
certificate in certificate chain". NixOS has no per-file trust anchor, and
declaring one would come too late — the first rebuild IS the first
download. The VM is therefore exempted by MAC, before creation, and it is
said.

The Proxmox image is put in place only once complete: "wget -O" wrote into
the target, and an interruption froze a truncated file there that the
presence test accepted on every later deployment.

Assisted-by: Claude Opus 5
2026-09-16 21:31:03 -04:00
f3edd806bc [ADD] proxmox : NixOS s'y déploie, ce qui a pris trois correctifs
Aucune lecture de code ne les aurait trouvés. Son image n'a pas de secteur
d'amorçage BIOS : une VM créée en SeaBIOS se déclare « running » avec une
console MUETTE, d'où un marqueur par distribution — Debian 13 démarre en
SeaBIOS sur le même hôte, et renverser le défaut coûterait un disque EFI
à chaque VM du parc.

« --ciuser » s'en remet au compte par DÉFAUT de l'image, que NixOS nomme
autrement : le cloud-config du dépôt part en extrait pour toutes les
distributions. Et le lecteur cloud-init passe sur le bus SCSI, une image
bâtie pour virtio seul ne voyant jamais un lecteur IDE.

--- EN ---

No code reading would have found them. Its image has no BIOS boot sector:
a VM created in SeaBIOS reports "running" with a SILENT console, hence a
per-distribution marker — Debian 13 boots in SeaBIOS on the same host, and
flipping the default would cost an EFI disk on every VM.

"--ciuser" defers to the image's DEFAULT account, which NixOS names
otherwise: the repository's cloud-config now travels as a snippet for
every distribution. And the cloud-init drive moves to the SCSI bus, an
image built for virtio alone never seeing an IDE drive.

Assisted-by: Claude Opus 5
2026-09-16 21:31:03 -04:00
fa5892d006 [FIX] qemu cloud-init : locale, clavier et profil, par distribution
Deux réglages régionaux échouaient sur toute VM Debian, et le seul signe
en était le mot « error » dans un compte-rendu qui le porte à chaque fois.
« update-locale » refuse un locale qui n'est pas généré, et le module du
clavier finit par redémarrer console-setup, absent de l'image
genericcloud : le réglage est écrit avant cet échec, donc le poser
nous-mêmes ne perd que la console texte.

Et l'installateur nix n'écrit plus dans ~/.bashrc : un fichier que
l'utilisateur possède ne se modifie pas pour la durée d'un amorçage.

--- EN ---

Two regional settings failed on every Debian VM, and the only sign was the
word "error" in a report that carries it every time. "update-locale"
refuses a locale that is not generated, and the keyboard module ends by
restarting console-setup, absent from the genericcloud image: the setting
is written before that failure, so placing it ourselves loses only the
text console.

And the nix installer no longer writes into ~/.bashrc: a file the user
owns is not edited for the duration of a bootstrap.

Assisted-by: Claude Opus 5
2026-09-16 21:31:03 -04:00
fce1d5b00b [ADD] qemu : NixOS déployable, de son image à ses dépendances
Neuvième système du catalogue, et le seul dont aucune distribution ne
publie d'image cloud : celle d'un tiers est épinglée et sa somme vérifiée
à chaque téléchargement. Son seed diffère aussi — networkd prend la clé
d'un bloc pour un NOM d'interface là où netplan honore un « match: », et
sshd refuse un compte dont le shell n'existe pas, d'où /bin/sh.

Ses dépendances se DÉCLARENT dans conf/nixos/erplibre.nix : envfs répond
à /usr/bin/env, nix-ld donne aux roues manylinux leur chargeur. Vérifié
sur une VM : le verrou de 362 paquets s'installe et Odoo répond.

--- EN ---

Ninth system of the catalogue, and the only one no distribution publishes
a cloud image for: a third party's is pinned and its sum verified at every
download. Its seed differs too — networkd reads a block's key as an
interface NAME where netplan honours a "match:", and sshd refuses an
account whose shell does not exist, hence /bin/sh.

Its dependencies are DECLARED in conf/nixos/erplibre.nix: envfs answers
/usr/bin/env, nix-ld gives manylinux wheels their loader. Checked on a VM:
the 362-package lock installs and Odoo answers.

Assisted-by: Claude Opus 5
2026-09-16 21:31:03 -04:00
aa6774939f [FIX] déploiement qemu : attendre l'étape finale de cloud-init
« cloud-init status --wait » rend la main dès que cloud-init se déclare en
erreur — un module accessoire y suffit — alors que son étape finale écrit
encore l'autorité du cache, les variables et le fichier sudoers. Une session
ouverte dans cette seconde-là vit sans ces variables, PAM ne relisant plus le
fichier, et sudo n'a alors rien à conserver : l'installation lancée par sudo
rejette le certificat du cache. L'attente guette désormais l'unité
cloud-final, et son seul état « activating » : ce oneshot reste ACTIF une fois
fini, si bien qu'« is-active » y ferait attendre la borne entière pour rien.

--- EN ---

« cloud-init status --wait » returns as soon as cloud-init declares itself in
error — an accessory module is enough — while its final stage still writes the
cache authority, the variables and the sudoers file. A session opened in that
second lives without those variables, PAM never rereading the file, and sudo
then has nothing to keep: an install run by sudo rejects the cache
certificate. The wait now watches the cloud-final unit, and only its
« activating » state: this oneshot stays ACTIVE once finished, so « is-active »
would wait the whole bound for nothing.

Assisted-by: Claude Opus 5
2026-09-16 05:36:13 -04:00
433fe753c3 [FIX] hors ligne : HEAD servi, attente NTP levée, étape nommée
Trois défauts qui empêchaient une VM hors ligne d'aboutir. zypper vérifie
chaque dépôt par un HEAD, jamais gardé sous une clé portable : le dépôt était
déclaré invalide alors que le magasin tenait son index, et un HEAD reçoit
désormais les en-têtes du corps du GET gardé. Une image qui attend la
synchronisation NTP avant son étape finale ne démarrait jamais son serveur
ssh, faute de serveur de temps joignable ; l'attente est levée sur une VM
déployée hors ligne. Enfin, une troisième VM en échec nomme l'étape qui l'a
arrêtée, là où le résumé d'une série n'affichait qu'un verdict nu.

--- EN ---

Three faults that kept an offline VM from finishing. zypper checks each
repository with a HEAD, never stored under a portable key: the repository was
declared invalid while the store held its index, and a HEAD now gets the
headers of the stored GET body. An image waiting for NTP synchronisation
before its final stage never started its ssh server, no time server being
reachable; that wait is lifted on a VM deployed offline. Last, a failing third
VM names the step that stopped it, where a series summary showed a bare
verdict.

Assisted-by: Claude Opus 5
2026-09-16 05:36:13 -04:00
15477d52ac [FIX] déploiement et mesure : openSUSE, sudo, console, mémoire
Quatre défauts qu'une campagne complète sur les sept systèmes du catalogue a
mis au jour. La famille zypper visait un faisceau de certificats qu'openSUSE
n'écrit pas, et pip s'arrêtait là, en ligne comme hors ligne. sudo remet
l'environnement à zéro : sans env_keep, une installation lancée par sudo
rejette l'autorité du cache là où PAM ne relit pas /etc/environment. Le
journal de console n'était gardé que pour la voie installateur, si bien
qu'une image cloud bloquée avant ssh ne laissait rien à lire. Et une VM de
8 Gio restait allumée après sa mesure, épuisant la mémoire de l'hôte.

--- EN ---

Four faults a full campaign over the catalogue's seven systems brought out.
The zypper family pointed at a certificate bundle openSUSE does not write,
and pip stopped there, online as well as offline. sudo resets the
environment: without env_keep, an install run by sudo rejects the cache
authority where PAM does not reread /etc/environment. The console log was
kept for the installer path only, so a cloud image stuck before ssh left
nothing to read. And an 8 GiB VM stayed up after its measurement, exhausting
the host's memory.

Assisted-by: Claude Opus 5
2026-09-16 05:36:13 -04:00
4b60dcba30 [ADD] déploiement qemu : couper l'audit npm, traduire l'exception
L'audit de npm interroge un service qu'aucun cache ne rejoue : amont coupé,
il échoue à chaque installation sans rien vérifier. Une VM déployée hors
ligne reçoit donc NPM_CONFIG_AUDIT=false, écrit dans /etc/environment et
relu après cloud-init ; une VM en ligne garde son audit. Le retrait d'une
exception du détournement parle désormais la langue du menu, son message
allant à l'erreur standard tandis que la sortie standard garde les règles
que nft lit, qui ne se traduisent jamais.

--- EN ---

The npm audit queries a service no cache can replay: upstream cut, it fails
every install without checking anything. A VM deployed offline therefore gets
NPM_CONFIG_AUDIT=false, written in /etc/environment and read back after
cloud-init; an online VM keeps its audit. Removing a redirection exception
now speaks the menu's language, its message going to standard error while
standard output keeps the rules nft reads, which are never translated.

Assisted-by: Claude Opus 5
2026-09-16 05:36:13 -04:00
814251f19f [FIX] déploiement qemu : amorcer Fedora en BIOS, sa chaîne UEFI se fige
Aucune VM Fedora ne démarrait : pas de console, pas de bail DHCP, une machine
« en cours d'exécution » qui ne fait rien. Le micrologiciel charge et DÉMARRE
le chargeur — il l'annonce — puis se fige sans écrire un octet sur le disque.
La même image en BIOS démarre son noyau : ce n'est donc ni l'image, saine, ni
sa partition EFI, dont le chemin de repli est bien là. Ni l'entropie ni la
machine q35 n'y changent rien. Une table nomme les distributions concernées et
« --bios » l'emporte toujours, pour l'hôte qui n'a pas OVMF.

--- EN ---

No Fedora VM would start: no console, no DHCP lease, a machine "running" that
does nothing. The firmware loads and STARTS the loader — it says so — then
freezes without writing a byte to disk. The same image under BIOS boots its
kernel: so it is neither the image, which is sound, nor its EFI partition,
whose fallback path is present. Neither entropy nor the q35 machine changes
anything. A table names the distributions concerned, and "--bios" always
wins, for the host that has no OVMF.

Assisted-by: Claude Opus 5
2026-09-14 16:46:15 -04:00
2892606690 [FIX] déploiement qemu : nom d'hôte valide, fuseau connu de l'invité
Deux réglages que cloud-init applique au premier démarrage, et qui échouaient
tous les deux SANS arrêter le déploiement. Un nom d'hôte n'accepte ni souligné
ni point, là où un nom de domaine libvirt les tolère : la VM gardait le nom
générique de son image. Un alias de fuseau hérité — la forme que plusieurs
distributions récentes ont reléguée à un paquet séparé — faisait marquer
l'exécution de cloud-init en erreur et laissait la machine en UTC, ce qui ne
se voit qu'après coup sur des horodatages à +0000. Le nom est nettoyé, le
fuseau rendu canonique par la table d'alias de tzdata.

--- EN ---

Two settings cloud-init applies at first boot, both of which failed WITHOUT
stopping the deployment. A hostname accepts neither underscore nor dot, where
a libvirt domain name tolerates them: the VM kept its image's generic name. A
legacy timezone alias — the form several recent distributions moved to a
separate package — marked the cloud-init run as failed and left the machine in
UTC, which only shows up later on +0000 timestamps. The name is cleaned, the
timezone made canonical through tzdata's alias table.

Assisted-by: Claude Opus 5
2026-09-14 16:46:15 -04:00
a7706adf3d [ADD] cache qemu : miroir des téléchargements des VM, hors ligne compris
VMs of one host pulled the same packages again and again, and an install
could not be proven to work without the network. A Go service intercepts the
bridge transparently: a package file is served from disk, an index is always
revalidated upstream and replayed only when upstream is mute, git is mirrored.
Deployment poses the cache authority in QEMU and Proxmox VE guests, and can cut
the network for a whole install. The TODO menu installs, diagnoses, fills,
cleans and copies the store; long_test/qemu_cache.py measures that a second VM
pulls no package upstream. Covered by Go tests and test/test_qemu_cache_*.py.

--- FR ---

Les VM d'un hôte tiraient sans cesse les mêmes paquets, et rien ne prouvait
qu'une installation marche sans réseau. Un service Go intercepte le pont de
façon transparente : un fichier de paquet est servi du disque, un index est
toujours revalidé à l'amont et rejoué seulement quand l'amont est muet, git
est mis en miroir. Le déploiement pose l'autorité du cache dans les invités
QEMU et Proxmox VE, et peut couper le réseau pour toute une installation. Le
menu TODO installe, diagnostique, remplit, nettoie et emporte le magasin ;
long_test/qemu_cache.py mesure qu'une seconde VM ne tire aucun paquet de
l'amont. Couvert par les tests Go et test/test_qemu_cache_*.py.

Assisted-by: Claude Opus 5
2026-09-14 16:46:15 -04:00
ddde76f0cf [FIX] qemu deploy : l'unité de l'agent invité ne finit plus en échec
Dans le script du service qui pose qemu-guest-agent, « && » et « || » se
lisent à égalité de gauche à droite : une pose apt réussie enchaînait sur
« dnf install », puis sur le « command -v » d'un gestionnaire absent, qui
rend 127 sous dash. Le service finissait en échec après avoir posé
l'agent. Chaque branche est désormais entre accolades. Vérifié : le script
extrait de la vraie configuration cloud-init rend 0 avec apt-get, dnf ou
pacman factice.

--- EN ---

In the script of the service installing qemu-guest-agent, "&&" and "||"
have equal precedence, left to right: a successful apt install went on to
"dnf install", then to the "command -v" of a missing manager, which
returns 127 under dash. The service ended in failure after installing the
agent. Each branch is now braced. Checked: the script extracted from the
real cloud-init configuration returns 0 with a fake apt-get, dnf or
pacman.

Assisted-by: Claude Opus 5
2026-09-14 16:32:42 -04:00
82c651f1df [FIX] qemu réseau : ne plus compter le pont d'un réseau contre lui-même
Un réseau libvirt démarré porte et route son /24 sur son pont, et ce pont
comptait dans « ce que l'hôte occupe déjà » : le verdict était donc
« collision » sur toute machine où le réseau tournait, quel que soit son
sous-réseau. Tout déploiement passe par cette vérification, qui abattait
alors le réseau et le déplaçait sur un /24 libre là où rien n'entrait en
conflit — les VM attachées y perdaient passerelle et pont. Le pont du réseau
examiné en est écarté, chaque adresse étant rattachée à son interface ; un
nom de pont illisible n'écarte rien. Le XML de net-define passe par un
fichier temporaire imprévisible, retiré même quand virsh échoue.
Vérifié : 31 tests, dont 10 neufs, que le retrait de l'exclusion casse.

--- EN ---

A started libvirt network carries and routes its /24 on its bridge, and that
bridge counted as « what the host already occupies »: the verdict was
therefore « collision » on every machine where the network ran, whatever
subnet it served. Every deployment goes through that check, which then tore
the network down and moved it onto a free /24 where nothing conflicted — the
attached VMs lost gateway and bridge. The bridge of the network being
examined is now excluded, each address being tied to its own interface; an
unreadable bridge name excludes nothing. The XML for net-define goes through
an unpredictable temporary file, removed even when virsh fails.
Checked: 31 tests, 10 of them new, which removing the exclusion breaks.

Assisted-by: Claude Opus 5
2026-09-04 03:31:08 -04:00
416a0c8631 [IMP] qemu deploy : constater le motif du sudo, le dire avant l'invite
sudo ne dit jamais ce qu'il sert à faire : son invite tombe entre deux lignes
de journal, et l'on tape un mot de passe sans savoir s'il porte sur libvirt,
sur un paquet ou sur un fichier — d'autant qu'appartenir au groupe libvirt a
l'air de suffire. Il ne suffit pas, et libvirt n'y est pour rien : le disque
et le seed s'écrivent dans le pool par défaut, répertoire de root où le
groupe ne donne pas l'écriture. Le motif est constaté, non déduit :
l'écriture s'essaie, une ACL pouvant l'accorder là où le mode semble la
refuser. Dit une fois avant la première commande privilégiée, et en dernière
ligne du récapitulatif. Vérifié : 18 tests, root compris, à qui rien n'est dit.

--- EN ---

sudo never states what it is about to do: its prompt lands between two log
lines, and one types a password without knowing whether it covers libvirt, a
package or a file — the more so as being in the libvirt group looks like it
should be enough. It is not, and libvirt is not the reason: the disk and the
seed are written into the default pool, a root-owned directory where the
group grants no write right. The reason is checked, not deduced: writing is
tried, since an ACL can grant it where the mode seems to refuse it. Said once
before the first privileged command, and last on the review page. Checked: 18
tests, root included, which is told nothing.

Assisted-by: Claude Opus 5
2026-09-04 02:27:51 -04:00
4b320dc1de [FIX] qemu setup-host : ne plus priver l'hôte de réseau au redémarrage
Le réseau « default » de libvirt sert 192.168.122.0/24, et toute VM déployée
par ce dépôt y vit : son pont prendrait la première adresse du /24, celle de
sa passerelle. virsh refuse ce démarrage tant que la route est là ; au
démarrage, libvirtd monte ses réseaux avant le bail DHCP, et plus rien ne la
signale. L'autostart était armé même après un net-start refusé, d'où un hôte
sans réseau au redémarrage suivant. Il ne s'arme plus qu'en l'absence de
collision, le réseau est déplacé par redéfinition — ni pont ni module du
noyau — et un actif en collision est abattu. L'état, cherché en anglais quand
virsh traduit, se lisait toujours éteint : LC_ALL=C. Vérifié sur un hôte en
collision, puis 21 tests.

--- EN ---

libvirt's `default` network serves 192.168.122.0/24, and every VM this
repository deploys lives there: its bridge would take the /24's first
address, which is that machine's gateway. virsh refuses such a start while
the route is there; at boot, libvirtd raises its networks before the DHCP
lease, and nothing signals the collision. Autostart was armed even after a
refused net-start, hence a host with no network at the next boot. It is armed
only where no collision remains, the network is moved by redefinition — no
bridge, no kernel module — and an active collision is torn down. State, read
in English where virsh translates, always read as off: LC_ALL=C. Checked on a
colliding host, then 21 tests.

Assisted-by: Claude Opus 5
2026-09-04 02:05:35 -04:00
68eff72243 [ADD] qemu deploy : poser rtk, starship et un agent dans la VM
Une case de plus au catalogue des outils, donc une case dans les deux
écrans sans y toucher. Cochée, elle découvre le choix de l'agent — Claude
Code ou opencode — et l'identité git, pré-remplie avec celle de l'hôte :
c'est ce que la VM reçoit déjà, et un champ vide la ferait croire absente.
Ce qui est saisi prime, champ par champ.

Phase « before », où chaque outil se garde lui-même. Chaque pose est aussi
privée d'entrée standard et bornée dans le temps : « || true » couvre
l'échec, pas l'ATTENTE, et un installateur amont qui pose une question
resterait pendu sur un SSH sans terminal — d'où « -y » pour starship.

--- EN ---

One more entry in the tool catalogue, hence one more box on both screens
for free. Ticked, it reveals the agent choice — Claude Code or opencode —
and the git identity, prefilled from the host: that is what the VM
already gets, and an empty field would suggest none. What is typed wins,
field by field.

Phase « before », where each tool guards itself. Every install is also
denied stdin and time-bounded: « || true » covers failure, not WAITING,
and an upstream installer asking a question would hang on a terminal-less
SSH — hence « -y » for starship.

Assisted-by: Claude Opus 5
2026-09-03 05:00:55 -04:00
b474b6d65e [FIX] qemu 3D : donner à l'invité l'accès au nœud de rendu
Le matériel virtuel accéléré ne suffisait pas. Dans l'invité, le nœud de
rendu appartient à « root:render » en 0660 et le compte créé n'y était
pas : toute application GL retombait sur le rendu logiciel alors que la
négociation VIRGL avait réussi, et rien ne le signalait. En session
graphique locale, logind pose une ACL pour l'utilisateur du siège ; en
SSH ou en tty, le cas d'une VM de ce parc, personne ne la pose.

Les groupes sont DÉCLARÉS avant d'être utilisés : « useradd -G » échoue
sur un nom inconnu, et cloud-init ne crée alors pas le compte du tout —
la VM démarre inaccessible. « render » manque des images anciennes. Même
parité côté preseed, par « groupadd -f ». « --gpu off » n'ajoute rien.

--- EN ---

Accelerated virtual hardware was not enough. In the guest the render
node is « root:render » at 0660 and the created account was not in it:
every GL application fell back to software rendering although VIRGL
negotiation had succeeded, with nothing to say so. On a local graphical
session logind sets an ACL for the seat's user; over SSH or on a tty,
which is what these VMs get, nobody sets one.

Groups are DECLARED before use: « useradd -G » fails on an unknown name
and cloud-init then creates no account at all — the VM boots
unreachable. « render » is missing from older images. The preseed keeps
parity via « groupadd -f ». « --gpu off » adds nothing.

Assisted-by: Claude Opus 5
2026-09-03 05:00:55 -04:00
f417a9ea86 [ADD] qemu deploy : case 3D à la création, même sans écran virtuel
Une VM sans console peut vouloir un virtio-gpu accéléré — rendu hors
écran, ou émulateur qui tourne dedans — et « auto » ne l'accorde jamais :
il s'abstient sans écran, pour ne pas poser un périphérique vidéo que
personne n'a demandé. La case envoie donc « --gpu on », qui l'accorde
désormais. « --graphics none » est alors écarté : il dit « aucun
affichage », et egl-headless EST un affichage. Le repli le rend quand la
3D tombe, sinon la VM repartirait sur le défaut de virt-install.

Vérifié : 8 tests neufs et 2 sur le repli, rougis par trois mutations.
Le rendu de la case dans le terminal plein écran n'est pas testé.

--- EN ---

A VM without a console may want an accelerated virtio-gpu — offscreen
rendering, or an emulator running inside — and « auto » never grants it:
it abstains without a screen, so as not to add a video device nobody
asked for. The box therefore sends « --gpu on », which now grants it.
« --graphics none » is then dropped: it means « no display », and
egl-headless IS a display. The fallback gives it back when 3D fails,
otherwise the VM would restart on virt-install's default.

Checked: 8 new tests and 2 on the fallback, turned red by three
mutations. The box's rendering in the full-screen terminal is not tested.

Assisted-by: Claude Opus 5
2026-09-03 05:00:55 -04:00
9f94316ab0 [FIX] qemu deploy : recréer la VM sans 3D quand EGL ne démarre pas
Le nœud de rendu existe mais EGL ne s'y initialise pas : QEMU s'arrête
sur « eglInitialize failed » pendant la connexion au moniteur. La
détection ne voit qu'un fichier dans /dev/dri, et rien ne distingue un
GPU utilisable d'un nœud sans pile EGL avant que QEMU n'essaie. La
création réessaie donc sans la 3D, après avoir retiré le domaine de
l'essai raté — sans quoi le nom reste pris. « --gpu on » n'est pas
rétrogradé en silence, et un échec qui n'est pas celui d'EGL n'est pas
rattrapé.

Vérifié : 8 tests et trois mutations. Le chemin réel n'a pas été exécuté,
faute de /dev/dri et de virt-install sur la machine de développement.

--- EN ---

The render node exists but EGL will not initialise on it: QEMU stops on
« eglInitialize failed » while connecting to the monitor. Detection only
sees a file under /dev/dri, and nothing separates a usable GPU from a
node without an EGL stack until QEMU tries. Creation therefore retries
without 3D, after undefining the domain of the failed attempt — the name
would otherwise stay taken. « --gpu on » is not silently downgraded, and
a failure that is not EGL's is not caught.

Checked: 8 tests and three mutations. The real path was not exercised,
for lack of /dev/dri and virt-install on the development machine.

Assisted-by: Claude Opus 5
2026-09-03 05:00:55 -04:00
29b12c8ca1 [ADD] qemu arch : yay et bash-completion sur l'invité, guide au MOTD
Une image cloud Arch est nue : ni bash-completion, ni accès à l'AUR. Les
deux arrivent avec l'amorçage, sur la seule branche pacman. yay-bin
plutôt que yay, dont le paquet source compile Go pour le même outil ; la
construction reste sous l'utilisateur de la VM, makepkg refusant root. Le
« || true » qui ferme le bloc porte : le groupe est le dernier membre de
sa liste « || », donc set -e s'y applique et un sudo en échec emporterait
l'installation entière. Le guide de connexion n'annonce yay que si une
installation a eu lieu.

Vérifié : 10 tests, dont « bash -n » sur la commande distante entière et
la survie du bloc sous set -e avec un PATH vide.

--- EN ---

An Arch cloud image is bare: no bash-completion, no AUR access. Both come
with the bootstrap, on the pacman branch alone. yay-bin rather than yay,
whose source package compiles Go for the same tool; the build stays under
the VM user, makepkg refusing root. The « || true » closing the block
carries weight: the group is the last member of its « || » list, so set -e
applies inside it and one failing sudo would take the whole install down.
The login guide announces yay only when an install ran.

Checked: 10 tests, among them « bash -n » over the whole remote command
and the block surviving set -e with an empty PATH.

Assisted-by: Claude Opus 5
2026-09-02 08:04:05 -04:00
736ab3b676 [FIX] qemu setup-host : demander avant de redémarrer l'hôte
Accepter d'installer les paquets QEMU redémarrait la machine sans autre
question : --assume-yes couvrait le gestionnaire de paquets, et la
commande y ajoutait --reboot-if-needed, qui ne demandait rien. Une seule
constante servait la VM qu'on vient de créer et le poste qui la crée.
--reboot-if-needed PROPOSE désormais, sur /dev/tty pour rester visible
quand la sortie est un tuyau, et vaut non par défaut ; un refus laisse
les paquets posés et dit quoi faire. --assume-yes-reboot est le seul
consentement muet, que seul le profil invité porte.

Vérifié : 7 tests, rougis par deux mutations — assume_yes rouvrant la
porte, le menu hôte reprenant le drapeau.

--- EN ---

Accepting the QEMU package install rebooted the machine with no further
question: --assume-yes covered the package manager, and the command
added --reboot-if-needed, which asked nothing. One constant served both
the VM just created and the workstation creating it. --reboot-if-needed
now OFFERS, on /dev/tty so it stays visible when output is a pipe, and
defaults to no; a refusal leaves the packages in place and says what to
do. --assume-yes-reboot is the only silent consent, carried by the guest
profile alone.

Checked: 7 tests, turned red by two mutations — assume_yes reopening the
door, the host menu taking the flag back.

Assisted-by: Claude Opus 5
2026-09-02 07:38:11 -04:00
f12e79c3a9 [ADD] qemu : déployer Proxmox VE (amd64, arm64)
Proxmox ne publie aucune image cloud : son ISO est un installateur qui formate
le disque. On prend donc la voie que l'amont documente lui-même — Proxmox VE
sur Debian — depuis l'image cloud trixie, partagée avec un déploiement
Debian 13 au lieu d'être téléchargée deux fois.

s390x n'y est pas et n'y sera pas par cette voie : le dépôt n'a aucun index
binary-s390x. arm64 y est, officiel depuis PVE 9. Le catalogue le dit AVANT le
déploiement, au lieu d'échouer au premier apt.

Vérifié sur une VM réelle : pve-manager 9.2.11, noyau 7.0.14-12-pve, quatre
services actifs, interface web en HTTP 200.

--- EN ---

Proxmox publishes no cloud image: its ISO is an installer that formats the
disk. So we take the path upstream documents itself — Proxmox VE on Debian —
from the trixie cloud image, shared with a Debian 13 deployment instead of
being downloaded twice.

s390x is not there and will not be by this route: the repository has no
binary-s390x index. arm64 is, official since PVE 9. The catalog says so BEFORE
the deployment rather than failing at the first apt.

Verified on a real VM: pve-manager 9.2.11, kernel 7.0.14-12-pve, four services
active, web UI answering HTTP 200.

Assisted-by: Claude Opus 5
2026-08-23 03:28:03 -04:00
22d30a1504 [FIX] security: redact the master password from every output
CodeQL raised seven high-severity alerts on this branch. Three were real,
and the same secret was behind all of them: the Odoo master password,
which db_restore appends to its command line as soon as the database
declares one.

The command itself was printed raw -- "print(arg)" -- so the password
reached stdout, and any terminal capture with it. The probe output was
logged raw too, and a refused attempt echoes the command it tried.

Wider than that: the runner filtered the command it was about to run, but
not what came back. A tool that reprints its own arguments -- "set -x", a
traceback, odoo_bin.sh -- put the secret straight back into the terminal
AND into the log file the sink writes. Every subprocess line now goes
through the same filter as the command.

The four remaining alerts sit on expressions already wrapped in
redact_secrets(). CodeQL does not cross re.sub, so it cannot see the
barrier; the mitigation is real and they are false positives.

--- FR ---

CodeQL a levé sept alertes de sévérité haute sur cette branche. Trois
étaient réelles, et le même secret était derrière : le mot de passe maître
d'Odoo, que db_restore ajoute à sa ligne de commande dès que la base en
exige un.

La commande elle-même était imprimée telle quelle — « print(arg) » — donc
le mot de passe atteignait la sortie standard, et toute capture de
terminal avec elle. La sortie de la sonde était journalisée brute
également, et un essai refusé réaffiche la commande tentée.

Plus large : le lanceur filtrait la commande qu'il allait exécuter, mais
pas ce qui en revenait. Un outil qui réaffiche ses propres arguments —
« set -x », une trace, odoo_bin.sh — remettait le secret dans le terminal
ET dans le fichier de journal. Chaque ligne du sous-processus passe
désormais par le même filtre que la commande.

Les quatre alertes restantes portent sur des expressions déjà entourées de
redact_secrets(). CodeQL ne franchit pas re.sub et ne voit donc pas la
barrière ; la mitigation est réelle, ce sont des faux positifs.

Assisted-by: Claude Opus 5
2026-08-23 02:11:50 -04:00
a55b03e199 [ADD] qemu : prendre le GPU de l'hôte, et régler le matériel des VM
Une VM graphique sans accélération rend tout par le processeur : le bureau,
et l'émulateur Android qui tourne dedans — 32 % d'images en retard, mesuré.
Le déploiement prend donc le GPU de l'hôte dès qu'un nœud de rendu existe.

Une VM déjà installée n'avait aucune voie : ni vCPU, ni RAM, ni 3D. Le menu
d'état les règle maintenant, pendant qu'elle est éteinte — le seul moment où
libvirt les lit.

Trois pièges du terrain : « --memory N » ne touche que le ballon, l'ajout
d'egl-headless n'est pas idempotent, et son retrait sans cible emporte la
console VNC. Vérifié sur un domaine jetable, 459 tests verts.

--- EN ---

A graphical VM without acceleration renders everything on the CPU: the
desktop, and the Android emulator inside it — 32 % janky frames, measured.
The deployment now takes the host GPU as soon as a render node exists.

An installed VM had no path at all: no vCPU, no RAM, no 3D. The state menu
now sets them while the VM is shut off — the only moment libvirt reads them.

Three field traps: "--memory N" only moves the balloon, adding egl-headless
is not idempotent, and removing it untargeted takes the VNC console with it.
Verified on a throwaway domain, 459 tests green.

Assisted-by: Claude Opus 5
2026-08-23 02:07:42 -04:00
75dbeb3258 [ADD] qemu guide: dire comment démarrer le bureau, sur les VM qui en ont un
Une VM graphique peut arriver sur une console texte — graphical.target est
atteinte avant que le paquet du bureau soit là, et « systemctl enable gdm » rend
0 sans rien faire sur Debian et Ubuntu, où l'unité n'a pas de WantedBy. La
commande qui répare tient sur une ligne ; encore faut-il la lire quelque part.

Le guide de connexion porte donc un bloc « Bureau », avec l'état et le
« enable --now ». Il n'apparaît que si la VM a été déployée avec un bureau :
sur un serveur, ces commandes ne mèneraient à aucune unité. Le drapeau existait
déjà côté déploiement, il n'y avait qu'à le passer.

--- EN ---

A graphical VM can land on a text console — graphical.target is reached before
the desktop package exists, and "systemctl enable gdm" returns 0 doing nothing
on Debian and Ubuntu, where the unit has no WantedBy. The command that repairs
it is one line; it still has to be readable somewhere.

The login guide therefore carries a "Desktop" block, with the state and the
"enable --now". It only shows when the VM was deployed with a desktop: on a
server those commands would point at no unit. The flag already existed on the
deploy side; it only had to be passed along.

Assisted-by: Claude Opus 5
2026-08-23 02:07:42 -04:00
57ab0b506f [ADD] qemu: greet the SSH login with the distro's own commands
The catalogue spans four package managers and the operator changes
distribution at every deployment, yet nothing in the VM said which one it
was. /etc/motd now carries the commands of the machine you just entered,
and the host's git identity lands in ~/.gitconfig so a commit made there
is not signed erplibre@<vm-name>.

The seven cloud images were mounted read-only to settle the mechanism:
sshd is PrintMotd no everywhere and pam_motd shows the file, so it appears
once and never for ssh host 'command'. Checked: cloud-init schema reports
Valid schema on the 8 catalogue combinations, the YAML round-trip is
byte-identical, and the s390x initrd was rebuilt and unpacked. Its
early_command gained the `true` guard it lacked: the last diagnostic
returns 1 when enc1 is absent, stopping the installer it was meant to
explain.

--- FR ---

Le catalogue couvre quatre gestionnaires de paquets et l'opérateur change
de distribution à chaque déploiement, sans que rien dans la VM ne dise
laquelle. /etc/motd porte maintenant les commandes de la machine où l'on
vient d'entrer, et l'identité git de l'hôte atterrit dans ~/.gitconfig :
un commit fait là ne porte plus erplibre@<nom-de-vm>.

Les sept images cloud ont été montées en lecture seule pour trancher le
mécanisme : sshd est en PrintMotd no partout et c'est pam_motd qui affiche
le fichier, donc un seul affichage, et jamais pour ssh hôte 'commande'.
Vérifié : cloud-init schema rend Valid schema sur les 8 combinaisons du
catalogue, l'aller-retour YAML est octet pour octet, et l'initrd s390x a
été reconstruit puis déplié. Son early_command a reçu la garde `true` qui
lui manquait : son dernier diagnostic rend 1 quand enc1 est absente, et
arrêtait l'installateur qu'il devait éclairer.

Assisted-by: Claude Opus 5
2026-08-23 02:07:42 -04:00
c87cd2f5bd [FIX] install : os-release au lieu de lsb_release, collision d'IP mieux vue
Deux echecs distincts sur les VM Debian s390x posees par l'installateur.

lsb_release vient du paquet lsb-release, livre avec la tache
« standard ». Les images cloud l'ont ; une Debian posee par
debian-installer, non. Les trois variables devenaient VIDES et le script
concluait « Your version of Ubuntu is not supported » sur une Debian.
/etc/os-release appartient a systemd, il est toujours la, et donne ID,
VERSION_ID et VERSION_CODENAME sans rien installer.

L'autre echec etait pire : l'adresse fixe choisie appartenait deja a une
machine du parc, et l'installation ERPLibre s'est deroulee SUR CETTE
DERNIERE. Le journal ne le disait qu'a demi-mot — « git is already the
newest version », impossible sur un systeme que d-i vient de poser. Un
essai sur le port 22 avec 0,4 s laissait passer toute machine eteinte ou
filtree. On interroge desormais le voisinage ARP, puis ICMP, puis SSH.

--- EN ---

Two distinct failures on Debian s390x VMs laid down by the installer.

lsb_release comes from the lsb-release package, shipped with the
"standard" task. Cloud images have it; a Debian installed by
debian-installer does not. All three variables came out EMPTY and the
script concluded "Your version of Ubuntu is not supported" on a Debian.
/etc/os-release belongs to systemd, is always there, and gives ID,
VERSION_ID and VERSION_CODENAME without installing anything.

The other failure was worse: the chosen static address already belonged
to a machine in the fleet, and the ERPLibre install ran ON THAT ONE. The
log only hinted at it — "git is already the newest version", impossible
on a system d-i just laid down. A port-22 probe with 0.4 s let through
any machine that was off or filtered. We now check the ARP neighbourhood,
then ICMP, then SSH.

Assisted-by: Claude Opus 5
(cherry picked from commit c73db1642a676ece1a06cdbdac3e9cfa5b526f3c)
2026-08-23 02:07:42 -04:00
b181ad56e8 [FIX] qemu debian s390x : rallumer la VM quand l'installateur a fini
« This domain is not running » apres une installation reussie. Le disque
portait 1,22 Gio et le XML persistant amorcait deja sur « hd » : rien
n'avait echoue, la VM etait simplement eteinte.

virt-install mene l'installation en deux temps — amorcage transitoire
sur kernel+initrd, puis configuration definitive sur disque — et le
passage se fait par un ARRET. C'est virt-install qui rallume ensuite,
sauf qu'avec « --wait 0 » il est deja parti.

On ne peut pas le laisser attendre : sous emulation l'installation dure
des heures, et le deploiement rendrait la main a ce rythme. Un veilleur
detache fait donc le dernier geste, avec 6 h de garde.

Mesure : domaine « shut off », veilleur lance, domaine « running ».
Et la VM installee repond en SSH.

--- EN ---

"This domain is not running" after a successful install. The disk held
1.22 GiB and the persistent XML already booted from "hd": nothing had
failed, the VM was simply powered off.

virt-install runs the install in two stages — a transient kernel+initrd
boot, then the final disk-boot config — and the handover goes through a
SHUTDOWN. virt-install powers it back on afterwards, except that with
"--wait 0" it is already gone.

We cannot let it wait: under emulation the install takes hours, and
deployment would return at that pace. So a detached watcher makes the
last move, with a 6 h guard.

Measured: domain "shut off", watcher started, domain "running". And the
installed VM answers over SSH.

Assisted-by: Claude Opus 5
(cherry picked from commit 9c6cdb7f14ca504fd9d0855ba0dacc3dbf43c04f)
2026-08-23 02:07:42 -04:00
58da6cdacd [FIX] qemu debian s390x : desactiver network-console, reclamer partman-auto
Deux blocages, deux mecanismes propres a IBM Z.

network-console n'est pas une question a laquelle repondre : il demarre
sshd et ATTEND une connexion, indefiniment. Preseeder son mot de passe
ne fait avancer que d'un ecran. d-i prevoit le levier — un composant
dont « .isinstallable » sort en erreur quitte le menu. On ajoute donc a
l'initrd une version qui refuse toujours ; le fichier ecrit APRES
l'original prend sa place, le noyau depliant le cpio sequentiellement.

partman-auto n'est pas tire d'office sur s390x, ou la voie attendue est
le partitionnement DASD manuel. Mesure : « /lib/partman/
automatically_partition/ No such file or directory », d'ou « No root
file system is defined ». anna/choose_modules le reclame.

Mesure apres correctif : recette atomic appliquee, aucun ecran bloquant,
l'installateur deballe le systeme de base.

--- EN ---

Two stops, two IBM Z mechanisms.

network-console is not a question to answer: it starts sshd and WAITS
for a connection, forever. Preseeding its password only advances one
screen. d-i provides the lever — a component whose ".isinstallable"
exits non-zero leaves the menu. So the initrd gets a version that always
refuses; the file written AFTER the original wins, since the kernel
unpacks the cpio sequentially.

partman-auto is not pulled by default on s390x, where manual DASD
partitioning is the expected path. Measured: "/lib/partman/
automatically_partition/ No such file or directory", hence "No root file
system is defined". anna/choose_modules asks for it.

Measured after the fix: atomic recipe applied, no blocking screen, the
installer unpacks the base system.

Assisted-by: Claude Opus 5
(cherry picked from commit 1fb06ad84b65f43e9ffd1604b4e3d3a7aef9aaf2)
2026-08-23 02:07:42 -04:00
788c17dbb5 [FIX] qemu debian s390x : adresse fixe propre a chaque VM
« Premiere libre en partant du haut » donnait la MEME adresse a deux VM
deployees en parallele : ni l'une ni l'autre n'est montee quand l'autre
cherche, donc aucune ne voit l'autre. Mesure — debian-12 et debian-13
ont tous deux pris .250 et se sont disputes l'adresse, une seule
survivant. C'est ce qui faisait echouer le 12 quand le 13 passait.

Le depart du balayage vient desormais du NOM de la VM, par crc32. Les
noms different toujours, la collision disparait, et le tirage reste
stable d'un redeploiement a l'autre. Le balayage garde ses garde-fous :
baux existants et adresses qui repondent restent ecartes.

Verifie : debian-12 -> .216, debian-13 -> .218.

--- EN ---

"First free from the top" gave the SAME address to two VMs deployed in
parallel: neither is up when the other looks, so neither sees the other.
Measured — debian-12 and debian-13 both took .250 and fought over it,
only one surviving. That is what made 12 fail while 13 went through.

The scan now starts from the VM NAME, via crc32. Names always differ,
the collision is gone, and the draw stays stable across redeployments.
The scan keeps its guards: existing leases and answering addresses are
still skipped.

Verified: debian-12 -> .216, debian-13 -> .218.

Assisted-by: Claude Opus 5
(cherry picked from commit 91592383e213ad98873125866e6120e5da5874fe)
2026-08-23 02:07:42 -04:00
01daacba22 [ADD] qemu debian s390x : repondre au mot de passe de network-console
Sur IBM Z, d-i propose systematiquement de poursuivre par SSH — la
console y est historiquement limitee. Il refuse un mot de passe vide et
s'arretait sur « Empty password ».

Preseede, le mot de passe passe. Mais l'ecran suivant montre que cela ne
suffit PAS : network-console demarre sshd et attend une connexion de
l'utilisateur « installer ». Il ne rend jamais la main. Le rendre non
assiste demande de l'empecher de s'executer, pas de lui repondre.

Le secret ne vit que le temps de l'installateur, sur le reseau libvirt,
et disparait avec lui.

--- EN ---

On IBM Z, d-i always offers to continue over SSH — the console there is
historically limited. It refuses an empty password and stopped on
"Empty password".

Preseeded, the password goes through. But the next screen shows this is
NOT enough: network-console starts sshd and waits for the "installer"
user to connect. It never returns. Making this unattended requires
preventing it from running, not answering it.

The secret lives only for the installer's lifetime, on the libvirt
network, and vanishes with it.

Assisted-by: Claude Opus 5
(cherry picked from commit 13f0f201678d2ef866fb2342ec16f958d44b0351)
2026-08-23 02:07:42 -04:00
08ebf99c77 [FIX] qemu debian s390x : adresse fixe, l'initrd ne sait pas faire de DHCP
Le syslog de d-i a tranche : « Menu item 'netcfg-static' selected », puis
« Taking down interface enc1 ». netcfg-dhcp n'apparait JAMAIS — il n'est
pas dans l'initrd s390x, et aucun variant netboot n'existe pour cette
architecture (404 sur trixie comme sur bookworm).

Aucun DHCP n'etait donc tente. Sept hypotheses ont cherche pourquoi il
echouait ; il n'avait jamais lieu. C'est la convention IBM Z, ou le
reseau se donne au parmfile.

deploy_qemu choisit desormais une adresse libre en HAUT de la plage —
dnsmasq attribue depuis le bas — et la preseede. Mesure : l'ecran
d'adressage statique a disparu, l'installateur poursuit.

--- EN ---

d-i's syslog settled it: "Menu item 'netcfg-static' selected", then
"Taking down interface enc1". netcfg-dhcp NEVER appears — it is not in
the s390x initrd, and no netboot variant exists for this architecture
(404 on trixie and bookworm alike).

So no DHCP was ever attempted. Seven hypotheses looked for why it
failed; it never happened. This is the IBM Z convention, where the
network is given in the parmfile.

deploy_qemu now picks a free address at the TOP of the range — dnsmasq
allocates from the bottom — and preseeds it. Measured: the static
addressing screen is gone, the installer moves on.

Assisted-by: Claude Opus 5
(cherry picked from commit 8c630969a605ec191a65dc93896014ac9e3a1227)
2026-08-23 02:07:42 -04:00
56803b3807 [REF] qemu debian s390x : retirer les reglages netcfg sans effet
Quatre lignes avaient ete empilees sur des hypotheses successives —
link_wait_timeout, dhcp_timeout, dhcp_options, choose_interface. Aucune
n'a jamais ete verifiee, et l'essai nu le montre : sans elles, le
comportement est EXACTEMENT le meme.

Elles restaient donc comme du bruit, en laissant croire que la question
du reseau avait ete traitee. Le blocage sur l'adressage statique
persiste, avec un lien UP,LOWER_UP et un DHCP qui repond en deux
secondes a un udhcpc manuel.

--- EN ---

Four lines had been stacked on successive hypotheses —
link_wait_timeout, dhcp_timeout, dhcp_options, choose_interface. None
was ever verified, and the bare run shows it: without them the behaviour
is EXACTLY the same.

They remained as noise, suggesting the network question had been dealt
with. The static-addressing stop persists, with a UP,LOWER_UP link and a
DHCP server answering a manual udhcpc in two seconds.

Assisted-by: Claude Opus 5
(cherry picked from commit f52bc66a3b70075831e1a7bfdd2dd7b2a352ad32)
2026-08-23 02:07:42 -04:00
ec8a44b9ae [ADD] qemu debian s390x : activer enc1 et tracer avant netcfg
Le blocage sur l'adressage statique n'etait pas diagnosticable : netcfg
ecrit ses traces dans le syslog INTERNE de d-i, qu'on ne lit qu'en
ouvrant un shell a la main sur une console serie.

Un preseed/early_command ecrit desormais l'etat du reseau sur la
console, donc dans le journal. Il a immediatement montre que l'interface
etait ETEINTE — « enc1: <BROADCAST,MULTICAST> qdisc noop » — alors qu'un
udhcpc manuel obtenait un bail en deux secondes. Le reseau n'a jamais
ete en cause.

La commande allume donc enc1 avant que netcfg ne decide. L'interface est
bien UP,LOWER_UP ensuite, ce qui est correct en soi — mais netcfg
demande TOUJOURS une adresse statique. La cause reste a trouver.

--- EN ---

The static-addressing stop was not diagnosable: netcfg writes its traces
to d-i's INTERNAL syslog, readable only by opening a shell by hand on a
serial console.

A preseed/early_command now writes the network state to the console,
hence to the log. It immediately showed the interface was DOWN — "enc1:
<BROADCAST,MULTICAST> qdisc noop" — while a manual udhcpc obtained a
lease in two seconds. The network was never at fault.

So the command brings enc1 up before netcfg decides. The interface is
UP,LOWER_UP afterwards, which is right in itself — but netcfg STILL asks
for a static address. The cause remains to be found.

Assisted-by: Claude Opus 5
(cherry picked from commit e594fe5eab87d5060b878e44f9cf484e6d7b9e7f)
2026-08-23 02:07:42 -04:00
a33684ddd1 [FIX] qemu debian s390x : retirer auto=true, inutile en preseed local
« auto=true » vise le preseed par URL : il reordonne l'installation pour
monter le reseau avant tout le reste, afin d'aller chercher le fichier.
Le notre est embarque dans l'initrd, il n'y a rien a telecharger.

Le garder faisait donc courir netcfg tres tot pour rien. Cela n'a pas
suffi a debloquer l'installation — le blocage sur l'adressage statique
demeure — mais l'argument n'avait aucune raison d'etre la.

--- EN ---

"auto=true" targets URL preseeding: it reorders the install to bring the
network up before anything else, so the file can be fetched. Ours is
embedded in the initrd; there is nothing to download.

Keeping it ran netcfg very early for no reason. This did not unblock the
install — the static-addressing stop remains — but the argument had no
business being there.

Assisted-by: Claude Opus 5
(cherry picked from commit b805d352e0c3505cdb2522e1023c70e0dc506f15)
2026-08-23 02:07:42 -04:00
12db87e1c2 [FIX] qemu debian s390x : journal de console et question reseau Z
« L'installation a echoue, pas de sortie pertinente » : une console pty
ne garde RIEN. Quand d-i s'arrete, il l'ecrit a l'ecran d'une VM que
personne ne regarde, et il ne reste rien a lire. La voie installateur
ecrit desormais un journal qui survit a l'arret du domaine.

Ce journal a immediatement nomme la premiere cause : d-i s'arretait sur
« Configure the network device », une question propre a s390x posee par
le udeb s390-netdevice — ctc, qeth, iucv ou virtio. Elle n'a AUCUNE
valeur par defaut, donc priority=critical ne la saute pas. Preseedee a
virtio, elle disparait.

Reste un second arret, non resolu : netcfg n'essaie aucun DHCP et tombe
sur la saisie d'une adresse statique. Ni le delai de lien, ni le nom
explicite de l'interface n'y changent quoi que ce soit.

--- EN ---

"The install failed, no relevant output": a pty console keeps NOTHING.
When d-i stops, it says so on the screen of a VM nobody watches, and
nothing is left to read. The installer path now writes a log that
outlives the domain.

That log immediately named the first cause: d-i stopped on "Configure
the network device", an s390x-only question from the s390-netdevice
udeb — ctc, qeth, iucv or virtio. It has NO default, so
priority=critical does not skip it. Preseeded to virtio, it is gone.

A second stop remains, unsolved: netcfg attempts no DHCP and falls to
static address entry. Neither the link timeout nor naming the interface
explicitly changes anything.

Assisted-by: Claude Opus 5
(cherry picked from commit d1a371a8f4775e8488522fba24a79775a5a101e8)
2026-08-23 02:07:42 -04:00
4df994f721 [FIX] todo qemu : lire les distros par arch dans deploy_qemu
L'ecran de deploiement portait sa PROPRE copie de S390X_DISTROS, sous un
commentaire promettant qu'elle restait « coherente avec deploy_qemu.py ».
Une copie ne tient aucune promesse : Debian a gagne s390x la-bas et
l'ecran ne le proposait toujours pas.

_qemu_arch_distros lit desormais ARCH_DISTRO_SUPPORT, et _qemu_arches_for
y passe aussi pour que « toutes les architectures » n'offre rien que
deploy_qemu refuserait ensuite. Les tuples locaux restent en repli si
l'import echoue. L'import est memorise : le catalogue l'interrogeait une
fois par couple (distro, version).

Plancher memoire de 2048 Mio sur la voie installateur, annonce et jamais
abaissant : d-i deplie un systeme de fichiers en RAM la ou une image
cloud arrive installee, et le manque s'y voit comme un ecran fige.

--- EN ---

The deploy screen carried its OWN copy of S390X_DISTROS, under a comment
promising it stayed "consistent with deploy_qemu.py". A copy keeps no
promise: Debian gained s390x over there and the screen still did not
offer it.

_qemu_arch_distros now reads ARCH_DISTRO_SUPPORT, and _qemu_arches_for
goes through it too, so "all architectures" offers nothing deploy_qemu
would later refuse. The local tuples remain as a fallback if the import
fails. The import is memoised: the catalogue queried it once per
(distro, version) pair.

A 2048 MiB memory floor on the installer path, announced and never
lowering: d-i unpacks a filesystem into RAM where a cloud image arrives
installed, and running short shows up as a frozen screen.

Assisted-by: Claude Opus 5
(cherry picked from commit f0ee70c1ac43ba2bc9f5fb78fe71f821a15daf7d)
2026-08-23 02:07:42 -04:00
9641a5b749 [ADD] qemu : Debian sur s390x, par debian-installer
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)
2026-08-23 02:07:42 -04:00
75498384c9 [ADD] qemu: build the tunnel to the remote desktop
A "Remote desktop tunnel" entry under SSH configuration. It lists the
targets, resolves them, and composes the full command -- nothing to fill
in.

todo.py runs on the libvirt HOST; the tunnel starts from the workstation.
It cannot open it, but it alone knows the VM's private IP, its port and
the address through which it was reached. That last one comes from
SSH_CONNECTION, whose third field is exactly the server address used --
far safer than a "hostname" that may resolve to nothing outside.

When ~/.ssh/config already carries the entry, the tunnel takes it:
"ssh -N -L 5902:localhost:5901 <vm>". ProxyJump makes the route and
"localhost" means the VM's OWN loopback, so the tunnel survives an IP
change. That config is also the right source of targets, not the local
libvirt: a graphical VM is often nested, and virsh would only ever list
the orchestrator.

Two details: the hypervisor console needs VNC bound to the loopback, as
"listen=none" opens no socket at all; and two menu entries had no icon.

--- FR ---

Une entrée « Tunnel bureau distant » sous Configuration SSH. Elle liste
les cibles, les résout, et compose la commande complète — rien à remplir.

todo.py tourne sur l'HÔTE libvirt ; le tunnel, lui, part du poste de
travail. Il ne peut donc pas l'ouvrir, mais il est le seul à connaître
l'IP privée de la VM, son port et l'adresse par laquelle on l'a joint.
Cette dernière vient de SSH_CONNECTION, dont le troisième champ est
exactement l'adresse serveur utilisée — bien plus sûr qu'un « hostname »
qui peut ne rien résoudre depuis l'extérieur.

Quand ~/.ssh/config porte déjà l'entrée, le tunnel l'emprunte :
« ssh -N -L 5902:localhost:5901 <vm> ». Le ProxyJump fait la route et
« localhost » désigne le bouclage DE LA VM, si bien que le tunnel survit à
un changement d'IP. Ce fichier est aussi la bonne source de cibles, pas le
libvirt local : une VM graphique est souvent imbriquée, et virsh ne
listerait jamais que l'orchestrateur.

Deux détails : la console de l'hyperviseur exige un VNC sur la boucle
locale, « listen=none » n'ouvrant aucun socket ; et deux entrées de menu
n'avaient pas d'icône.

Assisted-by: Claude Opus 5
2026-08-17 00:40:01 -04:00
9c470f065e [ADD] qemu: openSUSE Leap 16.0, numbered, as the default
The catalogue only offered openSUSE Tumbleweed, a rolling release with
no version number. Nearly every openSUSE incident in this series came
from that: the cloud image is a snapshot lagging behind its own repos,
hence the mandatory "zypper dup", and two VMs deployed the same day saw
git-daemon 2.54 on s390x against 2.55 on amd64. For an ERP platform,
that is not what should be offered by default.

Leap 16.0 is numbered, stable, and publishes the three architectures
that matter -- verified, x86_64, aarch64 and s390x all 200. It also
unifies its tree: no separate /ports/, unlike Tumbleweed, whose
equivalent paths 404 for Leap.

Tumbleweed stays on offer, as a bellwether for breakage to come. Two
things separate them in the scripts: the repository path, and "dup" --
which on Leap means CHANGING version, not updating.

--- FR ---

Le catalogue n'offrait qu'openSUSE Tumbleweed, une rolling sans numéro
de version. Presque tous les incidents openSUSE de la série venaient de
là : l'image cloud est un instantané en retard sur ses dépôts, d'où le
« zypper dup » obligatoire, et deux VM déployées le même jour ont vu
git-daemon 2.54 sur s390x contre 2.55 sur amd64. Pour une plateforme
ERP, ce n'est pas ce qu'on veut proposer par défaut.

Leap 16.0 est numérotée, stable, et publie les trois architectures qui
comptent — vérifié, x86_64, aarch64 et s390x en 200. Elle unifie de plus
son arbre : pas de /ports/ séparé, contrairement à Tumbleweed, dont les
chemins équivalents rendent 404 pour Leap.

Tumbleweed reste offerte, comme banc d'essai des ruptures à venir.
Deux points les séparent dans les scripts : le chemin des dépôts, et
« dup » — qui sur Leap sert à CHANGER de version, pas à mettre à jour.

Assisted-by: Claude Opus 5
2026-08-17 00:40:01 -04:00
7120732c25 [ADD] install: openSUSE support, mirrors and packages
Tumbleweed is the only catalog entry whose qpdf already clears the pikepdf
threshold: 12.3.2 against 12.2 required, so the half-hour qpdf build under
s390x emulation never runs there. It is also the only family foreign to
both RHEL and Debian, and it brings zypper, absent from the repository:
wired into the install_dev.sh dispatch, a dependency script, the remote
bootstrap and the desktop block.

Four SUSE traps, all met on real machines. Global options precede the
subcommand, and misplaced ones abort the call; without
"--auto-agree-with-licenses" zypper waits for an answer nobody gives in a
detached install. A compat package that PROVIDES another under a different
name makes zypper raise a conflict and drop the whole batch, so only what
nothing already provides is requested. pkg-config no longer exists as an
RPM, only as a capability. And a single mirror, unreachable one day, sent
everyone back to Europe -- three are probed in order now.

CentOS Stream is dropped again: it served as a canary but 10 duplicates
what Alma and Rocky already cover.

--- FR ---

Tumbleweed est la seule entrée du catalogue dont qpdf franchit déjà le
seuil de pikepdf : 12.3.2 contre 12.2 exigé, si bien que la demi-heure de
compilation de qpdf sous émulation s390x ne s'y déclenche jamais. C'est
aussi la seule famille étrangère à RHEL comme à Debian, et elle apporte
zypper, absent du dépôt : câblé dans l'aiguillage d'install_dev.sh, un
script de dépendances, l'amorçage distant et le bloc bureau.

Quatre pièges SUSE, tous rencontrés sur machine réelle. Les options
globales précèdent la sous-commande, mal placées elles arrêtent l'appel ;
sans « --auto-agree-with-licenses » zypper attend une réponse que personne
ne donne dans une installation détachée. Un paquet compat qui FOURNIT un
autre sous un nom différent fait lever un conflit à zypper, qui abandonne
le lot entier : on ne demande donc que ce que rien ne fournit déjà.
pkg-config n'existe plus comme RPM, seulement comme capacité. Et un miroir
unique, injoignable un jour, renvoyait tout le monde en Europe — trois
sont désormais sondés dans l'ordre.

CentOS Stream repart : il servait de canari, mais 10 double ce qu'Alma et
Rocky couvrent déjà.

Assisted-by: Claude Opus 5
2026-08-16 23:33:49 -04:00