dsoxlab 0.2.0__tar.gz → 0.2.2__tar.gz

dsoxlab-0.2.2/.github/workflows/appliance.yml

@@ -0,0 +1,261 @@
+# Construit l'appliance dsoxlab et l'attache à une Release.
+#
+# Workflow SÉPARÉ de `release.yml`, pour deux raisons :
+#
+#   1. `workflow_dispatch` permet de l'éprouver sans poser de tag. Greffé à la
+#      release, ce job n'aurait tourné qu'au prochain tag mineur, c'est-à-dire
+#      jamais avant d'en avoir besoin : un workflow qu'on n'a jamais joué est un
+#      workflow qui ne marche pas ;
+#   2. un build d'image de vingt minutes ne doit ni retarder une publication PyPI,
+#      ni pouvoir la faire échouer.
+#
+# Sur les tags, il ne se déclenche que sur les **mineurs** (`v0.3.0`, `v0.4.0`) :
+# l'image n'épingle pas la version de dsoxlab, elle installe la dernière au
+# premier démarrage, donc republier un gigaoctet à chaque correctif coûterait
+# cher pour ne rien changer.
+
+name: Appliance
+
+on:
+  push:
+    tags: ["v[0-9]+.[0-9]+.0"]
+  workflow_dispatch:
+    inputs:
+      tag:
+        description: "Release existante à laquelle attacher les images (vide = ne rien attacher)"
+        required: false
+        type: string
+
+permissions: {}
+
+concurrency:
+  group: appliance-${{ github.ref }}
+  cancel-in-progress: false
+
+jobs:
+  appliance:
+    name: Build the appliance image
+    # AFTER the Release exists, and never blocking it. A 20-minute image build
+    # must not delay a package that is already on PyPI, and its failure must not
+    # leave a version half-published.
+    runs-on: ubuntu-24.04
+    timeout-minutes: 120
+    permissions:
+      contents: write     # attach the assets to the existing Release
+      id-token: write     # provenance attestation
+      attestations: write
+    env:
+      # `/` has ~14 GB free on a runner, `/mnt` has ~70. Building anywhere else
+      # dies on disk space, twenty minutes in.
+      BUILD_DIR: /mnt/appliance
+
+    steps:
+      - name: Harden the runner
+        uses: step-security/harden-runner@e14015d583714f6e62063499dc959a02595150a1 # v2.21.1
+        with:
+          egress-policy: audit
+
+      - name: Checkout
+        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
+        with:
+          persist-credentials: false
+
+      - name: KVM must really be available
+        # The one fact this whole job rests on: GitHub-hosted Linux runners expose
+        # /dev/kvm. Checked FIRST — without acceleration the build would exceed the
+        # job limit, and the failure would arrive an hour later.
+        run: |
+          set -euo pipefail
+          test -e /dev/kvm || { echo "::error::no /dev/kvm on this runner"; exit 1; }
+          sudo apt-get update -qq
+          sudo apt-get install -y -qq qemu-system-x86 qemu-utils cpu-checker
+          kvm-ok
+          df -h / /mnt | tail -2
+
+      - name: Install Packer
+        run: |
+          set -euo pipefail
+          wget -qO- https://apt.releases.hashicorp.com/gpg \
+            | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
+          echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] \
+            https://apt.releases.hashicorp.com $(lsb_release -cs) main" \
+            | sudo tee /etc/apt/sources.list.d/hashicorp.list >/dev/null
+          sudo apt-get update -qq && sudo apt-get install -y -qq packer
+          packer version
+
+      - name: Resolve the Debian netinst ISO and its checksum
+        id: iso
+        # The checksum is read from Debian's signed SHA256SUMS rather than pinned
+        # here: a hash copied by hand is a hash that rots.
+        run: |
+          set -euo pipefail
+          base="https://cdimage.debian.org/debian-cd/current/amd64/iso-cd"
+          name="$(curl -fsSL "$base/SHA256SUMS" | grep -oE 'debian-[0-9.]+-amd64-netinst\.iso' | head -1)"
+          sum="$(curl -fsSL "$base/SHA256SUMS" | grep " $name\$" | cut -d' ' -f1)"
+          test -n "$name" && test -n "$sum"
+          echo "url=$base/$name" >> "$GITHUB_OUTPUT"
+          echo "sum=$sum" >> "$GITHUB_OUTPUT"
+          echo "ISO : $name"
+
+      - name: packer init && validate
+        working-directory: packer
+        env:
+          ISO_URL: ${{ steps.iso.outputs.url }}
+          ISO_SUM: ${{ steps.iso.outputs.sum }}
+        run: |
+          set -euo pipefail
+          mkdir -p "${BUILD_DIR}/out" "${BUILD_DIR}/tmp"
+          packer init .
+          packer validate \
+            -var "image_version=${GITHUB_REF_NAME#v}" \
+            -var "iso_url=${ISO_URL}" \
+            -var "iso_checksum=sha256:${ISO_SUM}" \
+            -var "output_directory=${BUILD_DIR}/out" .
+
+      - name: packer build
+        working-directory: packer
+        env:
+          PACKER_TMP_DIR: /mnt/appliance/tmp
+          ISO_URL: ${{ steps.iso.outputs.url }}
+          ISO_SUM: ${{ steps.iso.outputs.sum }}
+        run: |
+          set -euo pipefail
+          packer build \
+            -var "image_version=${GITHUB_REF_NAME#v}" \
+            -var "iso_url=${ISO_URL}" \
+            -var "iso_checksum=sha256:${ISO_SUM}" \
+            -var "output_directory=${BUILD_DIR}/out" .
+          ls -lh "${BUILD_DIR}/out"
+
+      - name: Derive the OVA from the qcow2
+        # No VirtualBox, no ovftool (proprietary). An OVA is a tar of three files,
+        # in THIS order: the .ovf, the .mf, then the disk — VirtualBox refuses the
+        # archive if the .ovf is not its first member.
+        #
+        # Verified locally before this workflow existed: the resulting OVA imports
+        # into VirtualBox 7.0 ("Successfully imported the appliance"), and the disk
+        # comes back byte-identical after the conversion.
+        run: bash packer/faire-ova.sh "${GITHUB_REF_NAME#v}" "${BUILD_DIR}/out"
+
+      - name: The OVF must validate against the DMTF schema
+        # VirtualBox imports almost anything; VMware checks. Since the same OVA
+        # is offered for both, the only way to keep that promise without a
+        # Broadcom licence is to hold the file to the specification it claims to
+        # follow. `xmllint` resolves the imported CIM schemas itself.
+        #
+        # Blocking on purpose: an OVF that no longer validates is exactly the
+        # kind of drift nothing else here would catch, and it would only show up
+        # on a user's machine.
+        run: |
+          set -euo pipefail
+          sudo apt-get install -y --no-install-recommends libxml2-utils
+          curl -fsS -o /tmp/dsp8023.xsd \
+            https://schemas.dmtf.org/ovf/envelope/1/dsp8023_1.1.0.xsd
+          ovf=$(mktemp -d)
+          tar -xf "${BUILD_DIR}"/out/*.ova -C "$ovf" --wildcards '*.ovf'
+          xmllint --noout --schema /tmp/dsp8023.xsd "$ovf"/*.ovf
+
+      - name: Every asset must stay within its budget
+        env:
+          # A BUDGET, not the 2 GB Release limit. Measured reference: 533 MiB for
+          # the qcow2 and 511 for the OVA, with 20 GiB of declared disk. A check
+          # set at the hard limit would silently wave through a 1.1 GB image the
+          # day the discard setting regresses — which is exactly how this recipe
+          # was found to be carrying 512 MiB of rubbish.
+          BUDGET_MIB: 800
+        run: |
+          set -euo pipefail
+          # `qemu-img info` and `check` give the real shape of the image: virtual
+          # size, allocated size, and the share of compressed clusters. Printed
+          # rather than guessed, so a regression is visible in the log.
+          for f in "${BUILD_DIR}"/out/*.qcow2; do
+            [ -f "$f" ] || continue
+            qemu-img info "$f"
+            qemu-img check "$f" || true
+          done
+
+          depasse=0
+          for f in "${BUILD_DIR}"/out/*.ova "${BUILD_DIR}"/out/*.qcow2; do
+            [ -f "$f" ] || continue
+            mib=$(( $(stat -c%s "$f") / 1024 / 1024 ))
+            echo "$(basename "$f") : ${mib} MiB (budget ${BUDGET_MIB})"
+            if [ "$mib" -gt "$BUDGET_MIB" ]; then
+              echo "::error::$(basename "$f") is ${mib} MiB, over the ${BUDGET_MIB} MiB budget."
+              echo "::error::Check the trim first: the log of 90-nettoyage.sh shows what fstrim returned."
+              depasse=1
+            fi
+          done
+          test "$depasse" -eq 0
+
+          ( cd "${BUILD_DIR}/out" && sha256sum ./*.ova ./*.qcow2 > SHA256SUMS && cat SHA256SUMS )
+
+      - name: Attest build provenance
+        uses: actions/attest-build-provenance@4d101475d8b20a2381f78447822ac1eab6504dd8 # v4.2.2
+        with:
+          subject-path: |
+            /mnt/appliance/out/*.ova
+            /mnt/appliance/out/*.qcow2
+
+      - name: Attach the images to the Release
+        # Sur un essai manuel sans tag, il n'y a rien à quoi les attacher : le
+        # build seul a prouvé ce qu'on voulait prouver.
+        if: github.event_name == 'push' || inputs.tag != ''
+        env:
+          GH_TOKEN: ${{ github.token }}
+          TAG: ${{ inputs.tag || github.ref_name }}
+          REPO: ${{ github.repository }}
+        run: |
+          set -euo pipefail
+          gh release upload "$TAG" --repo "$REPO" --clobber \
+            "${BUILD_DIR}"/out/*.ova \
+            "${BUILD_DIR}"/out/*.qcow2 \
+            "${BUILD_DIR}/out/SHA256SUMS"
+
+      - name: Keep only the last images, not all of them
+        # Roughly 900 MB per minor version, forever, for images that are worth
+        # nothing once the next one exists: the image pins NO dsoxlab version,
+        # it installs the latest at first boot. An old one therefore offers no
+        # reproducibility — only the weight.
+        #
+        # Two are kept, not one: if the newest turns out to be broken, the
+        # previous one is the fallback while it gets fixed. Below that there is
+        # no safety net; above, we are archiving for nobody.
+        #
+        # Only the images are removed. The Releases themselves, their changelog
+        # and the Python distributions stay: they are small, and pip and uv
+        # resolve versions through them.
+        if: github.event_name == 'push' || inputs.tag != ''
+        env:
+          GH_TOKEN: ${{ github.token }}
+          REPO: ${{ github.repository }}
+          GARDEES: 2
+        run: |
+          set -euo pipefail
+          mapfile -t tags < <(
+            gh release list --repo "$REPO" --limit 100 \
+              --json tagName,createdAt \
+              --jq 'sort_by(.createdAt) | reverse | .[].tagName'
+          )
+          porteuses=0
+          for tag in "${tags[@]}"; do
+            images=$(gh release view "$tag" --repo "$REPO" --json assets \
+              --jq '.assets[].name
+                    | select(endswith(".ova") or endswith(".qcow2"))')
+            [ -n "$images" ] || continue
+            porteuses=$((porteuses + 1))
+            if [ "$porteuses" -le "$GARDEES" ]; then
+              echo "$tag : images conservées (${porteuses}/${GARDEES})"
+              continue
+            fi
+            echo "$tag : retrait des images"
+            while IFS= read -r nom; do
+              [ -n "$nom" ] || continue
+              gh release delete-asset "$tag" "$nom" --repo "$REPO" --yes
+              echo "  supprimé : $nom"
+            done < <(
+              gh release view "$tag" --repo "$REPO" --json assets \
+                --jq '.assets[].name
+                      | select(endswith(".ova") or endswith(".qcow2")
+                               or . == "SHA256SUMS")'
+            )
+          done

{dsoxlab-0.2.0 → dsoxlab-0.2.2}/CHANGELOG.fr.md

@@ -9,6 +9,170 @@ et le projet suit le [versionnage sémantique](https://semver.org/lang/fr/).
 
 ## [Non publié]
 
+## [0.2.2] - 2026-09-26
+
+### Ajouté
+
+- **L'appliance : une VM prête à jouer, construite par la CI** (issue #91,
+  déplacée au jalon 0.3.0 et désormais entamée). Pour Windows et macOS, où
+  `uv tool install dsoxlab` n'est pas une option. Sur Linux elle reste la mauvaise
+  réponse, et le README le dit : télécharger un demi-gigaoctet pour éviter une
+  commande n'a aucun sens.
+
+  `packer/` porte la recette (builder `qemu`, installation Debian 13 automatisée,
+  quatre scripts de provisioning) et `.github/workflows/appliance.yml` la construit
+  **sur un runner GitHub-hosted**, sans machine à nous : les runners Linux exposent
+  `/dev/kvm`, donc QEMU y est accéléré. Ce choix retire du même coup `ovftool`
+  (propriétaire) et VirtualBox de la chaîne : l'OVA est dérivée du qcow2 avec
+  `qemu-img` et `tar` seulement.
+
+  L'image **n'épingle rien**. Le premier démarrage installe le dernier dsoxlab, et
+  les hyperviseurs seulement si l'hôte expose la virtualisation imbriquée, vérifiée
+  en direct et jamais supposée. D'où sa reconstruction sur les **tags mineurs
+  seulement** : republier un demi-gigaoctet à chaque correctif coûterait cher pour
+  ne rien changer.
+
+  Mesuré, non estimé : **461 Mio** pour le qcow2 et **446 Mio** pour l'OVA,
+  construits en 4 min 50 s, contre un budget que le workflow impose à 800 Mio. Une
+  appliance comparable construite avec `virtualbox-iso` pèse 979 Mio.
+
+- **Le README présente désormais les deux façons d'entrer**, côte à côte :
+  installer l'outil, ou télécharger l'appliance. Il dit aussi laquelle est la
+  bonne sous Linux, plutôt que de les vendre à égalité.
+
+- **Seuls les deux derniers jeux d'images sont conservés sur les Releases.**
+  Environ 900 Mo par version mineure, pour toujours, pour des images qui
+  n'épinglent aucune version de dsoxlab et installent la dernière au premier
+  démarrage : une ancienne n'offre aucune reproductibilité, seulement son
+  poids. Deux plutôt qu'une, pour qu'une image cassée ait un recours. Les
+  Releases, leur changelog et les distributions Python ne sont pas touchés.
+
+- **L'OVA est proposée pour VMware autant que pour VirtualBox**, et le workflow
+  tient maintenant cette promesse : l'OVF est validé contre le schéma DMTF à
+  chaque build. VirtualBox importe à peu près n'importe quoi, VMware contrôle —
+  et sans licence Broadcom, la conformité à la spécification est la seule façon
+  honnête de tenir l'affirmation. La page de l'appliance dit franchement ce qui
+  a été éprouvé et ce qui ne l'a pas été, et qu'**Apple Silicon est hors de
+  portée** : les deux images sont x86-64, les runners arm64 de GitHub n'exposent
+  aucun `/dev/kvm` pour en construire une autre, et la virtualisation imbriquée
+  sur ces Mac n'existe qu'à partir du M3.
+
+### Corrigé
+
+- **Trois défauts de cette recette, chacun attrapé par une mesure et non par une
+  relecture.** Ils valent d'être consignés parce qu'ils sont du genre qui se livre
+  en silence :
+
+  `fstrim` **rend un succès sans rien libérer** quand le disque de build est
+  attaché en `discard=ignore`, qui est le défaut de Packer. L'invité annonçait
+  « 520.4 MiB trimmed » pendant que le qcow2 gardait tout : 1110 Mio d'artefact
+  contre 597 pour le témoin. Le disque est donc attaché en `unmap`, avec
+  `detect_zeroes=unmap` pour que la mise à zéro ne coûte rien, et le repli
+  `|| dd` qui ne se déclenchait jamais a disparu, avec les 17 Gio qu'il écrivait
+  quand il se déclenchait.
+
+  `vm_name` **n'avait pas d'extension**, et Packer n'en ajoute aucune : les globs
+  `*.qcow2` du contrôle de budget, des empreintes et de l'envoi n'auraient jamais
+  vu le fichier. Le premier build local, qui a produit `dsoxlab-appliance-dev`,
+  l'a prouvé.
+
+  Le contrôle de taille testait la **limite dure de 2 Go**, donc il aurait laissé
+  passer une image de 1,1 Gio le jour où le trim se recasse. C'est désormais un
+  **budget de 800 Mio**, avec `qemu-img info` et `check` affichés, et une erreur
+  qui dit où regarder.
+
+- **`lsb_release` n'existe plus** dès que la tâche `standard` quitte le preseed, or
+  `20-outils.sh` s'en servait pour le dépôt HashiCorp. Lu dans `/etc/os-release` à
+  la place : sans cela le build aurait échoué net.
+
+- **Dix défauts de plus, trouvés en jouant l'appliance plutôt qu'en relisant la
+  recette.** Chacun échappait à tous les contrôles précédents, et le premier à lui
+  seul rendait l'image inutilisable pour ceux à qui elle est destinée :
+
+  **Le réseau ne survivait pas au changement d'hyperviseur.** L'installateur
+  Debian fige le nom de l'interface qu'il a vue — `enp0s2` sous le QEMU qui
+  construit l'image — et ce nom dérive de la position PCI de la carte. Sous
+  VirtualBox, la carte s'appelle `enp0s17` : la configuration ne s'appliquait donc
+  à rien. L'appliance importée démarrait avec `enp0s17 DOWN`, un `resolv.conf`
+  sans le moindre `nameserver`, et un premier démarrage qui échouait sur
+  « Temporary failure in name resolution ». Rien n'était installé : ni dsoxlab, ni
+  les hyperviseurs, ni le bureau. Le réseau passe désormais par
+  `systemd-networkd`, dont le `[Match]` **décrit** la carte (`en*`, `eth*`) au
+  lieu de la nommer.
+
+  **Le premier démarrage se marquait fait même quand tout avait échoué**, et la
+  machine n'avait plus aucun moyen de se rattraper. Il dit maintenant ce qui a
+  échoué, ne pose pas de marqueur, et recommence au démarrage suivant. Il attend
+  aussi qu'un nom se résolve vraiment avant de commencer :
+  `network-online.target` était atteinte sans qu'aucun bail DHCP soit pris, d'où
+  les huit secondes du défaut ci-dessus.
+
+  **Root héritait du `HOME` de student** pendant la construction (`sudo -E`),
+  si bien que `terraform version` et `ansible-playbook --version` créaient un
+  `~/.ansible` et un `~/.terraform.d` appartenant à root. Ansible refusait alors
+  de démarrer pour l'apprenant, et dsoxlab rendait un `rc=5, Stats: {}` que rien
+  ne reliait à la cause. Corrigé par `sudo -H`, avec une ceinture `chown`.
+
+  **`ovmf` et `qemu-utils` manquaient** : sur Debian, tous deux ne sont que des
+  *recommandations* de `qemu-kvm`, donc `--no-install-recommends` les écartait.
+  Sans le premier, libvirt n'expose aucun firmware EFI et tout `provision`
+  s'arrête net ; sans le second, il ne sait pas créer de volume qcow2. Trouvés en
+  provisionnant pour de vrai depuis l'appliance — et le premier a été nommé en
+  2,3 secondes par le garde-fou de l'issue #234.
+
+  **Aucun pool libvirt `default`, aucune appartenance de groupe** : une Debian
+  fraîche n'en définit ni l'un ni l'autre, donc `doctor --strict` sortait en 9 et
+  `student` ne pouvait pas ouvrir `/dev/kvm`. Les deux sont posés au premier
+  démarrage, ce qui est aussi la raison de son redémarrage final.
+
+  **Le bureau n'avait pas de serveur X.** Même motif qu'`ovmf` et `qemu-utils`,
+  pour la troisième fois : `xserver-xorg` est une *recommandation* de `xfce4` et
+  de `lightdm`, jamais une dépendance, donc `--no-install-recommends` l'écartait.
+  `/usr/bin/Xorg` n'existait pas, `lightdm` était « failed », et la machine
+  arrivait sur une console malgré `graphical.target` — sans que rien ne relie ce
+  symptôme à un paquet manquant. Le serveur et ses pilotes vidéo (`vmware` pour
+  le contrôleur VMSVGA que présentent VirtualBox et VMware, `vesa` et `fbdev` en
+  secours) sont désormais nommés explicitement.
+
+  **`~/.ssh/config` n'incluait pas ce que dsoxlab y écrit.** `provision` dépose un
+  `~/.ssh/config.d/<catalogue>.conf` et avertit, à chaque exécution, que rien ne
+  le lit. L'`Include` est maintenant posé en tête du fichier, là où OpenSSH
+  l'exige.
+
+  **`start` déclarait « déjà provisionnée » une infrastructure inutilisable.**
+  Il tranchait sur le seul state, donc une adresse suffisait. L'enchaînement qui
+  suivait était absurde : `provision` sortait en 8 sur « les hôtes n'ont pas
+  répondu : l'infrastructure existe, mais elle n'est pas utilisable en l'état »,
+  et le `start` relancé juste après — donc relancé *parce que* rien ne répondait
+  — annonçait « déjà provisionné, rien à reconstruire », avant d'échouer plus
+  loin sur un `UNREACHABLE` brut d'Ansible que rien ne reliait à la cause. Il
+  sonde désormais aussi le port 22 : une adresse n'est pas une machine. Rejouer
+  `provision` ne coûte rien, puisqu'il reprend sans rien recréer, et il attend.
+
+  **La console était noyée sous des erreurs `AF_VSOCK`**, une par rechargement de
+  systemd, soit une dizaine de lignes rouges en cinq secondes pendant
+  l'installation des paquets. Rien n'était cassé, mais rien ne le disait non
+  plus. `systemd-ssh-generator` est maintenant neutralisé par un lien vers
+  `/dev/null`, la façon documentée de le faire.
+
+## [0.2.1] - 2026-09-25
+
+### Ajouté
+
+- **Une section `Remerciements` dans les deux README.** Trois personnes
+  extérieures au projet ont remonté des défauts avec le diagnostic, et souvent le
+  correctif. La section nomme **ce que chaque retour a changé** plutôt que de
+  lister des pseudonymes : quatre versions viennent de
+  [@cedric-ribier](https://github.com/cedric-ribier) (tailles de disque nominales,
+  libvirt 8, l'agent Incus sur AlmaLinux avec l'attente réglable, et la
+  virtualisation imbriquée nommée), le `conftest.py` qui bloquait en silence tous
+  les labs `shell` vient de [@Gedd18](https://github.com/Gedd18), et deux labs dont
+  l'état de départ était inutilisable de
+  [@VictorVare](https://github.com/VictorVare).
+
+  Un crédit qui dit ce qu'il a corrigé vaut mieux qu'une liste, et il apprend au
+  lecteur suivant quel genre de rapport est utile.
+
 ## [0.2.0] - 2026-09-25
 
 **Passage au produit.** Cette version n'ajoute aucun code : elle marque le

{dsoxlab-0.2.0 → dsoxlab-0.2.2}/CHANGELOG.md

@@ -9,6 +9,155 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.2.2] - 2026-09-26
+
+### Added
+
+- **The appliance: a ready-to-play VM, built by the CI** (issue #91, moved to the
+  0.3.0 milestone and now started). For Windows and macOS, where `uv tool install
+  dsoxlab` is not an option. On Linux it stays the wrong answer, and the README
+  says so: downloading half a gigabyte to avoid one command makes no sense.
+
+  `packer/` holds the recipe — `qemu` builder, automated Debian 13 install, four
+  provisioning scripts — and `.github/workflows/appliance.yml` builds it **on a
+  GitHub-hosted runner**, with no self-hosted machine: Linux runners expose
+  `/dev/kvm`, so QEMU is accelerated. That choice also removes `ovftool`
+  (proprietary) and VirtualBox from the chain: the OVA is derived from the qcow2
+  with `qemu-img` and `tar` alone.
+
+  The image **pins nothing**. The first boot installs the latest dsoxlab, and the
+  hypervisors only if the host exposes nested virtualization — checked live, never
+  assumed. Which is why it is rebuilt on **minor tags only**: republishing half a
+  gigabyte for every patch would cost a lot and change nothing.
+
+  Measured, not estimated: **461 MiB** for the qcow2 and **446 MiB** for the OVA,
+  built in 4 min 50 s, against a budget the workflow enforces at 800 MiB. A
+  comparable appliance built with `virtualbox-iso` weighs 979 MiB.
+
+- **The README now presents both ways in**, side by side: install the tool, or
+  download the appliance. It also says which one is right on Linux, rather than
+  selling them as equals.
+
+- **Only the last two sets of images are kept on the Releases.** Roughly 900 MB
+  per minor version, forever, for images that pin no dsoxlab version and
+  install the latest at first boot: an old one offers no reproducibility, only
+  weight. Two rather than one, so a broken image has a fallback. The Releases,
+  their changelog and the Python distributions are untouched.
+
+- **The OVA is offered for VMware as well as VirtualBox**, and the workflow now
+  holds it to that promise: the OVF is validated against the DMTF schema at
+  every build. VirtualBox imports almost anything, VMware checks — and without
+  a Broadcom licence, conformity to the specification is the only honest way to
+  keep the claim. The appliance page says plainly what was tested and what was
+  not, and that **Apple Silicon is out of reach**: both images are x86-64,
+  GitHub's arm64 runners expose no `/dev/kvm` to build another, and nested
+  virtualization on those Macs only exists from the M3.
+
+### Fixed
+
+- **Three defects in that recipe, each caught by a measurement rather than a
+  reading.** They are worth recording because they are the kind that ship
+  silently:
+
+  `fstrim` **returns success without freeing anything** when the build disk is
+  attached with `discard=ignore`, which is Packer's default. The guest announced
+  "520.4 MiB trimmed" while the qcow2 kept every byte: 1110 MiB of artifact
+  against 597 for the control. So the disk is now attached `unmap`, with
+  `detect_zeroes=unmap` so that zeroing costs nothing — and the never-triggered
+  `|| dd` fallback is gone, along with the 17 GiB it wrote when it did fire.
+
+  `vm_name` **had no extension**, and Packer adds none: the `*.qcow2` globs of the
+  budget check, the checksums and the upload would never have seen the file. The
+  first local build produced `dsoxlab-appliance-dev`, which proved it.
+
+  The size check tested the **2 GB hard limit**, so it would have waved through a
+  1.1 GB image the day the trim regressed. It is now a **budget of 800 MiB**, with
+  `qemu-img info` and `check` printed, and an error that says where to look.
+
+- **`lsb_release` no longer exists** once the `standard` task is dropped from the
+  preseed, and `20-outils.sh` used it for the HashiCorp repository. Read from
+  `/etc/os-release` instead — without this the build would have failed outright.
+
+- **Ten more defects, found by playing the appliance rather than reading the
+  recipe.** Each was invisible to every check that came before, and the first one
+  alone made the image useless to the very people it is built for:
+
+  **The network did not survive a change of hypervisor.** Debian's installer
+  freezes the interface name it saw at install time — `enp0s2` under the QEMU that
+  builds the image — and that name is derived from the card's PCI position. Under
+  VirtualBox the card is `enp0s17`, so the configuration applied to nothing: the
+  imported appliance came up with `enp0s17 DOWN`, a `resolv.conf` without a single
+  `nameserver`, and a first boot that failed on "Temporary failure in name
+  resolution". Nothing was installed — no dsoxlab, no hypervisors, no desktop. The
+  image now configures the network with `systemd-networkd`, whose `[Match]`
+  **describes** the card (`en*`, `eth*`) instead of naming it.
+
+  **The first boot marked itself done even when everything had failed**, so the
+  machine had no way left to catch up. It now reports what failed, keeps no
+  marker, and starts over at the next boot. It also waits for a name to actually
+  resolve before it begins: `network-online.target` was reached with no DHCP lease
+  taken, which is how the failure above got its eight-second timeout.
+
+  **Root inherited the student's `HOME`** during the build (`sudo -E`), so
+  `terraform version` and `ansible-playbook --version` created a root-owned
+  `~/.ansible` and `~/.terraform.d`. Ansible then refused to start for the learner
+  and dsoxlab reported `rc=5, Stats: {}` — a symptom nothing connected to the
+  cause. Fixed with `sudo -H`, plus a `chown` belt.
+
+  **`ovmf` and `qemu-utils` were missing**: both are mere *recommendations* of
+  `qemu-kvm` on Debian, so `--no-install-recommends` dropped them. Without the
+  first, libvirt exposes no EFI firmware and every `provision` stops dead; without
+  the second, it cannot create a qcow2 volume. Found by provisioning for real from
+  inside the appliance — and the first was named in 2.3 seconds by the guard added
+  for issue #234.
+
+  **No libvirt `default` pool and no group membership**: a fresh Debian defines
+  neither, so `doctor --strict` exited 9 and `student` could not open `/dev/kvm`.
+  Both are now set up at first boot, which is also why it reboots at the end.
+
+  **The desktop had no X server.** Same pattern as `ovmf` and `qemu-utils`, for
+  the third time: `xserver-xorg` is a *recommendation* of `xfce4` and `lightdm`,
+  never a dependency, so `--no-install-recommends` dropped it. `/usr/bin/Xorg`
+  did not exist, `lightdm` was `failed`, and the machine came up on a console
+  despite `graphical.target` — with nothing tying that to a missing package. The
+  server and its video drivers (`vmware` for the VMSVGA controller VirtualBox and
+  VMware present, `vesa` and `fbdev` as fallbacks) are now named explicitly.
+
+  **`~/.ssh/config` did not include what dsoxlab writes.** `provision` drops a
+  `~/.ssh/config.d/<catalog>.conf` and warns, at every run, that nothing reads it.
+  The `Include` is now placed at the top of the file, where OpenSSH requires it.
+
+  **`start` called an unusable infrastructure "already provisioned".** It
+  decided from the state alone, so an address was enough. The sequence that
+  followed was absurd: `provision` exited 8 on "some hosts did not answer: the
+  infrastructure exists, but it is not usable as it stands", and the `start`
+  relaunched right after — relaunched *because* nothing answered — announced
+  "already provisioned, nothing to build again", then failed further down on a
+  raw Ansible `UNREACHABLE` that nothing tied to the cause. It now probes port
+  22 as well: an address is not a machine. Replaying `provision` costs nothing,
+  since it resumes without recreating anything, and it waits.
+
+  **The console was flooded with `AF_VSOCK` errors**, one per systemd reload, so
+  a dozen red lines in five seconds while packages installed. Nothing was broken,
+  but nothing said so either. `systemd-ssh-generator` is now masked, the
+  documented way, with a symlink to `/dev/null`.
+
+## [0.2.1] - 2026-09-25
+
+### Added
+
+- **A `Thanks` section in both READMEs.** Three people outside the project have
+  reported defects with the diagnosis, and often the fix. The section names **what
+  each report changed** rather than listing handles: four releases come from
+  [@cedric-ribier](https://github.com/cedric-ribier) (nominal disk sizes, libvirt 8,
+  the Incus agent on AlmaLinux with a configurable host wait, and nested
+  virtualization named), the `conftest.py` that silently blocked every `shell` lab
+  from [@Gedd18](https://github.com/Gedd18), and two labs whose starting state was
+  unusable from [@VictorVare](https://github.com/VictorVare).
+
+  A credit that says what it fixed is worth more than a list, and it tells the next
+  reader what kind of report is useful.
+
 ## [0.2.0] - 2026-09-25
 
 **Productization.** This version adds no code: it marks a milestone, and its