Funk-lab/admin/incidents.md

Incidents — Historique et résolutions

---

2026-05-13 — storage-01 : corruption EXT4 après arrêt brutal + reinstall hermes-agent

Symptômes

• hermes-agent en boucle de crash : SyntaxError: source code string cannot contain null bytes
• Erreurs EXT4 au démarrage des services : Directory block failed checksum, deleted inode referenced
• dmesg : EXT4-fs (md0): error count since last fsck: 655
• sdb : erreurs ATA bus (SError: { RecovComm HostInt PHYRdyChg PHYInt }) et I/O error sector 13405184

Cause racine

Arrêt brutal du cluster la veille (funk-stop --k8s) → journal ext4 non rejoué correctement → 655 erreurs de corruption sur /dev/md0. sdb avait des erreurs transitoires mais SMART PASSED (pas de défaillance matérielle).

Résolution étape par étape

1. Vérifier SMART sdb

smartctl -H /dev/sdb
# SMART overall-health self-assessment test result: PASSED → purement logiciel

2. Arrêter les services et démonter

sudo systemctl stop hermes-agent litellm qdrant postgresql-16 nfs-server
sudo umount /srv/data

3. Réparer le filesystem

sudo e2fsck -f -y /dev/md0
# 655 erreurs corrigées : HTREE invalides, blocs multiplement revendiqués,
# checksums de répertoires incorrects, compteurs d'inodes wronge

4. Remonter et redémarrer les services

sudo mount /srv/data
sudo systemctl start postgresql-16 qdrant litellm hermes-agent nfs-server

5. Hermes-agent toujours en erreur après fsck

Le e2fsck a zéroïsé des blocs appartenant à plusieurs inodes simultanément → des fichiers du venv Python et du code source hermes_cli/ ont été corrompus (null bytes).

Tentatives de réparation du venv échouées (pip install -e . crash, uv.lock corrompu).

6. Réinstallation complète de hermes-agent

# Supprimer le code source corrompu (les profils dans /srv/data/hermes/profiles/ ne sont PAS touchés)
sudo rm -rf /srv/data/hermes/hermes-agent
sudo rm /opt/hermes/.local/bin/hermes

# Réinstaller depuis le script officiel (depuis un répertoire valide)
cd /srv/data/hermes
sudo -u hermes bash -c 'cd /srv/data/hermes && HOME=/opt/hermes HERMES_HOME=/srv/data/hermes curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash'

Lors du sudo rm -rf, ne pas rester dans le répertoire supprimé — le shell perd le CWD et le script d'installation échoue avec getcwd: cannot access parent directories.

Résultat : hermes-agent réinstallé dans /opt/hermes/.hermes/hermes-agent/ (SSD OS, plus de RAID5). Tous les profils (funk-ai, brain, system, monitor) intacts dans /srv/data/hermes/profiles/.

Changement d'architecture post-incident

Avant	Après
Code hermes-agent : /srv/data/hermes/hermes-agent/ (RAID5)	Code hermes-agent : /opt/hermes/.hermes/hermes-agent/ (SSD OS)
Venv : /srv/data/hermes/hermes-agent/venv/	Venv : /opt/hermes/.hermes/hermes-agent/venv/
Profils/données : /srv/data/hermes/	Profils/données : /srv/data/hermes/ (inchangé)

Le code étant désormais sur le SSD, une corruption future du RAID5 n'impactera plus l'installation — seulement les profils et données.

Surveillance post-incident

# Santé RAID et disques
cat /proc/mdstat
smartctl -H /dev/sdb    # à surveiller

# Vérifier que e2fsck n'a pas schedulé un check au prochain boot
sudo tune2fs -l /dev/md0 | grep -E "check|count|error"

---

2026-05-11 — storage-01 : boucle fsck après coupure de courant

Symptômes

• Boucle infinie de fsck au démarrage sur /dev/md0
• You are in emergency mode. Give root password for maintenance — mot de passe impossible à saisir (messages défilants)
• Après résolution : hermes-agent en boucle d'erreurs (cause : /srv/data non monté)

Architecture concernée

Composant	Détail
Disque système	NVMe nvme0n1 — LVM (almalinux-root XFS 70G, swap 14.7G, home 845G)
RAID données	RAID5 software md0 — 4 disques SATA 931.5G (sda1, sdb2, sdc1, sdd1)
Point de montage	/srv/data (ext4)

Cause racine

La coupure de courant a corrompu le système de fichiers XFS sur almalinux-root. Au redémarrage, systemd tentait de vérifier /srv/data avant que le RAID md0 soit assemblé → boucle bloquante.

Résolution étape par étape

1. Shell de secours via GRUB

Au démarrage, appuyer sur Shift pour afficher le menu GRUB. Appuyer sur e pour éditer la ligne linux :

• Remplacer ro par rw
• Ajouter init=/bin/bash en fin de ligne

Démarrer avec Ctrl+X.

2. Activer le LVM

lvm vgchange -ay
# 3 logical volume(s) in volume group "almalinux" now active

3. Réparer le XFS (pas fsck)

XFS nécessite xfs_repair, pas fsck :

umount /dev/mapper/almalinux-root
xfs_repair /dev/mapper/almalinux-root
# Phases 1 à 7 — succès

4. Désactiver temporairement /srv/data dans fstab

vi /etc/fstab
# Commenter la ligne /srv/data pour permettre le boot sans RAID

5. Reboot → système normal, RAID intact [4/4] [UUUU].

Fix permanent — fstab

Modifier la ligne /srv/data dans /etc/fstab :

# Avant
UUID=3add8360-fa01-47eb-0aa1-0e84bacbbc15 /srv/data ext4 defaults,noatime,nodiratime 0 2

# Après
UUID=3add8360-fa01-47eb-0aa1-0e84bacbbc15 /srv/data ext4 defaults,noatime,nodiratime,_netdev 0 0

Changement	Effet
0 2 → 0 0	Désactive la vérification fsck automatique au boot
_netdev	Force systemd à attendre que tous les périphériques (RAID) soient prêts avant de monter

Surveillance post-incident

# État du RAID
cat /proc/mdstat

# Santé des disques (sdb a généré des erreurs I/O — à surveiller)
smartctl -a /dev/sda
smartctl -a /dev/sdb
smartctl -a /dev/sdc
smartctl -a /dev/sdd

# Monter /srv/data manuellement si besoin
mount /srv/data

# Logs de boot
journalctl -xb | grep -i "error\|fail"

Points d'attention

• sdb a généré des erreurs I/O pendant l'incident — il est revenu opérationnel mais doit être surveillé régulièrement avec smartctl.
• Envisager un onduleur (UPS) pour prévenir ce type d'incident sur coupure de courant.
• Le fix fstab (_netdev, 0 0) est permanent — ne pas revenir aux valeurs précédentes.