Roulette des mises à jour du BIOS : le clic le plus courageux de l’informatique

Pourquoi ça ressemble à une roulette (et pourquoi ce n’est pas le cas)

Mettre à jour le BIOS en production fait peur pour la même raison que remplacer le train d’atterrissage d’un avion en vol : c’est fondamental, difficile à observer en fonctionnement, et si ça tourne mal vous n’êtes plus en train de « déboguer », vous êtes en train de « récupérer ».

Le BIOS et le firmware UEFI se situent sous votre OS. Ils décident comment la mémoire est entraînée, comment les voies PCIe sont négociées, comment les périphériques de démarrage sont énumérés, comment les états d’alimentation sont gérés, comment la plateforme expose les tables ACPI, et comment les fonctions de sécurité comme Secure Boot et TPM se comportent. Si l’un de ces éléments change de façon inattendue, votre noyau et votre pile de stockage auparavant stables peuvent commencer à faire des siennes.

Mais « roulette » implique le pur hasard. En pratique, la plupart des mauvais résultats proviennent de modes d’échec très spécifiques et très reproductibles :

• Des suppositions sur des valeurs par défaut (ordre de démarrage, mode SATA, état de Secure Boot) qui se réinitialisent silencieusement.
• Sous-estimer les dépendances (firmware BMC/IPMI, option ROM des cartes réseau, firmware des HBA RAID).
• Changer des paramètres critiques pour la performance sans s’en apercevoir (C-states, NUMA, SMT, ASPM, Gen PCIe).
• Ne pas disposer d’un chemin de récupération lorsque l’hôte ne redémarre pas (console distante, image connue bonne, matériel de rechange).

Si vous traitez les mises à jour du BIOS comme des déploiements de code — planifier, mettre en scène, vérifier, revenir en arrière — vous transformez la roulette en routine. Pas « sûre ». Juste contrôlée.

Blague n°1 : Un flash BIOS est la seule fois où un serveur vous demande poliment de ne pas faire la chose que les centres de données savent le mieux faire : couper l’alimentation.

Faits intéressants et contexte historique

• Le BIOS date de l’époque du IBM PC, où un firmware en ROM assurait l’initialisation matérielle et une interface basique pour démarrer les systèmes d’exploitation.
• UEFI a remplacé le « BIOS classique » sur les plateformes modernes pour prendre en charge des disques plus volumineux, des chemins de démarrage plus rapides et un environnement pré-démarrage extensible.
• Secure Boot est né du besoin de protéger la chaîne de démarrage, mais opérationnellement il a aussi introduit une nouvelle catégorie de « ça fonctionnait hier, ça ne démarre plus aujourd’hui ».
• Le microcode CPU est une entité vivante : les mises à jour BIOS intègrent souvent des révisions de microcode qui modifient le comportement du CPU sans changer votre noyau.
• Les mises à jour de l’ère Spectre/Meltdown ont rendu les mises à jour firmware un sujet opérationnel courant, pas seulement une note en marge pour l’équipe hardware.
• L’entraînement mémoire est piloté par le firmware ; une mise à jour peut modifier subtilement les timings et les marges de stabilité, ce qui explique pourquoi des « erreurs ECC aléatoires » coïncident parfois avec des révisions de firmware.
• Le support NVMe a mûri avec le temps ; les premiers firmwares de plateforme étaient célèbres pour un ordre d’énumération étrange et des changements de démarrage surprises au fur et à mesure que les vendeurs affinaient l’initialisation PCIe.
• Les vendeurs livrent des « paramètres optimisés par défaut » qui sont optimisés pour des benchmarks marketing, pas pour vos SLOs de latence, votre budget énergétique ou la déterminisme de votre chemin de stockage.

Une citation qui devrait être tatouée à l’intérieur de chaque carnet d’astreinte : « L’espoir n’est pas une stratégie. » — Général Gordon R. Sullivan.

Ce que change vraiment une mise à jour du BIOS (les parties qui vous feront souffrir plus tard)

1) Mécanique de démarrage : entrées UEFI, ordre de démarrage et énumération des périphériques

Une mise à jour du BIOS peut :

• Réinitialiser l’ordre de démarrage sur la « valeur par défaut du vendeur », qui signifie généralement « l’appareil le plus bruyant sur le PCIe ».
• Recréer ou supprimer des entrées de démarrage UEFI (surtout si la NVRAM est réinitialisée ou réécrite).
• Changer l’ordre d’énumération des disques. Votre /dev/sda d’hier peut être /dev/sdb aujourd’hui. Si vous dépendez encore de cela, vous vivez dangereusement.

Pour Linux : vous devriez déjà utiliser des UUID dans /etc/fstab et un chargeur de démarrage qui n’est pas fragile. Mais de nombreuses flottes réelles ont des « exceptions legacy » qui deviennent l’incident de demain.

