
🌐 También en: English · Deutsch · Français
🚨 No hay nada que te despierte tanto como un correo del iLO a las 20:30 diciéndote que un servidor se acaba de caer. Este artículo cuenta cómo perseguí ese cuelgue madriguera abajo: desde una entrada del registro de hardware con muy mala pinta, pasando por un aviso de bug real de HPE que resultó ser un callejón sin salida, hasta el que ahora es mi principal sospechoso: un demonio de gestión desactualizado que habla en silencio precisamente con el chip que falló.📧 El correo
El iLO no se anda con sutilezas. El asunto decía “CRITICAL” y el cuerpo contenía dos entradas consecutivas del Integrated Management Log, ambas con la misma marca de tiempo al segundo: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.Traducción para quien nunca se haya quedado mirando códigos de PCIe Advanced Error Reporting: algo en el bus PCI Express lanzó un error tan grave que el propio hardware no pudo corregirlo, y la máquina simplemente… dejó de responder. Uno de mis tres nodos Proxmox se había dado de bruces en silencio durante la noche. 💀🔍 Encontrar el chip de verdad
“Bus 1, Device 0, Function 2” no dice gran cosa por sí solo, así que en lugar de adivinar fui directamente al inventario de hardware del propio servidor a través de la API Redfish del iLO. Cada dispositivo PCI integrado de esta máquina informa de su dirección Bus/Device/Function exacta: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 faultLa función 2 en esa dirección no aparece por separado, pero está justo al lado del controlador de vídeo integrado, que en esta generación de ProLiant está implementado en realidad dentro del propio chip iLO 5, no en una GPU aparte. Así que el dispositivo que falla es alguna función del propio silicio del iLO que habla con el host por PCIe. No es que “el iLO haya muerto” (al fin y al cabo, me estaba mandando correos muy alegremente sobre su propio registro de fallos), sino más bien que el enlace PCIe interno entre el iLO y el resto del sistema tuvo un mal momento. 🧩📋 El aviso de HPE que encajaba a la perfección (casi)
Una búsqueda rápida me llevó a un aviso de HPE que no podría haber encajado mejor ni aunque lo hubiera escrito yo: “HPE ProLiant DL20/ML30 Gen10 Plus and ProLiant MicroServer Gen10 Plus v2 – Server May Experience ‘Uncorrectable PCI Express Error Detected’ Events.” Misma familia de servidores, mismo código de error (0x14000), misma dirección PCI. El aviso describe un bug documentado del firmware System ROM (BIOS) y propone como solución una actualización de la ROM. Caso cerrado, ¿no? 🎉 Pues no: lo comprobé. La BIOS, el iLO y el firmware del controlador de vídeo integrado ya estaban todos en las últimas versiones disponibles públicamente. La solución de “basta con actualizar el firmware” no sirve aquí: ya la tengo, o al menos lo que HPE publica actualmente como última versión. Así que o bien esta errata concreta no está del todo resuelta con el firmware actual, o bien está pasando algo completamente distinto. Un informe de bug que encaja como de manual pero que no se resuelve cuando sigues sus propios consejos es un tipo de frustración muy especial. 🤷🕵️ Entra en escena amsd, mi principal sospechoso actual
Aquí es donde la cosa se puso interesante. HPE distribuye un demonio de espacio de usuario llamado AMS (Agentless Management Service,amsd) que se ejecuta en el sistema operativo del host y devuelve telemetría de hardware al iLO: velocidad de los ventiladores, temperaturas, datos de salud. Lo crucial: lo hace a través de un canal interno que va por el mismo enlace PCIe integrado que el chip que acababa de fallar. Resulta que esta máquina en concreto estaba ejecutando amsd 3.6.0, una compilación hecha explícitamente para Debian 12, mientras que Proxmox VE (lo que de verdad arranca sobre el hierro) es Debian 13. Un desajuste de versiones que llevaba alrededor de una semana funcionando en silencio antes del cuelgue, toqueteando activamente justo la interfaz de hardware que falló. Es una coincidencia realmente sospechosa. 🔦 Desde que lo descubrí, he actualizado amsd por precaución a la compilación actual nativa para Debian 13 (4.7.0) en los tres hosts.⚖️ Siendo sincero sobre lo que en realidad no sé
Me encantaría terminar este artículo con “y era eso, seguro”. En conciencia, no puedo. Mis otros dos servidores (mismo hardware, misma BIOS, mismo firmware) también estaban ejecutando exactamente al mismo tiempo el mismoamsd desactualizado y compilado para Debian 12, y ninguno se colgó. Así que esto no es una historia limpia de “driver viejo = cuelgue garantizado”. Mi mejor teoría de trabajo ahora mismo es que se trata de una combinación de dos medio culpables: una errata de plataforma de HPE conocida pero, por lo visto, no del todo corregida, quizá con más probabilidades de dispararse por culpa de un demonio con la versión equivocada machacando el mismo enlace PCIe; ninguno de los dos basta por sí solo, y los dos juntos son simple mala suerte. Lo cual, por desgracia, es exactamente el tipo de bug intermitente y pegado al hardware que nunca te regala ese satisfactorio momento de “¡ajá, lo encontré!”. 🎯❌ Lo que me queda por hacer: vigilar el IML por si se repite, mantener al día a partir de ahora el firmware y los demonios de gestión de cada host, y esperar en silencio que esto haya sido un hipo eléctrico puntual y no la primera señal de un chip que se está muriendo poco a poco. 🤞 Si vuelve a pasar, ese será el momento en que “abrir un caso con el soporte de HPE” deje de ser opcional. 



