
🌐 Auch auf: English · Français · Español
🚨 Nichts macht einen so schlagartig wach wie eine iLO-Mail um 20:30, die einem mitteilt, dass gerade ein Server umgekippt ist. Dieser Beitrag erzählt, wie ich diesem Absturz in den Kaninchenbau gefolgt bin – von einem furchteinflößenden Eintrag im Hardware-Log über ein echtes HPE-Bug-Advisory, das sich als Sackgasse entpuppte, bis zu meinem aktuellen Hauptverdächtigen: einem veralteten Management-Daemon, der still und leise mit genau dem Chip redet, der ausgefallen ist.📧 Die Mail
iLO macht keine halben Sachen. Der Betreff lautete „CRITICAL“, und im Text standen zwei direkt aufeinanderfolgende Einträge aus dem Integrated Management Log, beide mit demselben Zeitstempel bis auf die Sekunde: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.Übersetzung für alle, die noch nie auf PCIe-Advanced-Error-Reporting-Codes gestarrt haben: Irgendetwas auf dem PCI-Express-Bus hat einen Fehler geworfen, der so schlimm war, dass die Hardware ihn selbst nicht korrigieren konnte – und die Kiste hat einfach … aufgehört zu antworten. Einer meiner drei Proxmox-Nodes war über Nacht still und leise mit dem Gesicht voran hingefallen. 💀🔍 Den eigentlichen Chip finden
„Bus 1, Device 0, Function 2“ sagt für sich genommen nicht viel, also bin ich direkt ans eigene Hardware-Inventar des Servers über die iLO-Redfish-API gegangen, statt zu raten. Jedes eingebaute PCI-Gerät in dieser Kiste meldet seine exakte Bus/Device/Function-Adresse: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 faultFunction 2 an dieser Adresse taucht nicht separat auf, sitzt aber direkt neben dem eingebauten Grafikcontroller – und der ist bei dieser ProLiant-Generation tatsächlich im iLO-5-Chip selbst implementiert, nicht als eigene GPU. Das fehlerhafte Gerät ist also irgendeine Funktion von iLOs eigenem Silizium, die per PCIe mit dem Host spricht. Nicht „iLO ist tot“ (es hat mir schließlich fröhlich Mails über sein eigenes Crash-Log geschickt) – eher hatte die interne PCIe-Verbindung zwischen iLO und dem Rest des Systems einen schlechten Moment. 🧩📋 Das HPE-Advisory, das perfekt passte (fast)
Eine kurze Suche förderte ein HPE-Advisory zutage, das nicht besser hätte passen können, wenn ich es selbst geschrieben hätte: „HPE ProLiant DL20/ML30 Gen10 Plus and ProLiant MicroServer Gen10 Plus v2 – Server May Experience ‚Uncorrectable PCI Express Error Detected‘ Events.“ Gleiche Serverfamilie, gleicher Fehlercode (0x14000), gleiche PCI-Adresse. Das Advisory beschreibt einen dokumentierten Bug in der System-ROM-Firmware (BIOS) und nennt als Lösung ein ROM-Update. Fall gelöst, oder? 🎉 Nur: Ich habe nachgesehen. BIOS, iLO und die Firmware des eingebauten Grafikcontrollers waren alle bereits auf den neuesten öffentlich verfügbaren Versionen. Der „einfach Firmware updaten“-Fix greift hier nicht – den habe ich schon, oder zumindest das, was HPE aktuell als neueste Version veröffentlicht. Entweder ist dieses konkrete Erratum mit der aktuellen Firmware also nicht vollständig behoben, oder hier läuft etwas ganz anderes. Ein Bug-Report wie aus dem Lehrbuch, der sich nicht erledigt, wenn man seinen eigenen Rat befolgt, ist eine ganz eigene Sorte Frust. 🤷🕵️ Auftritt amsd – mein aktueller Hauptverdächtiger
Jetzt wurde es spannend. HPE liefert einen Userspace-Daemon namens AMS (Agentless Management Service,amsd) aus, der auf dem Host-OS läuft und Hardware-Telemetrie – Lüfterdrehzahlen, Temperaturen, Zustandsdaten – an iLO zurückmeldet. Der springende Punkt: Er tut das über einen internen Kanal, der auf derselben eingebauten PCIe-Verbindung läuft wie der Chip, der gerade ausgefallen ist. Wie sich herausstellte, lief auf genau dieser Kiste amsd 3.6.0, ein Build, der ausdrücklich für Debian 12 kompiliert war – während Proxmox VE (das, was tatsächlich auf dem Blech bootet) Debian 13 ist. Eine Versions-Diskrepanz, die vor dem Absturz etwa eine Woche lang still vor sich hin lief und aktiv genau an der Hardware-Schnittstelle herumstocherte, die ausgefallen ist. Das ist ein wirklich verdächtiger Zufall. 🔦 Seit ich das entdeckt habe, habe ich amsd vorsorglich auf allen drei Hosts auf den aktuellen, nativen Debian-13-Build (4.7.0) aktualisiert.⚖️ Ehrlich sein bei dem, was ich eigentlich nicht weiß
Ich würde diesen Beitrag liebend gern mit „und das war es definitiv“ beenden. Guten Gewissens kann ich das nicht. Meine anderen beiden Server – identische Hardware, identisches BIOS, identische Firmware – liefen ebenfalls zur exakt selben Zeit mit demselben veralteten, für Debian 12 gebautenamsd, und keiner davon ist abgestürzt. Das ist also keine saubere „alter Treiber = garantierter Absturz“-Geschichte. Meine beste Arbeitstheorie ist im Moment eine Kombination aus zwei Halb-Schuldigen: ein bekanntes, aber offenbar nicht vollständig behobenes HPE-Plattform-Erratum, das möglicherweise eher ausgelöst wird, wenn ein Daemon mit falscher Version auf dieselbe PCIe-Verbindung einhämmert – keiner von beiden allein reicht aus, beide zusammen sind einfach Pech. Was ärgerlicherweise genau die Art von sporadischem, hardwarenahem Bug ist, die einem nie den befriedigenden „Aha, gefunden“-Moment gönnt. 🎯❌ Was mir bleibt: das IML auf Wiederholungen beobachten, Firmware und Management-Daemons auf jedem Host ab jetzt aktuell halten und still hoffen, dass das ein einmaliger elektrischer Schluckauf war und nicht das erste Anzeichen eines langsam sterbenden Chips. 🤞 Passiert es noch mal, ist der Punkt erreicht, an dem „einen HPE-Support-Fall aufmachen“ keine Option mehr ist, sondern Pflicht. 