2) Comportement CPU : microcode, états d’alimentation, fonctions de virtualisation

Les mises à jour du BIOS apportent souvent :

• Un nouveau microcode qui peut modifier le comportement de prédiction de branchement et les paramètres de mitigation par défaut.
• Des valeurs par défaut différentes pour les C-states et P-states (économie d’énergie vs latence).
• Des bascules de virtualisation (Intel VT-x/VT-d, AMD-V/IOMMU) qui sont parfois réinitialisées.

Si votre charge est sensible à la latence, l’« aide » de gestion d’alimentation peut être le méchant. Si votre charge est axée sur le débit, les mitigations de microcode peuvent grignoter quelques points de pourcentage. Vous n’en discutez pas en abstrait. Vous mesurez et vous décidez.

3) Mémoire : entraînement, interleaving, comportement ECC

Le firmware gère l’entraînement mémoire. Un changement peut :

• Déplacer les marges de stabilité : des DIMM limites deviennent visibles.
• Modifier le mappage NUMA ou le comportement d’interleaving mémoire.
• Exposer (ou masquer) les voies de rapport d’erreurs ECC corrigées.

4) Chemin de stockage : mode AHCI/RAID, quirks NVMe, vitesse de lien PCIe

Le stockage est là où « ça démarre » ne suffit pas. Une mise à jour du BIOS peut :

• Basculer le mode SATA (AHCI ↔ RAID/RST), changeant la visibilité des périphériques et les pilotes.
• Modifier la négociation du lien PCIe : des appareils qui tournaient en Gen4 peuvent régresser en Gen3 (ou inversement, causant de l’instabilité).
• Réinitialiser les options « Above 4G decoding » ou Resizable BAR qui affectent le mappage des périphériques, surtout avec beaucoup de NVMe.

5) Positionnement de sécurité : état TPM, Secure Boot, bases de clés

Les mises à jour du BIOS réinitialisent parfois les paramètres de sécurité ou modifient la manière dont la plateforme expose les fonctionnalités TPM/TCG. Si vous utilisez le démarrage mesuré, le chiffrement de disque ou l’attestation, traitez les changements de firmware comme des changements de politique — car c’en sont.

Préparation : quoi capturer avant de toucher à quoi que ce soit

Avant de mettre à jour un firmware, vous voulez deux choses : un instantané de la réalité et un plan de récupération qui ne dépend pas de l’optimisme.

Capturer une « empreinte firmware »

• Version et date de sortie BIOS/UEFI.
• Version du firmware BMC/IPMI.
• Version du microcode CPU actuellement en cours d’utilisation.
• Mode de démarrage (UEFI vs Legacy) et état de Secure Boot.
• Versions du firmware des contrôleurs RAID/NVMe (si applicable).
• Vitesses de lien PCIe pour les périphériques critiques.

Capturer les réglages de la plateforme qui vous importent

C’est la partie que les gens sautent parce que c’est ennuyeux et que vous pouvez « regarder plus tard ». Le « plus tard » c’est quand vous regardez une console distante à 02:00 en essayant de vous souvenir si vous aviez désactivé les C-states sur les nœuds de base de données.

• Ordre de démarrage et entrées UEFI.
• TPM activé/désactivé et état de propriété (là où c’est pertinent).
• Paramètres de virtualisation et IOMMU.
• Profil d’alimentation : performance vs équilibré.
• Options PCIe comme Above 4G decoding, SR-IOV.
• Mode SATA, si un SATA existe du tout.

Définir la récupération

• Accès console hors bande vérifié (iKVM/Redfish/IPMI).
• Média de démarrage connu bon ou chemin de boot réseau qui fonctionne aujourd’hui.
• Contrôle d’alimentation hors bande testé.
• Un chemin de retour : méthode prise en charge par le vendeur pour rétrograder le BIOS, ou procédure de double BIOS/image de secours.
• Un plan « de secours » : capacité hôte de rechange, fenêtre de maintenance et une personne sur place si l’accès distant échoue.

Tâches pratiques : commandes, sorties et la décision que vous prenez

Ce sont les commandes que je veux réellement voir dans un runbook. Pas parce qu’elles sont sophistiquées — parce qu’elles vous obligent à comparer le « avant » et le « après » d’une manière qui capte les changements silencieux.

Task 1: Get BIOS version (and confirm you’re reading the platform, not the OS guess)

cr0x@server:~$ sudo dmidecode -s bios-version
2.4.7

Ce que cela signifie : C’est la version du firmware rapportée par le BIOS. Enregistrez-la.

Décision : Si vous ne pouvez pas identifier clairement le BIOS actuel, arrêtez. Vous ne pouvez pas gérer un changement que vous ne pouvez pas mesurer.

Task 2: Get BIOS release date (useful when vendors reuse version patterns)

