Résumé en français. Le récit complet, beaucoup plus détaillé, est disponible en anglais.
Sur mon NAS quatre baies, un disque de remplacement s’est mal inséré: une brève chute de capacité pendant l’insertion a fait échouer la seule tentative de reconstruction automatique du firmware. Résultat: le tableau RAID 5 restait dégradé ([4/3]), et même après une reconstruction manuelle réussie, chaque redémarrage faisait retomber le disque hors du tableau.
Avec Claude Code, j’ai désassemblé les binaires propriétaires du firmware pour comprendre pourquoi. La vraie cause était une boucle: au moment d’éteindre le NAS, une routine expulsait explicitement tout disque absent d’un registre de volume (corrompant son superblock RAID), donc le démarrage suivant l’excluait légitimement, donc les registres se régénéraient comme “trois disques”, et ainsi de suite indéfiniment. Plusieurs pistes plausibles se sont révélées être des impasses, dont l’édition de champs de configuration que le code ne lit jamais, avant qu’un traçage rigoureux, vérifié instruction par instruction, ne révèle le vrai mécanisme.
Le correctif final tenait en une seule ligne: ajouter le disque manquant à la liste used_device du registre de volume, ce qui arrêtait l’expulsion au moment de l’arrêt. Une fois le tableau capable de survivre à un arrêt propre, les registres se sont remis en cohérence d’eux-mêmes, et chaque redémarrage depuis est revenu complet ([UUUU]), sans intervention manuelle.
La leçon principale: une valeur qui correspond au symptôme n’est pas nécessairement celle qui le cause, et sur un binaire sans code source, un “flux de données plausible” n’est qu’une hypothèse tant qu’il n’est pas vérifié par un vrai test.