Alertes smartd NVMe sur YunoHost / Debian Bookworm : Error Log entries increased avec SSD sain, recommandation officielle?

[lelabtv]

What type of hardware are you using: Old laptop or computer
What YunoHost version are you running: 12.1.39
How are you able to access your server: The webadmin
SSH
Are you in a special context or did you perform specific tweaking on your YunoHost instance ?: non

Describe your issue

Bonjour,

Je rencontre des alertes répétées de smartd sur un serveur YunoHost basé sur Debian Bookworm.

J’ai cherché sur le forum et trouvé un sujet proche autour d’un NVMe potentiellement défaillant, mais mon cas semble un peu différent : les indicateurs critiques du SSD sont bons, et l’alerte semble liée au compteur NVMe Error Information Log Entries.

Le serveur est à jour : sudo yunohost tools update
Résultat : aucun paquet à mettre à jour.

Version de smartmontools : apt policy smartmontools
Résultat : smartmontools:
Installé : 7.3-1+b1
Candidat : 7.3-1+b1

Le mail reçu par smartd est le suivant :
SMART error (ErrorCount) detected on host: lab

Device: /dev/nvme0, number of Error Log entries increased from 114 to 116

Device info:
OM3PDP3-AD NVMe KDI 512GB, S/N:50026B72831379B4, FW:10100002, 512 GB

État SMART du SSD :
SMART overall-health self-assessment test result: PASSED
Critical Warning: 0x00
Temperature: 32 Celsius
Available Spare: 100%
Available Spare Threshold: 50%
Percentage Used: 0%
Data Units Written: 715785 [366 GB]
Power On Hours: 7
Unsafe Shutdowns: 30
Media and Data Integrity Errors: 0
Error Information Log Entries: 116

Journal d’erreur NVMe : sudo smartctl -l error /dev/nvme0
Résultat : Error Information (NVMe Log 0x01, 16 of 16 entries)
Num ErrCount SQId CmdId Status PELoc LBA NSID VS
0 116 0 0x4019 0x4005 0x028 0 0 -

À première vue, le SSD semble sain : PASSED, Critical Warning: 0x00, Available Spare: 100%, Percentage Used: 0%, Media and Data Integrity Errors: 0.

J’ai aussi vu le bug Debian #1041745, qui semble correspondre au message :
Device: /dev/nvme0, number of Error Log entries increased

Ce bug est indiqué comme trouvé dans smartmontools 7.3-1 et corrigé dans smartmontools 7.4-1.

Je sais aussi que YunoHost déconseille l’usage des backports, donc je préfère éviter d’activer bookworm-backports ou d’installer smartmontools 7.4 sans avis.

Quelle serait la recommandation propre côté YunoHost ?

Considérer cette alerte comme non critique tant que les indicateurs SMART critiques restent bons ?
Modifier /etc/smartd.conf pour surveiller explicitement /dev/nvme0 avec les indicateurs importants, mais sans surveiller l’augmentation du NVMe Error Log ?
Éviter toute modification et attendre une éventuelle mise à jour Debian/YunoHost ?
Installer smartmontools 7.4 depuis backports de manière ciblée est-il acceptable sur YunoHost, ou déconseillé ?
YunoHost pourrait-il documenter ce cas, car l’alerte est assez anxiogène alors que le SSD semble sain ?

Je cherche surtout à éviter deux erreurs :

masquer une vraie panne SSD ;
recevoir des alertes quotidiennes pour un compteur qui semble augmenter à cause d’une commande NVMe invalide ou non supportée.

Merci pour vos avis.

Share relevant logs or error messages

SMART error (ErrorCount) detected on host: lab

Device: /dev/nvme0, number of Error Log entries increased from 114 to 116

Device info:
OM3PDP3-AD NVMe KDI 512GB, S/N:50026B72831379B4, FW:10100002, 512 GB

Error Information (NVMe Log 0x01, 16 of 16 entries)
Num ErrCount SQId CmdId Status PELoc LBA NSID VS
0 116 0 0x4019 0x4005 0x028 0 0 -

