🌐 Aussi en: English · Deutsch · Español
Dans mon homelab trône un HPE ProLiant DL20 Gen10 Plus qui fait tourner Debian 13 en toute discrétion. Debian, c’est-à-dire : pas RedHat, pas un dérivé de RedHat, rien de ce avec quoi le Service Pack for ProLiant (SPP) de HPE accepte de dialoguer quand il s’agit de la voie de mise à jour installable, native au système. L’installateur de paquets natif du SPP repose sur RPM, point final. Debian a droit à un haussement d’épaules poli. 🤷
En temps normal, ce ne serait pas bien grave – un firmware ne se périme pas du jour au lendemain –, mais je voulais vérifier si la machine avait besoin d’un peu d’attention. Spoiler : oui, un peu. iLO 5 avait une version de retard (3.20 contre la 3.21 publiée), et je voulais une vue d’ensemble au lieu de courir après un PDF de changelog pour chaque composant – System ROM, SPS, firmware de la carte réseau et tout ce qui vit dans cet inventaire firmware de 14 éléments. Je voulais l’expérience « démarrer sur un outil, le laisser tout scanner, qu’il me dise ce qui est obsolète ». Cet outil existe. Il s’appelle SUM (Smart Update Manager), il est livré dans l’ISO du SPP et – point crucial – la variante ISO amorçable se moque de ce qui est installé sur vos disques. Elle démarre son propre environnement. En théorie, totalement indépendante du système d’exploitation. Problème Debian réglé, non ? 😌
Chers lecteurs, ce n’était pas si simple. Ça ne l’est jamais.
💾 Acte I : le HP USB Key Utility rejoue son plus grand flop
Les lecteurs de longue date se souviennent peut-être d’un article précédent où j’avais déjà mené exactement cette bataille contre l’outil officiel ISO-vers-USB de HPE. Il était vieux à l’époque. Il est encore plus vieux aujourd’hui. Et il ne fonctionne toujours pas de manière fiable – même histoire, autre jour : des échecs silencieux, une clé USB dont le menu de démarrage du serveur refuse poliment de reconnaître l’existence. HPE ne semble plus vraiment chouchouter cet outil, et ça se voit. 🪦
🔌 Acte II : Rufus en mode DD, et puis plus rien
Plan B : Rufus, précisément en mode DD – le mode qui écrit l’image en copie brute, bloc par bloc et bit pour bit, au lieu de la réinterprétation ISO-vers-FAT32 habituelle de Rufus. Exactement ce que veut une ISO hybride amorçable. Je branche, je démarre dessus… et ça s’arrête net, en plein démarrage, apparemment quelque part autour de GRUB. Pas un propre « périphérique non amorçable », pas de message d’erreur utile non plus – juste bloqué. Pourquoi ? Aucune idée, sincèrement – et à un moment donné, dans un homelab, « je ne sais pas pourquoi » doit devenir « on passe à autre chose ». ➡️
📡 Acte III : iLO n’a pas besoin de clé USB du tout
iLO Advanced dispose de Virtual Media : on pointe le lecteur CD/DVD virtuel d’iLO vers une ISO, et le serveur démarre dessus comme sur un vrai lecteur optique, en streaming sur le réseau. Et honnêtement, une fois le déclic passé, c’était une évidence : c’est objectivement la meilleure façon de faire, drames d’outillage mis à part. Le serveur vit à la cave, dans une baie, où il fait sa petite vie de baie-dans-une-cave. L’approche clé USB, c’est : descendre, ouvrir la baie, trouver le bon port, brancher la clé, remonter, lancer la mise à jour, puis redescendre encore pour récupérer la clé une fois terminé – deux allers-retours à la cave pour une seule mise à jour de firmware, juste pour qu’un objet physique effleure brièvement un port physique. En streamant l’ISO sur le réseau, je fais tout ça depuis mon bureau, dans un fauteuil confortable, un café à la main ☕, sans que le matériel n’ait jamais à savoir que je possède une clé USB. Ça valait bien de traverser quelques couches d’absurdités logicielles.
Sauf que – et c’est là que l’interface Virtual Media d’iLO dévoile discrètement son avis sur la question – elle n’accepte pas d’envoi de fichier depuis le navigateur. Elle veut une URL. Soit, j’ai des machines Linux qui traînent, je dois bien pouvoir servir un (1) fichier ISO en HTTP. 🙃
🐔🥚 Acte IV : l’œuf, la poule et la VM hébergée sur la mauvaise machine
Ma partie préférée, parce que je suis tombé dans le panneau en beauté et que je n’ai compris mon erreur qu’en plein facepalm.
Premier réflexe : héberger l’ISO sur une VM Linux qui tournait déjà. Deux minutes, c’est fait, le média virtuel est monté, je suis très content de moi. Puis vient le moment de redémarrer réellement le DL20 pour qu’il démarre sur cette image montée.
Ce qui – vous le voyez sans doute venir depuis l’orbite 🛰️ – a aussi redémarré la VM qui servait l’ISO, parce que cette VM tourne sur ce même serveur physique. Une dépendance circulaire parfaite : le serveur a besoin de l’ISO pour démarrer, et l’ISO est servie par quelque chose qui a besoin que le serveur tourne. Dès le début du redémarrage, mon serveur de fichiers s’est volatilisé en plein vol, et iLO s’est retrouvé avec un CD-ROM virtuel relié à absolument rien. Inventaire firmware après coup : inchangé, jusqu’au dernier chiffre – car rien n’avait été lu au-delà de la poignée de main initiale du montage.
Leçon réapprise à la dure : quand on redémarre un hôte physique, tout ce que cet hôte héberge tombe avec lui. Révolutionnaire, je sais. 🤦
🖥️ Acte V : servir l’ISO depuis une machine qui reste vraiment allumée
Solution : héberger l’ISO sur le client Windows à la place – une machine qui n’a strictement aucun avis sur l’état d’alimentation du DL20. Le serveur web intégré de Python semblait être la solution évidente en deux secondes :
python -m http.server 8000J’y pointe iLO, je monte l’image, je redémarre dans le menu de démarrage ponctuel, je sélectionne le CD/DVD virtuel… et ça ne démarre toujours pas proprement. Un progrès, pas un succès. Il est temps de réfléchir réellement à ce qui se passe au lieu de lancer des outils au hasard.
🕵️ Interlude : pourquoi un CD-ROM virtuel n’est pas un téléchargement
Le vrai cœur technique de toute cette saga : monter une ISO via le réseau, ce n’est pas la même chose que télécharger un fichier.
Un vrai lecteur optique n’est pas aspiré en mémoire d’un seul coup. Le chargeur d’amorçage lit des secteurs précis à la demande, en sautant dans la structure du disque exactement comme le dicte l’organisation du système de fichiers ISO9660 – quelques octets du catalogue de démarrage ici, un fragment de fichier quelque part au milieu là. Virtual Media émule exactement ce comportement via HTTP : iLO envoie des requêtes du genre « donne-moi les octets 5 368 709 120 à 5 368 711 168, s’il te plaît » – une minuscule tranche, à un décalage arbitraire, d’un fichier de 9,8 Go.
Le mécanisme HTTP prévu exactement pour ça, c’est la requête Range (Range: bytes=X-Y), à laquelle on répond par 206 Partial Content avec un en-tête Content-Range correspondant, et uniquement la tranche demandée.
Le classique http.server de Python ne fait pas ça. Pas du tout. Je l’ai testé directement : une requête Range pour une tranche de 1 Ko, et en retour 200 OK avec le fichier entier de 9,8 Go, l’en-tête Range complètement ignoré. Pour un petit fichier, c’est techniquement faux mais personne ne le remarque. Pour une ISO SPP de 9,8 Go sollicitée à chaque minuscule lecture de secteur, c’est la différence entre instantané et pratiquement infini ♾️ – ce qui, du point de vue d’iLO, ressemble exactement à un lecteur virtuel cassé ou vide.
La solution est un minuscule remplaçant prêt à l’emploi :
python -m pip install rangehttpserver
python -m RangeHTTPServer --bind 0.0.0.0 8000(Notez le python -m pip au lieu d’un simple pip – sur une installation fraîche de Python sous Windows, pip.exe n’est pas toujours dans le PATH, même si python.exe l’est. Appeler pip comme module via l’interpréteur contourne entièrement le problème.)
🔥 Coup de théâtre : le pare-feu contre-attaque
Serveur remplacé, requête Range retestée – toujours rien, cette fois un franc délai de connexion dépassé au lieu d’une mauvaise réponse. Pas « il n’y a personne » (ça ressemblerait à une connexion refusée), mais « les paquets disparaissent dans le néant » – la signature classique d’un pare-feu qui jette silencieusement le trafic au lieu de le rejeter franchement.
En fait, le pare-feu Windows Defender avait discrètement bloqué le nouveau serveur : l’ancien lancement de http.server avait déjà reçu un clic « Autoriser » à un moment donné, mais le démarrer en tant que python -m RangeHTTPServer comptait apparemment comme un contexte de programme suffisamment différent pour exiger sa propre demande d’autorisation – que j’avais ratée. Une exception de pare-feu plus tard 🔓, les deux problèmes avaient enfin disparu en même temps :
HTTP/1.0 206 Partial Content
Content-Range: bytes 1000-2000/9844506624
Accept-Ranges: bytesJoignable, et compatible Range. Exactement ce qu’un lecteur optique virtuel veut voir. ✅
📋 Ce qui tournait réellement, côté versions
Pour les curieux qui se demandent à quoi ressemble l’inventaire firmware d’un DL20 Gen10 Plus – 14 composants, récupérés directement via l’API Redfish d’iLO au lieu de cliquer page par page dans l’interface graphique :
- iLO 5 – v3.20 (une version de retard ; la 3.21 est sortie)
- System ROM (actif) – U60 v2.64
- System ROM (emplacement redondant/de secours) – U60 v2.50, volontairement en retard, c’est précisément le rôle de l’emplacement de secours
- Intelligent Provisioning, SPS, TPM, la carte réseau intégrée BCM5720, le contrôleur vidéo et le firmware des deux disques
Tout l’intérêt de démarrer sur l’ISO du SPP au lieu de courir après chaque fichier .fwpkg un par un : SUM analyse tout en une seule passe et me dit exactement ce qui est obsolète. Pas besoin de RedHat, pas besoin de clé USB, pas besoin d’un deuxième aller-retour à la cave. 🎉
🎓 La morale de l’histoire
Trois outils ont échoué ou à moitié échoué avant que l’un d’eux fonctionne vraiment – et celui-là n’a fonctionné qu’une fois que j’ai arrêté de considérer « servir un fichier en HTTP » comme un problème résolu et que je me suis souvenu qu’un média virtuel ne télécharge pas, il lit des secteurs, exactement comme un lecteur physique. Ajoutez une demande du pare-feu ratée en un clignement d’yeux, et voilà un bel après-midi passé sur ce qui aurait dû être une tâche de cinq minutes. Les mises à jour de firmware en homelab : jamais aussi simples que « cliquer sur mettre à jour », toujours l’occasion de réapprendre quelque chose qu’on savait techniquement déjà. 😅
Prochain épisode : ce que SUM trouvera réellement une fois qu’il démarrera correctement. Restez à l’écoute.
📸 Quelques captures d’écran du périple – Rufus échouant en silence, l’inventaire firmware Redfish, les en-têtes de requête Range enfin corrects – se trouvent ci-dessous.
