rpa_vision_v3/docs/DESIGN_OVMF_AUTOREPAIR_VM_2026-06-20.md

Design — Auto-réparation OVMF de la VM Léa (gap G2, reprise non-assistée)

• Auteur: Claude (infra)
• Date: 2026-06-20 ~03:15 CEST
• Statut: PROPOSITION / design read-only — à appliquer après revue Dom (garde-fou : aucun changement service prod sans Dom).
• Référence: post-mortem docs/POSTMORTEM_PANNE_SECTEUR_DGX_2026-06-20.md (gap G2).

1. Problème

Une coupure brutale corrompt OVMF_VARS.fd (NVRAM UEFI) → la VM boucle dans TianoCore/Windows Boot Manager. Le 2026-06-20, blocage 02:07→02:18 jusqu'à intervention manuelle de Codex (restore OVMF connu-bon + TPM frais). En clinique sans technicien, ce blocage serait permanent.

2. Pourquoi le service ne s'auto-répare pas aujourd'hui

~/.config/systemd/user/win11-arm-lea.service :

• Restart=on-failure — inopérant : en boucle TianoCore, QEMU ne sort pas (process « running » à 99 % CPU). Aucun échec → aucun restart.
• ExecStartPre efface tpm2-00.permall (TPM frais à chaque boot) mais pas OVMF_VARS.fd → un OVMF corrompu survit aux restarts → boucle permanente.

3. Détecteur fiable

Le guest agent QEMU (windows-11-arm-lea-agent.sock) ne répond que si Windows a réellement booté. En boucle firmware, il ne répond jamais. Signature d'échec = pas de réponse guest-agent après N min + CPU QEMU élevé. (Plus robuste qu'une analyse framebuffer ; v1 suffisante.)

4. Design proposé (2 briques + garde-fous)

Brique A — Snapshot « known-good » après boot sain

Watchdog compagnon (lancé en ExecStartPost=... & ou service apparié vm-health-watchdog.service) :

1. Fenêtre de boot (0→~6 min), poll guest-agent toutes les 30 s (guest-ping via socket agent).
2. Guest-agent répond → boot sain : copie atomique OVMF_VARS.fd → OVMF_VARS.fd.known-good, écrit sentinel boot-ok, log horodaté. C'est le point de restauration.

Brique B — Détection boucle + restauration auto

Si à T+6 min le guest-agent ne répond toujours pas ET CPU QEMU > 80 % (signature boucle) :

1. Écrit sentinel boot-failed.
2. Archive l'OVMF suspect : OVMF_VARS.fd → OVMF_VARS.fd.failed-<ts> (convention déjà utilisée par Codex).
3. Restaure OVMF_VARS.fd.known-good → OVMF_VARS.fd.
4. Arrête le QEMU en boucle firmware. Sûr : aucun OS n'a booté (guest-agent jamais monté) → pas de risque de corruption Windows (≠ règle « jamais kill un Windows booté », qui ne s'applique pas ici).
5. systemd relance (Restart=on-failure se déclenche enfin) avec le bon OVMF.

Garde-fous (anti-mauvais comportement)

• Pas de known-good (1er boot, jamais eu de boot sain) → ne PAS restaurer ; log + alerte, comportement actuel conservé.
• Compteur d'essais : max 2 auto-restaurations consécutives (sentinel compteur). Au-delà → stop + alerte (évite la boucle restore→échec→restore si le known-good est lui aussi mauvais).
• Faux positifs : Windows peut booter lentement → fenêtre 6–8 min + double critère (guest-agent ET CPU). Réglable.
• TPM : on garde l'effacement tpm2-00.permall existant (évite le hang TPM) ; l'auto-réparation OVMF est complémentaire.
• Idempotence : nettoyage des sentinels en début de cycle.

5. Points d'intégration (à valider Dom avant écriture)

• win11-arm-lea.service : ajouter ExecStartPre de garde (si boot-failed + known-good → restaurer avant lancement) et ExecStartPost qui lance le watchdog.
• Nouveau script vm-health-watchdog.sh (briques A+B) dans ~/quickemu-win11-arm-lea/.
• Optionnel : vm-health-watchdog.service (PartOf=win11-arm-lea.service) plutôt qu'un &, pour un cycle de vie propre.

6. Plan de test (sans risque, sur la VM labo)

1. Boot sain → vérifier création OVMF_VARS.fd.known-good + sentinel boot-ok.
2. Simuler corruption (copier l'OVMF_VARS.fd.failed-powercut-20260620-021854 archivé sur le live) → vérifier détection à T+6 min, archivage, restauration, restart, boot sain.
3. Vérifier le compteur d'essais (corrompre aussi le known-good) → stop + alerte, pas de boucle infinie.
4. Mesurer le temps total de reprise auto (cible < 10 min sans intervention).

7. Décision attendue (Dom)

GO/NO-GO sur l'écriture + le réglage de la fenêtre (6 vs 8 min) et du mécanisme d'alerte (log seul ? message coordination ? mail ?). Application supervisée, un changement / un test, après ton réveil.