mirror of https://github.com/Alkatrazz24/Funk-lab.git synced 2026-07-08 21:54:42 +02:00

alkatrazz dca71144d6 docs(admin): add ops documentation and fix hermes dashboard service

- Remove admin/ from .gitignore (repo is now private)
- Add --tui flag to hermes-dashboard.service template
- Document hermes-tui wrapper, dashboard access, TUI usage

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

2026-05-12 18:50:43 +02:00

2.9 KiB

Raw Blame History

Incidents — Historique et résolutions

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.

2.9 KiB Raw Blame History