diff --git a/hosts/overmind.md b/hosts/overmind.md
index f5613ac..69b901f 100644
--- a/hosts/overmind.md
+++ b/hosts/overmind.md
@@ -76,9 +76,26 @@ vorhanden, Runbook referenziert `stable`.
 zurückgestellt, bis kein Auto-Job das alte Image parallel referenziert (Reihenfolge:
 erst neues Image bauen, dann Referenz umstellen).
 
-## OVERMIND-02 — Host-Ausfall 2026-07-31 ~19:15 lokal (Ursache ungeklärt)
+## OVERMIND-02 — Host-Ausfall 2026-07-31 ~19:15 lokal (NIC-Hang, Fix aktiv)
 
-**Status:** offen
+**Status:** Fix aktiv, Beobachtung
+
+**Ursache (Journal des Vor-Boots, via Claude-Session auf Overmind):** `e1000e`
+`Detected Hardware Unit Hang` auf `eno1` in Endlosschleife — die Intel-NIC hing
+(bekanntes e1000e-Problem in Kombination mit EEE/Energiesparen), der Host lief weiter,
+war aber netzwerktot. Kein OOM, kein Bezug zur Windows-VM/CI. Passt zu allen Symptomen:
+Ping tot, aber der Windows-Runner erreichte GitLab host-intern noch (Job 413 wurde
+aufgegriffen) und scheiterte erst an der DNS-Auflösung übers tote Interface.
+
+**Fix (2026-07-31, Overmind-Session):** `ethtool --set-eee eno1 eee off` live gesetzt
++ persistente udev-Regel `/etc/udev/rules.d/71-disable-eee-eno1.rules` (greift bei
+jedem Boot). Temporäre sudoers-Freigabe danach wieder entfernt.
+
+**Offen:**
+- NIC-/BIOS-Firmware-Update 2.4.0.0 → 2.5.2.0 — ins nächste geplante Wartungsfenster
+  (physisch am Gerät), nicht ad hoc
+- Falls Hang trotz EEE-off wiederkehrt: gezielter ASPM-Fix statt globalem
+  Kernel-Parameter
 
 **Zeitleiste (lokal, UTC+2):**
 - 18:58 — Windows-VM nach händischem Container-Stop+Start zurück, Runner online
@@ -99,13 +116,8 @@ geholt, die VM lief nur idle (frisch provisioniert; denkbare Gast-Hintergrundlas
 Windows Update/Defender nach den choco-Installs). Die 8-G-Zuteilung der VM plus
 GitLab-Stack blieb aber auch nach dem Puma-Fix ein enges Budget auf 30 Gi.
 
-**Nächste Schritte:**
-1. (sorb) Absturzspuren des letzten Boots sichern:
-   `journalctl -b -1 -p err --no-pager | tail -50` und
-   `journalctl -b -1 --no-pager | grep -iE 'oom|out of memory|panic|hung task' | tail -20`
-2. Ursache hier nachtragen; je nach Befund VM-`RAM_SIZE` auf 6G senken oder
-   Build-Fenster ohne Parallellast definieren
-3. Erst danach Versuch 7 der Windows-Build-Kette (ThreadNet-Web#5)
+**Konsequenz für die Build-Kette:** RAM-Budget war nicht das Problem — VM bleibt bei
+8G, Versuch 7 der Windows-Build-Kette (ThreadNet-Web#5) direkt nach VM-Neustart.
 
 ---