cr0x@server:~$ sudo dmidecode -s bios-release-date
08/14/2024

Ce que cela signifie : Aide à corréler les changements de comportement avec le rythme de publication du vendeur.

Décision : Si le firmware installé est ancien par rapport à la référence de votre flotte, planifiez des mises à jour par étapes ; ne sautez pas trois ans d’un coup si le vendeur le déconseille.

Task 3: Confirm UEFI vs Legacy boot (this affects recovery steps)

cr0x@server:~$ test -d /sys/firmware/efi && echo UEFI || echo Legacy
UEFI

Ce que cela signifie : Le mode UEFI est actif si le sysfs EFI existe.

Décision : Si vous attendiez UEFI mais voyez Legacy, vous pouvez déjà être dans un état mal configuré ; ne procédez pas tant que vous n’avez pas recueilli les raisons.

Task 4: Check Secure Boot state (saves you from surprise “invalid signature” boots)

cr0x@server:~$ sudo mokutil --sb-state
SecureBoot enabled

Ce que cela signifie : Secure Boot est activé ; les chargeurs et noyaux doivent être signés de manière appropriée.

Décision : Si Secure Boot est activé en production, vérifiez que votre chemin de démarrage post-update est toujours signé et approuvé. Si vous dépendez de modules noyau personnalisés, prévoyez la signature et l’enrôlement.

