Dom/rpa_vision_v3
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
6907ecc82f3953aefd98fffe591e4ef257c9df72
rpa_vision_v3/docs/POSTMORTEM_PANNE_SECTEUR_DGX_2026-06-20.md
Dom 6907ecc82f docs: track design docs, plans, audits, coordination infrastructure, handoffs 
- 21 docs/*.md: audits, design notes, deployment plans, checklists, memos
- Coordination: ROLES, runbooks (DGX reboot, Lea live), patches, registre, syntheses, systemd, QG template
- Handoffs: 6 Codex handoff documents + README + template
2026-07-02 13:29:58 +02:00

5.4 KiB
Raw Blame History

Post-mortem — Panne secteur DGX 2026-06-20 (test reboot non planifié)

  • Auteur: Claude (infra)
  • Date: 2026-06-20 ~03:00 CEST
  • Scope: La coupure électrique réelle de 02:07 traitée comme exécution non planifiée du test de stabilité reboot (CHECKLIST_DGX_PRE_CLINIQUE.md §6). Objectif : mesurer ce qui se rétablit seul vs ce qui exige une intervention — c'est le critère clé pour une clinique sans personnel technique sur place.
  • Méthode: diagnostic read-only multi-agents (Claude infra, Qwen appli/guest, Codex consolidation). Aucun reset Git, aucun changement réseau hors IP statique arbitrée par Dom.

1. Timeline

Heure Événement
02:07 Coupure secteur. DGX reboot. Poste Dom (Linux) reboot. Laptop Windows .11 (sur batterie) jamais coupé.
02:07:42 win11-arm-lea.service (user) auto-démarre la VM.
~02:09 Watcher coordination (systemd user) revenu seul. Services rpa système remontés.
02:07→02:18 VM bloquée en boucle TianoCore (QEMU 99% CPU, guest agent/SSH absents).
02:18 Codex diagnostique : OVMF_VARS.fd corrompu par coupure brutale.
02:21 Codex restaure OVMF connu-bon (18/06) + TPM frais → VM boot prouvé (écran verrouillage Windows).
~02:28 Claude : DGX revenu en DHCP sur .46 (au lieu de .45) → IP statique .45 appliquée (décision Dom).
~02:35 Accès VM Dom rétabli (tunnel + VNC, mot de passe OK).
~02:55 Crash-loop dashboard-user éteint (Qwen). Revue infra/appli consolidée.

2. Ce qui s'est rétabli SEUL (✅ socle solide)

Domaine Constat Réf checklist
Boot DGX + services rpa Tous active+enabled (dashboard, streaming, agent-chat, vwb back/front, api, worker, stream-worker, vllm-grounder, firewall) §1 PASS
Firewall Réappliqué : 5900/5902/3389/22220/8000/11434 filtrés LAN, seuls 5001/5002/5004/5005 ouverts §2 PASS (fort)
Auth Dashboard 401, VWB 401 (basic auth), streaming Bearer §3 majoritaire PASS
Auto-start VM win11-arm-lea.service a bien démarré la VM (linger=yes) §4.1 — prouvé (était « à implémenter »)
Coordination Watcher couche-1 (systemd user) revenu seul —

→ Le socle infra/services/sécurité survit à une coupure brutale sans intervention.

3. Ce qui a EXIGÉ une intervention (⚠️ gaps reprise non-assistée)

# Problème Cause Correctif (qui) Risque clinique
G1 DGX IP a dérivé .45→.46 bail DHCP après reboot IP statique .45 (Claude/Dom) Élevé — casse tous clients/tunnels pointant .45. DHCP non fiable.
G2 VM bloquée TianoCore OVMF_VARS.fd corrompu (coupure brutale) restore OVMF connu-bon + TPM frais (Codex) Élevé — sans agent, VM morte jusqu'à intervention manuelle.
G3 dashboard-user crash-loop (244 restarts) fallback user clash port 5001 (service système le sert déjà) stop + mask session (Qwen) Moyen — bruit/ressources ; disabled mais relancé.
G4 Léa guest non reconnectée config.txt = CONFIGURE_ME + login Windows requis à renseigner .45+token (Qwen) Élevé — VM redémarre mais Léa ne reprend pas le travail seule.
G5 Mot de passe VNC -vnc password=on sans set_password dans les scripts rétabli de fait (tunnel) Faible/Moyen — fragile si relaunch sans repose mdp.

4. Recommandations de durcissement — reprise CLINIQUE non-assistée

Toutes modifiantes → à valider par Dom (mises en file, non appliquées cette nuit).

  1. BIOS DGX = « Power On » au retour AC (physique, Dom) — sinon une coupure laisse le DGX éteint.
  2. IP statique : fait au labo (.45) ; cible clinique = Ethernet statique .178 (DHCP = point faible démontré par G1).
  3. Auto-réparation OVMF dans win11-arm-lea.service : au boot Windows réussi, snapshot OVMF_VARS.fd sain ; ExecStartPre : si boucle TianoCore détectée (CPU 99% + guest agent absent N s), restaurer le snapshot sain automatiquement. → neutralise G2 sans agent.
  4. rpa-vision-v3-dashboard-user : mask persistant (pas seulement session) — G3.
  5. Léa reprise auto (G4) : config.txt persistant vers IP DGX + token ; auto-login Windows + Léa auto-start (pythonw) + reconnexion fleet sans geste humain.
  6. Mot de passe VNC (G5) : poser le mot de passe au lancement via le monitor (script), ou documenter la procédure de repose.

5. Propositions de MAJ pour CHECKLIST_DGX_PRE_CLINIQUE.md (Qwen, propriétaire)

  • §4.1 « auto-start VM » : passer À IMPLÉMENTER → VALIDÉ (prouvé par la panne, 02:07:42).
  • §1.10 / Items à fixer #1 : dashboard service système actif confirmé ; le fallback user est l'orphelin → masquer.
  • §6 « Test reboot » : exécuté en réel le 2026-06-20 → renseigner les résultats (col. Résultat) à partir des sections 2 et 3 ci-dessus.
  • Ajouter une ligne G1 dérive IP DHCP et G2 corruption OVMF comme items de durcissement explicites.

6. Verdict test

Le socle technique tient (services, firewall, auth, auto-start VM). Les deux points durs pour une clinique sans technicien sur place sont G1 (dérive IP DHCP) et G2 (corruption OVMF VM non auto-réparée) : tous deux ont nécessité un agent cette nuit. La cible clinique doit les automatiser (IP statique Ethernet + auto-réparation OVMF). G4 (Léa ne reprend pas seule) est le troisième chantier reprise.

Reference in New Issue View Git Blame Copy Permalink