[MariusBaguepi]

Ce problème semble récurrent. Il y a un bug de remonté au niveau du noyau linux…

217445 – standby-resume cycle increases NVMe error count (maybe bad NVMe...

Dans l’idée, si la commande suivante te renvoie systématiquement la valeur invalid field in command, c’est juste que le driver lance une commande “optionnelle” sur le disque. Et le driver n’a aucun moyen de savoir si le disque sait ou non interpréter cette commande.

nvme error-log /dev/nvme0

[lelabtv]

Merci beaucoup pour la piste, elle semble effectivement correspondre à mon cas.

J’ai vérifié l’état SMART du NVMe : les indicateurs critiques sont bons (PASSED, Critical Warning: 0x00, Available Spare: 100%, Percentage Used: 0%, Media and Data Integrity Errors: 0). Le seul élément qui remontait était l’augmentation du compteur Error Information Log Entries, ce qui déclenchait les alertes smartd du type :

number of Error Log entries increased

Au vu du bug que tu as partagé, j’ai finalement choisi une solution prudente : ne pas désactiver SMART, ne pas installer smartmontools depuis les backports, mais modifier /etc/smartd.conf pour surveiller explicitement le NVMe sans surveiller l’augmentation du journal d’erreurs NVMe.

J’ai donc remplacé le DEVICESCAN générique par une ligne explicite du type :
/dev/nvme0 -d nvme -n standby -H -l selftest -W 4,45,60 -m root -M exec /usr/share/smartmontools/smartd-runner

L’idée est de conserver les alertes importantes : état SMART global, selftests, température, etc., mais d’éviter les courriels anxiogènes liés uniquement à -l error, puisque ce compteur semble pouvoir augmenter à cause d’une commande NVMe optionnelle/non supportée plutôt qu’à cause d’une vraie panne matérielle.

Après modification, j’ai redémarré smartd :

/dev/nvme0 -d nvme -n standby -H -l selftest -W 4,45,60 -m root -M exec /usr/share/smartmontools/smartd-runner

Puis vérifié que le service surveille toujours bien le NVMe et que la configuration est acceptée.

Donc pour laisser une trace : dans mon cas, le SSD semble sain, et j’ai choisi de ne pas masquer toute la surveillance SMART, mais seulement de ne plus alerter sur ce compteur NVMe précis. Je vais continuer à surveiller les vrais indicateurs critiques du disque.

[MariusBaguepi]

N’hésites pas à vérifier que les erreurs remontées correspondent bien au problème de commande non implémentée.

nvme error-log /dev/nvme0

[lelabtv]

Merci pour la piste, je viens de vérifier avec :

sudo nvme error-log /dev/nvme0

Et ça semble bien confirmer ton hypothèse. L’entrée active du journal NVMe indique :

status_field : 0x2002(Invalid Field in Command: A reserved coded value or an unsupported value in a defined field)

Donc, dans mon cas, l’erreur remontée ne semble pas correspondre à une panne matérielle du SSD, mais plutôt à une commande NVMe non supportée ou à un champ non interprété par le disque.

Les autres indicateurs SMART restent bons : pas de Critical Warning, pas de Media and Data Integrity Errors, spare à 100 %, disque indiqué comme PASSED.

J’ai donc choisi une solution prudente : ne pas désactiver SMART, ne pas passer par les backports, mais modifier /etc/smartd.conf pour surveiller explicitement le NVMe sans surveiller l’augmentation du journal d’erreurs NVMe.

J’ai remplacé le DEVICESCAN générique par :

/dev/nvme0 -d nvme -n standby -H -l selftest -W 4,45,60 -m root -M exec /usr/share/smartmontools/smartd-runner

Depuis, smartd surveille toujours bien le disque, mais je n’ai plus les alertes anxiogènes liées uniquement à l’augmentation de Error Log entries.

Merci encore, ta piste a permis de confirmer que le problème venait probablement bien de cette commande non supportée plutôt que d’une défaillance du SSD.