Task 5: Capture current UEFI boot entries (so you can restore them)

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0002
Boot0001* UEFI PXE IPv4 (MAC:3C:FD:FE:12:34:56)
Boot0002* UEFI PXE IPv6 (MAC:3C:FD:FE:12:34:56)
Boot0003* ubuntu HD(1,GPT,1c2d...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

Ce que cela signifie : Vous avez des entrées de démarrage explicites ; BootOrder compte ; PXE est présent.

Décision : Sauvegardez cette sortie. Si après la mise à jour la machine démarre sur PXE de façon inattendue, vous réappliquerez BootOrder et validerez l’entrée disque.

Task 6: Identify disks by stable IDs (avoid /dev/sdX dependency)

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,FSTYPE,UUID,MOUNTPOINTS
sda     disk  1.8T
├─sda1  part  1G   vfat   3A1B-2C3D /boot/efi
└─sda2  part  1.8T ext4   2c7d...    /
nvme0n1 disk  3.5T
└─nvme0n1p1 part 3.5T xfs  9b12...   /data

Ce que cela signifie : Vous pouvez mapper les systèmes de fichiers aux UUID ; vous pouvez survivre à un renommage.

Décision : Si /etc/fstab utilise des chemins /dev/sdX, corrigez cela avant les changements de firmware. Le firmware se fiche de vos raccourcis.

Task 7: Confirm SATA mode hints (AHCI vs RAID) from kernel messages

cr0x@server:~$ sudo dmesg | grep -E "ahci|megaraid|mdraid|rst|VROC" | head
[    1.912345] ahci 0000:00:17.0: AHCI 0001.0301 32 slots 6 ports 6 Gbps 0x3f impl SATA mode

Ce que cela signifie : La plateforme expose AHCI. Si cela bascule en mode RAID, les noms de périphériques et les pilotes peuvent changer.

Décision : Si vous voyez aujourd’hui des pilotes RAID et que vous n’en aviez pas prévu, identifiez pourquoi. Si vous voyez AHCI aujourd’hui, assurez-vous que les mises à jour BIOS ne reviendront pas aux valeurs par défaut RAID.

Task 8: Check CPU microcode revision currently in use

cr0x@server:~$ grep -m1 microcode /proc/cpuinfo
microcode	: 0x2f

Ce que cela signifie : Révision de microcode visible par le noyau. Les mises à jour BIOS peuvent modifier ceci même si le paquet microcode OS reste inchangé.

Décision : Enregistrez le « avant ». Après la mise à jour, comparez. Si des changements de performance apparaissent, le microcode est un suspect.

Task 9: Check active kernel mitigations (context for post-update performance deltas)

cr0x@server:~$ grep . /sys/devices/system/cpu/vulnerabilities/* | head
/sys/devices/system/cpu/vulnerabilities/spectre_v2: Mitigation: Retpolines; IBPB: conditional; STIBP: disabled; RSB filling
/sys/devices/system/cpu/vulnerabilities/mds: Mitigation: Clear CPU buffers; SMT vulnerable

Ce que cela signifie : La vue du noyau sur les mitigations. Le firmware/microcode peut changer ce qui est disponible ou activé.

Décision : Si une mise à jour BIOS change le statut des mitigations, attendez-vous à un impact mesurable sur les performances. Décidez si le compromis sécurité/performance est acceptable et documentez-le.

Task 10: Check PCIe link speed/width for critical devices (NICs, NVMe HBAs)

cr0x@server:~$ sudo lspci -s 3b:00.0 -vv | grep -E "LnkCap|LnkSta"
LnkCap: Port #8, Speed 16GT/s, Width x16, ASPM L1, Exit Latency L1 <64us
LnkSta: Speed 16GT/s, Width x16

Ce que cela signifie : Cet appareil a négocié PCIe Gen4 x16 (16GT/s). Après une mise à jour BIOS, vous pourriez voir une régression (8GT/s Gen3) ou une réduction de largeur.

Décision : Si la vitesse/la largeur du lien diminue après la mise à jour, enquêtez sur les paramètres PCIe du BIOS, le reseating des risers ou des bugs de firmware avant d’accuser « le réseau » ou « le stockage ».

Task 11: Check NVMe health and error logs (catch new AER storms early)

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0
temperature                         : 41 C
available_spare                     : 100%
percentage_used                     : 2%
media_errors                        : 0
num_err_log_entries                 : 0

Ce que cela signifie : L’état du lecteur est sain pour le moment. Après la mise à jour, surveillez la croissance des journaux d’erreurs ou des changements de température soudains dus à des modifications d’états d’alimentation.

Décision : Si les entrées d’erreur augmentent après la mise à jour, envisagez des changements de gestion d’énergie PCIe ou une instabilité de lien introduite par le firmware.

Task 12: Check for PCIe AER spam (a common post-update “performance bug”)

cr0x@server:~$ sudo journalctl -k -b | grep -i aer | head
Jan 22 10:14:02 server kernel: pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
Jan 22 10:14:02 server kernel: pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Physical Layer

Ce que cela signifie : Les erreurs AER corrigées peuvent quand même écraser les performances à cause du bruit d’interruption/journalisation et du réentraînement du lien.

Décision : Si un flot d’AER apparaît après la mise à jour, traitez-le comme un problème de plateforme : vérifiez les paramètres PCIe, les notes de firmware et l’implantation physique ; ne vous contentez pas de muter les journaux.

Task 13: Verify time and NTP after update (yes, firmware can mess with it)

cr0x@server:~$ timedatectl
               Local time: Wed 2026-01-22 10:20:11 UTC
           Universal time: Wed 2026-01-22 10:20:11 UTC
                 RTC time: Wed 2026-01-22 10:20:10
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Ce que cela signifie : RTC et horloge système sont sains et synchronisés.

Décision : Si l’heure est fausse après une mise à jour BIOS, corrigez-la immédiatement. Une mauvaise heure casse TLS, les systèmes en cluster, la corrélation des journaux et votre capacité à prouver ce qui s’est passé.

Task 14: Validate ZFS pool health (if you run ZFS, you check it every time)

cr0x@server:~$ sudo zpool status -x
all pools are healthy

Ce que cela signifie : Aucun pool connu en problème pour l’instant.

Décision : Si une mise à jour BIOS déclenche des changements de contrôleur de stockage, vous voulez une ligne de base. Après la mise à jour, vérifiez à nouveau ; toute nouvelle erreur de checksum est une alarme rouge, pas un « probablement correct ».

Task 15: Validate multipath (SAN or dual-path NVMe-oF)

cr0x@server:~$ sudo multipath -ll | head -n 12
mpatha (3600508b400105e210000900000490000) dm-2 IBM,2810XIV
size=500G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 3:0:0:1 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 4:0:0:1 sdc 8:32 active ready running

Ce que cela signifie : Vous avez un chemin actif et un chemin activé ; les priorités semblent saines.

Décision : Si après la mise à jour un chemin disparaît, enquêtez sur l’énumération PCIe/NIC, les réglages SR-IOV ou les interactions firmware HBA avant de toucher aux configs SAN.

Task 16: Confirm BMC reachability (you want this before you brick anything)

cr0x@server:~$ ipmitool -I lanplus -H bmc01 -U admin chassis status
System Power         : on
Power Overload       : false
Power Interlock      : inactive
Main Power Fault     : false
Power Control Fault  : false
Power Restore Policy : previous

Ce que cela signifie : Le contrôle hors bande fonctionne et le châssis répond.

Décision : Si vous ne pouvez pas parler au BMC de manière fiable, ne faites pas de mise à jour BIOS distante. Réparez l’accès hors bande d’abord ou planifiez une intervention sur site.

Méthode de diagnostic rapide

Après une mise à jour du BIOS, le pire moment pour commencer à « enquêter de manière large » est quand vous perdez de la disponibilité. Vous avez besoin d’un flux de triage qui resserre le problème en minutes.

Première étape : pouvez-vous joindre la machine et voir à quel stade elle plante ?

• Console hors bande : passe-t-elle le POST ? affiche-t-elle un menu de périphérique de démarrage ? se fige-t-elle lors de l’entraînement mémoire ?
• État d’alimentation : boucle de redémarrage ? s’éteint immédiatement ?
• Bips/codes POST (si disponibles) : peu glamour, mais directs.

Deuxième étape : si elle démarre, la chaîne de démarrage est-elle stable ?

• UEFI vs Legacy changé ?
• BootOrder réinitialisé sur PXE ?
• Secure Boot modifié, provoquant le rejet du chargeur ?
• Mode disque changé (AHCI/RAID) cachant le disque racine ?

Troisième étape : si l’OS est en ligne, qu’est-ce qui a changé sous lui ?

• Négociation PCIe : vitesse/largeur du lien, périphériques manquants, flot AER.
• États d’alimentation CPU : nouveaux pics de latence ; comportement d’échelle de fréquence modifié.
• Routage des interruptions : le comportement MSI/MSI-X peut changer ; surveillez la saturation IRQ sur un seul cœur.
• Microcode/mitigations : régressions de performance ; nouvelle posture de sécurité.
• Chemins de stockage : multipath dégradé, timeouts NVMe, incompatibilité firmware des contrôleurs.

Les vérifications rapides des goulets d’étranglement (la liste « ne réfléchissez pas trop »)

1. Scan des logs noyau : erreurs, AER, fautes IOMMU, réinitialisations NVMe.
2. Présence des périphériques : lspci, lsblk, multipath ; confirmez que les contrôleurs critiques existent.
3. Négociation de lien : vérifiez LnkSta pour NIC/HBA ; une régression Gen est une évidence.
4. Comportement de fréquence CPU : confirmez le governor et l’état turbo ; les réinitialisations de politique d’alimentation sont courantes.
5. Latence de stockage : un aperçu rapide iostat ; ne benchmarkez pas encore, repérez juste les incendies.

Trois mini-récits d’entreprise depuis les tranchées du firmware

Mini-récit n°1 : L’incident causé par une mauvaise supposition

Une entreprise de taille moyenne exploitait une flotte mixte : certains nœuds démarraient depuis des SSD SATA en miroir, d’autres depuis NVMe, et quelques vieilles machines « spéciales » démarraient encore en mode Legacy parce que « c’était plus simple il y a des années ». L’équipe a programmé une mise à jour BIOS sur un rack pendant une fenêtre calme.

La mauvaise supposition était simple : « L’ordre de démarrage est stable. » Sur la moitié des machines, après la mise à jour, le firmware a réinitialisé le BootOrder et promu le PXE au-dessus du disque local. Les hôtes ont démarré, demandé au réseau une image de démarrage et — comme l’environnement PXE était toujours configuré pour le provisionnement — certains ont lancé un instalateur. D’autres sont restés à un prompt. Tous étaient hors service.

L’ingénieur d’astreinte a fait ce que la plupart des gens font d’abord : il a accusé la mise à jour du système d’exploitation qui avait eu lieu plus tôt dans la semaine. Ils ont perdu du temps à chercher des changements de paquets et des régressions du noyau qui n’existaient pas. Pendant ce temps, le vrai problème était visible sur la console distante : une bannière PXE enjouée, attendant.

La correction a été ennuyeuse : utiliser efibootmgr sur les machines encore accessibles pour restaurer le démarrage local en premier, et le BIOS setup sur celles qui ne l’étaient pas. La correction à long terme était moins excitante mais plus importante : standardiser le mode de démarrage (UEFI), standardiser les identifiants de disque, et traiter l’ordre de démarrage comme une configuration à capturer et restaurer.

Le postmortem a eu une seule phrase qui comptait : « Nous avons supposé que les valeurs par défaut étaient persistantes. » Les valeurs par défaut ne sont pas persistantes. Les valeurs par défaut sont l’idée que le vendeur se fait de vos priorités, et les vendeurs n’ont jamais eu affaire à votre pager.

Mini-récit n°2 : L’optimisation qui s’est retournée contre eux

Une autre équipe gérait des services à faible latence et avait précédemment ajusté des réglages BIOS pour la performance : C-states limités, profil d’alimentation « performance », et quelques réglages PCIe modifiés pour garder les périphériques éveillés et réactifs. Ils avaient une ligne de base documentée, mais elle n’était pas appliquée automatiquement.

Une mise à jour BIOS est arrivée avec une note sur « amélioration de l’efficacité énergétique » et « compatibilité PCIe améliorée ». Elle a aussi réinitialisé le profil d’alimentation sur mode équilibré et réactivé des C-states plus profonds. Les systèmes ont démarré correctement. Tout vert. Pas d’alarmes.

Puis les graphiques ont bougé. La latence P99 a augmenté lors des pics de trafic, pas assez pour déclencher une alarme immédiate, mais suffisamment pour provoquer des plaintes clients. L’utilisation CPU semblait plus faible, ce qui rendait la situation encore plus déroutante : les machines « travaillaient moins » tout en accomplissant la même tâche. Quelques ingénieurs ont brièvement célébré le gain d’efficacité.

Le retournement venait de la latence de réveil et du comportement d’augmentation de fréquence. Sous une charge en rafales, les cœurs se mettaient en veille plus agressivement et montaient en fréquence plus lentement. Cela s’est traduit directement en latence tail. La correction a été de réappliquer le profil performance et de vérifier, avec des mesures, que les réglages restaient effectivement appliqués.

Leçon : « optimisation » dans les notes de version du firmware concerne rarement votre fonction objective. Elle concerne les suites de tests du vendeur, des cibles réglementaires et des charges de travail génériques. Si vous optimisez pour la latence, vous ré-ajustez après les changements de firmware — et vous le prouvez avec des données.

Mini-récit n°3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une équipe en charge d’une plateforme lourde en stockage avait l’habitude, jugée obsessive, d’appliquer chaque mise à jour BIOS d’abord à deux nœuds canaris — un nœud « normal » et un nœud « étrange » (NIC différent, HBA différent, population mémoire différente). Ils capturaient les empreintes avant/après : version BIOS, microcode, statut du lien PCIe, et un petit ensemble de vérifications de latence de stockage.

Lors d’un cycle de mise à jour, le nœud canari « étrange » est revenu avec son HBA NVMe fonctionnant à une largeur PCIe réduite. Il fonctionnait toujours. Il fonctionnait juste plus lentement. Les logs du noyau montraient des erreurs AER corrigées, et le lien négociait à la baisse. Cela ressemblait à un problème matériel — jusqu’à ce qu’ils le corrèlent avec le changement de firmware et le reproduisent au redémarrage.

Parce que c’était un canari, pas une mise à jour globale, ils ont eu le temps. Ils ont testé un paramètre BIOS lié à la gestion d’alimentation PCIe et désactivé l’ASPM sur ce slot. Le lien s’est stabilisé à la largeur et à la vitesse attendues. Ils ont ajouté le réglage à la checklist post-update et l’ont vérifié sur les nœuds restants.

Pas d’incident. Aucun impact client. Juste une note interne tranquille : « Le firmware X nécessite l’override de gestion d’alimentation PCIe pour le HBA Y. » C’est le type de victoire opérationnelle qui n’obtient jamais d’applaudissements, parce que rien n’a pris feu.

Blague n°2 : Le meilleur déploiement de firmware ressemble à une bonne réunion — si inaperçu que personne ne se souvient qu’il a eu lieu.

Erreurs courantes : symptômes → cause racine → correctif

1) Symptom: host boots into PXE or “No boot device”

Cause racine : BootOrder réinitialisé ; entrée de démarrage UEFI supprimée ; énumération des disques modifiée.

Correctif : Utiliser la console distante pour sélectionner la bonne entrée de démarrage ; restaurer avec efibootmgr ; si l’entrée est manquante, réinstaller/recréer le chargeur (par ex. grub-install ou outil fournisseur).

2) Symptom: OS can’t find root filesystem after update

Cause racine : Le mode SATA a basculé (AHCI ↔ RAID) ou le mode du contrôleur a changé ; initramfs manque le pilote ; les noms de périphériques ont changé.

Correctif : Rétablir le mode SATA/contrôleur dans le BIOS ; reconstruire l’initramfs avec les pilotes adéquats ; assurer que /etc/fstab utilise des UUID.

3) Symptom: sudden storage latency increase, but “everything is healthy”

Cause racine : Le lien PCIe a négocié à la baisse (chute de Gen ou réduction de largeur) ; flot d’erreurs AER corrigées ; changements ASPM/gestion d’alimentation.

Correctif : Vérifier lspci -vv pour LnkSta ; inspecter journalctl -k pour AER ; ajuster les paramètres PCIe / d’alimentation du BIOS ; reseater le matériel si besoin.

4) Symptom: virtualization workloads fail or passthrough breaks

Cause racine : VT-d/IOMMU désactivé ou réinitialisé ; bascules SR-IOV modifiées ; Above 4G decoding désactivé.

Correctif : Réactiver IOMMU/VT-d, SR-IOV, Above 4G decoding ; vérifier les groupes de périphériques et le binding des pilotes ; redémarrer et retester.

5) Symptom: secure boot suddenly blocks boot or kernel modules

Cause racine : Secure Boot basculé ; base de clés mise à jour/réinitialisée ; enrôlement MOK perdu.

Correctif : Restaurer l’état de Secure Boot de manière intentionnelle ; ré-enregistrer les clés ; assurer que chargeur/noyau/modules sont signés correctement.

6) Symptom: sporadic reboots or new ECC corrected errors

Cause racine : Changements d’entraînement mémoire ayant resserré les marges ; BIOS modifiant les timings mémoire ; DIMM limite exposé.

Correctif : Comparer les compteurs d’erreurs DIMM, effectuer des diagnostics mémoire en maintenance, envisager de réduire la fréquence mémoire ou de remplacer le DIMM ; si le vendeur confirme, revenir en arrière sur le BIOS ou appliquer un correctif ultérieur.

7) Symptom: performance regression with no obvious logs

Cause racine : Profil d’alimentation réinitialisé sur équilibré ; C-states plus profonds activés ; comportement turbo modifié ; différences de microcode/mitigations.

Correctif : Vérifier le profil d’alimentation BIOS et le governor OS ; comparer le microcode et le statut des mitigations ; mesurer avant/après avec des tests représentatifs de la charge.

8) Symptom: NIC missing or interface names changed

Cause racine : Changements d’Option ROM/driver UEFI ; changement d’ordre d’énumération PCIe ; réinitialisation des réglages SR-IOV/ports.

Correctif : Confirmer la présence du périphérique avec lspci ; revoir les paramètres NIC du BIOS ; valider les règles de nommage prévisible ; mettre à jour initramfs/udev si nécessaire.

Listes de contrôle / plan étape par étape

Étape par étape : un déploiement BIOS en production qui respecte la physique

1. Lisez les notes de version comme si vous passiez en revue une PR risquée. Cherchez : changements de microcode, correctifs de sécurité, « paramètres par défaut mis à jour », notes PCIe/NVMe, et avertissements sur la voie de mise à jour.
2. Confirmez que l’accès hors bande fonctionne. Testez la console distante, le contrôle d’alimentation et l’authentification. Si vous ne pouvez pas accéder à iKVM de façon fiable, planifiez une intervention sur site.
3. Capturez l’empreinte préflight. Sauvegardez les sorties des commandes ci-dessus dans un ticket ou un artefact de runbook.
4. Exportez la configuration BIOS si votre vendeur le permet. Certaines plateformes autorisent des profils de configuration BIOS. Utilisez-les. Ils transforment le savoir tribal en fichiers.
5. Sélectionnez des canaris. Un nœud typique, un nœud « étrange ». Si vous ne canarisez que les faciles, vous ne canarisez pas vraiment.
6. Mettre à jour le BMC/IPMI si nécessaire, dans le bon ordre. Les vendeurs exigent parfois des mises à jour BMC avant le BIOS. Ignorez cela et vous vous offrez des bizarreries de gestion à distance.
7. Appliquer la mise à jour BIOS aux canaris. Ne combinez pas avec des mises à jour OS/noyau dans la même fenêtre sauf si vous aimez les responsabilités ambiguës.
8. Vérification post-update (mêmes commandes que le préflight). Comparez version BIOS, microcode, état Secure Boot, entrées UEFI, statut PCIe, santé du stockage et journaux.
9. Exécuter un petit test de charge ciblé. Pas un benchmark de vanité. Quelque chose qui ressemble à la production : échantillon de latence stockage, test de débit réseau, smoke test applicatif.
10. Attendre en observation. La latence tail, les erreurs corrigées et les comportements thermiques apparaissent souvent après une heure, pas dans la première minute.
11. Déployer par lots. Taille de lot réduite avec pauses. Si vous ne pouvez pas faire de pause, vous ne faites pas un déploiement ; vous organisez un événement.
12. Documenter le delta. Tout paramètre changé, tout override requis, tout impact de performance. Cela devient le « ennuyeux mais correct » du trimestre suivant.

Checklist de récupération : lorsque l’hôte ne revient pas proprement

1. Confirmer l’état d’alimentation via le BMC ; ne couper l’alimentation que si les recommandations du vendeur l’autorisent (certaines plateformes nécessitent des temps d’attente).
2. Utiliser la console distante pour observer les codes/messages POST ; noter où ça s’arrête.
3. Tenter le menu de démarrage pour sélectionner le bon périphérique ; éviter de changer plusieurs paramètres BIOS au hasard.
4. Si les entrées de démarrage sont manquantes, recréez ou réinstallez le chargeur.
5. Si les disques sont manquants, vérifier d’abord le mode SATA/RAID et la détection du contrôleur de stockage.
6. Si l’OS démarre mais que la performance est dégradée, vérifier le lien PCIe et les logs AER avant de toucher aux configs applicatives.
7. Envisager un rollback BIOS seulement après avoir capturé des preuves ; revenir en arrière efface des indices et peut introduire ses propres problèmes.

Checklist politique : ce que vous standardisez pour que ça cesse d’être un drame

• Versions BIOS de référence par modèle de plateforme.
• Profils de configuration BIOS « golden » : alimentation, PCIe, virtualisation, démarrage, sécurité.
• Preuves préflight et postflight obligatoires attachées aux tickets de changement.
• Exigences canary et limites de lots.
• Critères de rollback explicites et responsabilité du processus.

FAQ

1) Should I update BIOS if everything is working?

Si « tout fonctionne » inclut une exposition de sécurité connue, des bugs de stabilité correspondant à vos symptômes, ou des avis du vendeur pertinents pour votre pile CPU/NIC/stockage, oui — sur un plan par étapes. Si la mise à jour ajoute uniquement la prise en charge d’un matériel que vous n’avez pas, non. Le churning firmware a un coût.

2) What’s the difference between BIOS update and microcode update from the OS?

Les paquets microcode OS peuvent charger du microcode au démarrage, mais le microcode fourni par le BIOS peut différer et peut être chargé plus tôt dans la chaîne de démarrage. Vous mesurez ce qui est actif via /proc/cpuinfo et comparez avant/après.

3) Why did my boot order change after a BIOS update?

Parce que les vendeurs traitent l’ordre de démarrage comme une préférence, pas comme un contrat. La NVRAM peut être réinitialisée ou réécrite pendant les mises à jour. Capturez toujours la sortie efibootmgr -v au préalable.

4) Can a BIOS update reduce storage performance without any errors?

Oui. La négociation du lien PCIe peut changer silencieusement (Gen4 → Gen3, x8 → x4), la gestion d’alimentation peut modifier le comportement de réveil des périphériques, et le firmware peut altérer les mappages IOMMU. L’absence d’erreurs n’est pas une preuve que les performances n’ont pas changé.

5) Is it safer to update BIOS from the OS or from the BMC?

« Plus sûr » dépend de la maturité des outils de la plateforme et de votre environnement. Les mises à jour via BMC peuvent fonctionner même si l’OS est malade, mais elles dépendent aussi de la stabilité du BMC et de la fiabilité réseau. Les outils basés sur l’OS peuvent être plus observables mais risquent des interactions pilote/OS. Choisissez une méthode par plateforme et opérationnalisez-la avec des tests, pas des impressions.

6) Do I need to update BMC/IPMI firmware too?

Parfois. Les vendeurs peuvent exiger des versions BMC spécifiques pour de nouvelles images BIOS, et les incompatibilités peuvent causer des lectures de capteurs bizarres, des courbes de ventilation ou des problèmes de console distante. Consultez la matrice de compatibilité du vendeur dans les notes de version que vous prétendez déjà lire.

7) What’s the fastest way to detect “it’s PCIe” after a BIOS update?

Vérifiez lspci -vv pour LnkSta sur le périphérique affecté et scannez journalctl -k pour des messages AER. Un lien négocié à la baisse ou un flot AER est une régression classique induite par le firmware.

8) Can I just roll back the BIOS if anything looks weird?

Parfois, mais n’assumez pas que la rétrogradation est supportée ou sûre. Certaines plateformes bloquent les rétrogradations à cause de fusibles de sécurité ou de politiques de signature de capsule. De plus, revenir en arrière peut réinitialiser des paramètres et compliquer l’enquête. Rétrogradez lorsque vous avez une régression claire et une cible connue bonne.

9) Why did Secure Boot behavior change when I didn’t touch it?

Les mises à jour BIOS peuvent réinitialiser Secure Boot sur la valeur par défaut, mettre à jour les bases de clés, ou modifier la manière dont l’enrôlement MOK est géré. Traitez Secure Boot comme un élément de configuration géré ; vérifiez l’état après mise à jour avec mokutil.

10) How do I keep BIOS settings consistent across a fleet?

Utilisez les outils fournisseurs pour exporter/importer des profils BIOS quand c’est possible, et renforcez cela par une vérification de conformité : vérifiez les paramètres clés après les mises à jour. Si vous comptez sur des humains pour cliquer correctement les mêmes 14 options, vous vous préparez à l’incohérence.

Conclusion : prochaines étapes qui réduisent vraiment le risque

Les mises à jour BIOS ne sont pas héroïques. Elles sont inévitables. Le courage consiste à prétendre que c’est un rituel unique et non une pratique opérationnelle que vous pouvez améliorer.

La prochaine fois que vous regarderez ce message « Ne pas éteindre », gagnez votre calme :

• Capturez une empreinte avant/après (BIOS, microcode, entrées de démarrage, état du lien PCIe, santé du stockage).
• Canarisez sur un nœud normal et un nœud étrange. Toujours.
• Vérifiez l’accès hors bande avant de commencer, pas après l’avoir regretté.
• Réappliquez et vérifiez les réglages BIOS importants pour vos SLOs, en particulier les knobs d’alimentation et PCIe.
• Quand quelque chose casse, procédez au triage dans l’ordre : chaîne de démarrage → présence des périphériques → négociation PCIe → comportement d’alimentation/microcode → chemins de stockage.

L’objectif n’est pas d’éliminer le risque. C’est de rendre le risque lisible, borné et récupérable. C’est ainsi que les systèmes de production restent ennuyeux — et c’est le compliment le plus élevé que les opérations puissent donner.