🌐 Auch auf: English · Français · Español
Im Homelab steht ein HPE ProLiant DL20 Gen10 Plus und lässt still und leise Debian 13 laufen. Debian, also: nicht RedHat, kein RedHat-Ableger, nichts von dem, womit HPEs Service Pack for ProLiant (SPP) beim installierbaren, betriebssystemeigenen Update-Weg überhaupt reden will. Der native Paket-Installer von SPP basiert auf RPM, Punkt. Debian bekommt ein höfliches Schulterzucken. 🤷
Normalerweise wäre das nicht weiter schlimm – Firmware veraltet nicht über Nacht –, aber ich wollte nachsehen, ob die Kiste irgendwo etwas Zuwendung braucht. Spoiler: ja, ein bisschen. iLO 5 war eine Version hintendran (3.20 statt der veröffentlichten 3.21), und ich wollte das Gesamtbild, statt für jede einzelne Komponente – System ROM, SPS, NIC-Firmware und was sonst noch in diesem 14-teiligen Firmware-Inventar wohnt – von Hand einem Changelog-PDF hinterherzujagen. Ich wollte das Erlebnis „in ein Tool booten, alles scannen lassen, mir sagen lassen, was veraltet ist“. Dieses Tool gibt es. Es heißt SUM (Smart Update Manager), steckt im SPP-ISO und – das ist der Knackpunkt – die bootfähige ISO-Variante interessiert sich nicht dafür, was auf deinen Platten installiert ist. Sie bootet ihre eigene Umgebung. Theoretisch komplett betriebssystemunabhängig. Debian-Problem gelöst, oder? 😌
Liebe Leserin, lieber Leser: So einfach war es nicht. Ist es nie.
💾 Erster Akt: Das HP USB Key Utility und die Neuauflage seines größten Flops
Wer schon länger mitliest, erinnert sich vielleicht an einen früheren Beitrag, in dem ich genau diesen Kampf mit HPEs offiziellem ISO-zu-USB-Tool schon einmal ausgefochten habe. Damals war es alt. Heute ist es älter. Zuverlässig funktioniert es immer noch nicht – gleiche Geschichte, anderer Tag: stille Fehlschläge und ein USB-Stick, dessen Existenz das Bootmenü des Servers höflich ignoriert. HPE scheint in dieses Tool nicht mehr viel Liebe zu stecken, und das merkt man. 🪦
🔌 Zweiter Akt: Rufus im DD-Modus, und dann Stillstand
Plan B: Rufus, und zwar ausdrücklich im DD-Modus – der Modus, der das Image als rohe, bitgenaue Blockkopie schreibt, statt es wie Rufus sonst üblich nach FAT32 umzudeuten. Genau das, was ein hybrides bootfähiges ISO will. Eingesteckt, davon gebootet … und es blieb einfach stehen, mitten im Bootvorgang, offenbar irgendwo um GRUB herum. Kein sauberes „nicht bootfähiges Gerät“, auch keine hilfreiche Fehlermeldung – einfach hängen geblieben. Warum, ist mir bis heute schleierhaft – und irgendwann muss im Homelab aus „keine Ahnung, warum“ eben „weiter geht’s“ werden. ➡️
📡 Dritter Akt: iLO braucht überhaupt keinen USB-Stick
iLO Advanced hat Virtual Media: Man richtet das virtuelle CD/DVD-Laufwerk von iLO auf ein ISO, und der Server bootet davon wie von einem echten optischen Laufwerk, gestreamt über das Netzwerk. Und ehrlich gesagt, als der Groschen fiel, fiel er richtig: Das ist objektiv der bessere Weg, Tool-Drama hin oder her. Der Server wohnt im Keller, in einem Rack, und macht dort sein Rack-im-Keller-Ding. Der USB-Stick-Weg heißt: runter in den Keller, Rack aufmachen, richtigen Port finden, Stick einstecken, wieder hoch, Update machen, und wenn alles durch ist, nochmal runter, um den Stick zu holen – zwei Kellerausflüge für ein Firmware-Update, nur damit ein physischer Gegenstand kurz einen physischen Port berühren darf. Streame ich das ISO übers Netz, erledige ich das alles vom Schreibtisch aus, auf einem bequemen Stuhl, mit Kaffee ☕, und die eigentliche Hardware muss nie erfahren, dass ich überhaupt einen USB-Stick besitze. Dafür lohnt es sich, sich durch ein paar Schichten Tool-Unsinn zu kämpfen.
Nur – und hier verrät die Virtual-Media-Oberfläche von iLO still und leise ihre Meinung zum Thema – sie nimmt keinen Datei-Upload aus dem Browser an. Sie will eine URL. Na gut, ich habe Linux-Kisten herumstehen, da werde ich ja wohl eine (1) ISO-Datei per HTTP ausliefern können. 🙃
🐔🥚 Vierter Akt: Henne, Ei und die VM auf der falschen Kiste
Mein Lieblingsteil, weil ich voll darauf reingefallen bin und meinen Fehler erst mitten im Facepalm bemerkt habe.
Erster Impuls: das ISO von einer Linux-VM ausliefern, die ohnehin schon lief. Zwei Minuten, fertig, Virtual Media eingebunden, sehr zufrieden mit mir selbst. Dann war es Zeit, den DL20 tatsächlich neu zu starten, damit er von diesem eingebundenen Image bootet.
Was – das siehst du wahrscheinlich schon aus dem Orbit kommen 🛰️ – auch die VM neu startete, die das ISO auslieferte, denn diese VM läuft auf genau diesem physischen Server. Eine perfekte zirkuläre Abhängigkeit: Der Server braucht das ISO zum Booten, und das ISO wird von etwas ausgeliefert, das den laufenden Server braucht. In dem Moment, in dem der Neustart begann, verschwand mein Fileserver mitten im Flug, und iLO hielt ein virtuelles CD-ROM in der Hand, das mit absolut nichts verbunden war. Firmware-Inventar danach: unverändert, bis auf die letzte Stelle – denn über den ersten Mount-Handshake hinaus war nie etwas gelesen worden.
Lektion auf die harte Tour neu gelernt: Wenn du einen physischen Host neu startest, geht alles, was dieser Host hostet, mit ihm unter. Bahnbrechende Erkenntnis, ich weiß. 🤦
🖥️ Fünfter Akt: Ausliefern von irgendwo, das auch wirklich oben bleibt
Lösung: das ISO stattdessen vom Windows-Client ausliefern – einer Maschine, der der Stromzustand des DL20 völlig egal ist. Pythons eingebauter Webserver schien die offensichtliche Zwei-Sekunden-Lösung zu sein:
python -m http.server 8000iLO darauf gerichtet, eingebunden, ins einmalige Bootmenü neu gestartet, das virtuelle CD/DVD-Laufwerk gewählt … und es kam immer noch nicht sauber hoch. Fortschritt, aber kein Erfolg. Zeit, tatsächlich darüber nachzudenken, was da passiert, statt Tools darauf zu werfen.
🕵️ Zwischenspiel: Warum ein virtuelles CD-ROM kein Download ist
Der eigentliche technische Kern dieser ganzen Saga: Ein ISO über das Netzwerk einzubinden ist nicht dasselbe wie eine Datei herunterzuladen.
Ein echtes optisches Laufwerk wird nicht vorab komplett in den Speicher gesaugt. Der Bootloader liest bei Bedarf bestimmte Sektoren und springt dabei genau so durch die Struktur der Disc, wie es das ISO9660-Dateisystem-Layout vorgibt – hier ein paar Bytes aus dem Boot-Katalog, dort ein Dateifragment irgendwo in der Mitte. Virtual Media emuliert genau dieses Verhalten über HTTP: iLO schickt Anfragen wie „gib mir bitte die Bytes 5.368.709.120 bis 5.368.711.168“ – ein winziges Stück an einem beliebigen Offset einer 9,8 GB großen Datei.
Der HTTP-Mechanismus genau dafür ist der Range-Request (Range: bytes=X-Y), beantwortet mit 206 Partial Content samt passendem Content-Range-Header, der nur das angeforderte Stück enthält.
Pythons klassischer http.server kann das nicht. Überhaupt nicht. Direkt getestet: einen Range-Request für ein 1 KB großes Stück geschickt, zurück kam 200 OK und die komplette 9,8-GB-Datei, der Range-Header wurde komplett ignoriert. Bei einer kleinen Datei technisch falsch, aber es merkt keiner. Bei einem 9,8 GB großen SPP-ISO, das bei jedem einzelnen winzigen Sektor-Lesezugriff angefragt wird, ist das der Unterschied zwischen sofort und praktisch unendlich ♾️ – was aus Sicht von iLO genau wie ein kaputtes oder leeres virtuelles Laufwerk aussieht.
Die Lösung ist ein winziger Drop-in-Ersatz:
python -m pip install rangehttpserver
python -m RangeHTTPServer --bind 0.0.0.0 8000(Beachte das python -m pip statt eines nackten pip – bei einer frischen Python-Installation unter Windows liegt pip.exe nicht zuverlässig im PATH, auch wenn python.exe es tut. Pip als Modul über den Interpreter aufzurufen umgeht das komplett.)
🔥 Plot-Twist: Die Firewall schlägt zurück
Server getauscht, den Range-Request nochmal getestet – wieder nichts, diesmal ein glatter Verbindungs-Timeout statt einer falschen Antwort. Nicht „niemand zu Hause“ (das sähe nach einer abgelehnten Verbindung aus), sondern „die Pakete verschwinden im Nichts“ – die klassische Handschrift einer Firewall, die Traffic stillschweigend verwirft, statt ihn offen abzulehnen.
Es stellte sich heraus, dass die Windows Defender Firewall den neuen Server still und leise blockiert hatte: Der alte http.server-Lauf hatte irgendwann schon einen „Zulassen“-Klick bekommen, aber der Start als python -m RangeHTTPServer galt offenbar als ausreichend anderer Programmkontext, um eine eigene, frische Berechtigungsabfrage zu brauchen – eine, die ich übersehen hatte. Eine Firewall-Ausnahme später 🔓 waren endlich beide Probleme gleichzeitig weg:
HTTP/1.0 206 Partial Content
Content-Range: bytes 1000-2000/9844506624
Accept-Ranges: bytesErreichbar und Range-fähig. Genau das, was ein virtuelles optisches Laufwerk sehen will. ✅
📋 Was versionsmäßig tatsächlich drauf war
Für alle, die neugierig sind, wie das Firmware-Inventar eines DL20 Gen10 Plus überhaupt aussieht – 14 Komponenten, direkt über die Redfish-API von iLO abgefragt, statt sich Seite für Seite durch die GUI zu klicken:
- iLO 5 – v3.20 (ein Release hintendran; 3.21 ist draußen)
- System ROM (aktiv) – U60 v2.64
- System ROM (redundanter/Backup-Slot) – U60 v2.50, absichtlich hinterher, genau dafür ist der Backup-Slot da
- Intelligent Provisioning, SPS, TPM, die Onboard-NIC BCM5720, der Grafikcontroller und die Firmware beider Laufwerke
Der ganze Sinn davon, das SPP-ISO zu booten, statt jeder .fwpkg-Datei einzeln von Hand hinterherzulaufen: SUM scannt alles in einem Durchgang und sagt mir genau, was veraltet ist. Kein RedHat nötig, kein USB-Stick nötig, kein zweiter Kellerausflug nötig. 🎉
🎓 Die Moral von der Geschicht’
Drei Tools sind gescheitert oder halb gescheitert, bevor eines tatsächlich funktioniert hat – und auch das erst, als ich aufgehört habe, „eine Datei per HTTP ausliefern“ als gelöstes Problem zu behandeln, und mich daran erinnert habe, dass Virtual Media nichts herunterlädt, sondern Sektoren liest, genau wie ein physisches Laufwerk. Dazu eine Firewall-Abfrage, die ich im Vorbeiblinzeln verpasst habe, und schon ist ein ordentlicher Nachmittag für etwas draufgegangen, das eine Fünf-Minuten-Aufgabe hätte sein sollen. Firmware-Updates im Homelab: nie so einfach wie „auf Update klicken“, immer eine Gelegenheit, etwas neu zu lernen, das man technisch gesehen schon wusste. 😅
Als Nächstes: was auch immer SUM tatsächlich findet, sobald es richtig bootet. Dranbleiben.
📸 Ein paar Screenshots der Reise – Rufus beim stillen Scheitern, das Redfish-Firmware-Inventar, die Range-Request-Header, die endlich richtig aussehen – gibt es unten.
