Homelab Rebuild 2026 : wait and see – un serveur planté, un bulletin sans issue et mon nouveau suspect n° 1

🌐 Aussi en: English · Deutsch · Español

🚨 Rien ne vous réveille aussi sûrement qu’un e-mail de l’iLO à 20 h 30 vous annonçant qu’un serveur vient de tomber. Cet article raconte comment j’ai suivi ce plantage jusqu’au fond du terrier du lapin blanc – d’une entrée inquiétante dans le journal matériel à un véritable bulletin HPE qui s’est révélé être une impasse, jusqu’à mon principal suspect actuel : un démon de gestion obsolète qui discute discrètement avec exactement la puce qui a lâché.

Table of Contents

📧 L’e-mail

L’iLO ne fait pas dans la nuance. L’objet indiquait « CRITICAL » et le corps contenait deux entrées consécutives de l’Integrated Management Log, horodatées à la même seconde :

EVENT: Uncorrectable PCI Express Error Detected. [UNKNOWN] 0
(Segment 0x0, Bus 0x1, Device 0x0, Function 0x2).
Uncorrectable Error Status: 0x14000
ACTION: Update the firmware of the failing device. If the issue persists, replace the device.

EVENT: Unrecoverable I/O Error has occurred. System Firmware will log
additional details in a separate IML message entry if possible.

Traduction pour ceux qui n’ont jamais contemplé de codes PCIe Advanced Error Reporting : quelque chose sur le bus PCI Express a levé une erreur si grave que le matériel lui-même n’a pas pu la corriger, et la machine a tout simplement… cessé de répondre. L’un de mes trois nœuds Proxmox s’était discrètement étalé de tout son long pendant la nuit. 💀

🔍 Trouver la vraie puce

« Bus 1, Device 0, Function 2 » ne veut pas dire grand-chose en soi, alors plutôt que de deviner, je suis allé directement consulter l’inventaire matériel du serveur via l’API Redfish de l’iLO. Chaque périphérique PCI intégré de cette machine indique son adresse Bus/Device/Function exacte :

BCM 5720 NIC port 1    -> Bus 2, Dev 0, Func 0
BCM 5720 NIC port 2    -> Bus 2, Dev 0, Func 1
Embedded SATA Ctrl     -> Bus 0, Dev 23, Func 0
Embedded Video Ctrl    -> Bus 1, Dev 0, Func 1   <-- same Bus+Device as the fault

La fonction 2 à cette adresse n’apparaît pas séparément, mais elle se trouve juste à côté du contrôleur vidéo intégré – qui, sur cette génération de ProLiant, est en réalité implémenté dans la puce iLO 5 elle-même, et non dans un GPU distinct. Le périphérique défaillant est donc une fonction du silicium de l’iLO qui dialogue avec l’hôte en PCIe. Pas « l’iLO est mort » (après tout, il m’envoyait joyeusement des e-mails au sujet de son propre journal de plantage) – plutôt un mauvais moment passé par la liaison PCIe interne entre l’iLO et le reste du système. 🧩

📋 Le bulletin HPE qui collait parfaitement (presque)

Une rapide recherche m’a fait tomber sur un bulletin HPE qui n’aurait pas pu mieux correspondre si je l’avais écrit moi-même : « HPE ProLiant DL20/ML30 Gen10 Plus and ProLiant MicroServer Gen10 Plus v2 – Server May Experience ‘Uncorrectable PCI Express Error Detected’ Events. » Même famille de serveurs, même code d’erreur (0x14000), même adresse PCI. Le bulletin décrit un bug documenté du firmware System ROM (BIOS) et indique comme correctif une mise à jour de la ROM. Affaire classée, non ? 🎉 Sauf que : j’ai vérifié. Le BIOS, l’iLO et le firmware du contrôleur vidéo intégré étaient déjà tous dans les dernières versions publiquement disponibles. Le correctif « il suffit de mettre à jour le firmware » ne s’applique pas ici – je l’ai déjà, ou du moins ce que HPE publie actuellement comme dernière version. Donc soit cet erratum précis n’est pas entièrement corrigé par le firmware actuel, soit il se passe tout autre chose. Un rapport de bug qui correspond trait pour trait mais ne règle rien quand on suit ses propres conseils, c’est une forme de frustration bien particulière. 🤷

🕵️ Entrée en scène d’amsd – mon principal suspect actuel

C’est là que ça devient intéressant. HPE fournit un démon en espace utilisateur appelé AMS (Agentless Management Service, amsd), qui tourne sur l’OS hôte et renvoie à l’iLO la télémétrie matérielle – vitesse des ventilateurs, températures, données de santé. Point crucial : il le fait via un canal interne qui emprunte la même liaison PCIe intégrée que la puce qui venait de défaillir. Il s’avère que cette machine faisait tourner amsd 3.6.0, un build explicitement compilé pour Debian 12 – alors que Proxmox VE (ce qui démarre réellement sur le métal) est basé sur Debian 13. Un décalage de versions qui tournait discrètement depuis environ une semaine avant le plantage, en titillant activement exactement l’interface matérielle qui a lâché. Voilà une coïncidence franchement suspecte. 🔦 Depuis cette découverte, j’ai mis à jour amsd par précaution vers le build actuel natif Debian 13 (4.7.0) sur les trois hôtes.

⚖️ Être honnête sur ce que je ne sais pas vraiment

J’adorerais terminer cet article par « et c’était forcément ça ». En toute conscience, je ne peux pas. Mes deux autres serveurs – matériel identique, BIOS identique, firmware identique – faisaient eux aussi tourner exactement au même moment le même amsd obsolète compilé pour Debian 12, et aucun d’eux n’a planté. Ce n’est donc pas une histoire nette du genre « vieux pilote = plantage garanti ». Ma meilleure hypothèse de travail pour l’instant est une combinaison de deux demi-coupables : un erratum de plateforme HPE connu mais apparemment pas entièrement corrigé, peut-être rendu plus susceptible de se déclencher par un démon à la mauvaise version qui martèle la même liaison PCIe – aucun des deux ne suffisant seul, les deux ensemble relevant de la malchance. Ce qui est, et c’est agaçant, exactement le genre de bug intermittent, à la lisière du matériel, qui ne vous offre jamais le satisfaisant « eurêka, trouvé ! ». 🎯❌ Ce qu’il me reste à faire : surveiller l’IML pour repérer toute récidive, garder désormais à jour le firmware et les démons de gestion de chaque hôte, et espérer en silence qu’il s’agissait d’un hoquet électrique ponctuel et non du premier signe d’une puce en train de mourir lentement. 🤞 Si ça se reproduit, ce sera le moment où « ouvrir un ticket au support HPE » cessera d’être facultatif.