Debian 13 : firmware manquant après l’installation — corriger le support NIC et HBA correctement

Ce qui se passe réellement (et pourquoi Debian agit ainsi)

« Firmware manquant » sous Debian signifie rarement que le pilote du kernel est absent. Cela signifie que le pilote s’est chargé, a tenté
d’initialiser le matériel, puis a demandé un fichier de firmware depuis l’espace utilisateur (typiquement via udev/systemd-udevd)
à partir de /lib/firmware. Le pilote est présent ; le blob de microcode ne l’est pas.

Sur les NICs et HBAs modernes, le firmware n’est pas une décoration optionnelle. C’est la façon dont le périphérique met en place l’entraînement
du lien, les moteurs d’offload, la gestion des files, le comportement du PHY, et parfois la capacité entière à s’énumérer ou se réinitialiser proprement.
Beaucoup de pilotes s’attachent sans firmware, mais ils exposent un « netdev » qui ne se met jamais en lien, ou un HBA qui montre la présence PCIe
mais n’arrive pas à faire monter les phys SAS/SATA.

Debian a historiquement séparé le logiciel « libre » des paquets de firmware « non-free ». C’est une décision de politique ayant des conséquences techniques :
l’installateur et les sources apt par défaut peuvent ne pas inclure les paquets de firmware nécessaires pour démarrer avec le réseau ou le stockage.
Debian 12 a introduit non-free-firmware comme composant de dépôt officiel, ce qui a aidé, mais les mises à niveau, les images personnalisées
et les installations minimes peuvent toujours vous laisser en purgatoire de firmware.

La bonne correction n’est pas « copier un fichier au hasard dans /lib/firmware une fois et l’oublier ». La bonne correction est :
installer les bons paquets de firmware Debian (pour recevoir mises à jour, hashs et suivi des dépendances),
s’assurer qu’ils sont disponibles dans l’initramfs si nécessaire,
et vérifier que le périphérique a bien chargé le firmware après le redémarrage.

Une règle opérationnelle : si la machine a besoin du firmware pour accéder au réseau qui fournit le firmware, vous avez besoin d’un chemin hors-bande.
Cela peut être un média physique, un miroir local, une seconde carte NIC fonctionnelle, ou l’accès IPMI/iKVM avec une ISO montée. Si vous riez,
c’est que vous êtes déjà passé par là.

Blague #1 : Le firmware, c’est comme le café — tout le monde fait semblant de pouvoir s’en passer jusqu’à ce que la production commence à poser des questions.

Quelques faits et historique utiles

• Le chargement de firmware est passé d’un « cas limite » à un comportement par défaut : nombreux périphériques PCIe livrent des ROMs minimales et comptent sur des blobs fournis par l’OS pour des fonctionnalités et corrections.
• Linux utilise un mécanisme standard de requête : les pilotes appellent request_firmware() et le kernel demande à l’espace utilisateur de fournir le fichier depuis /lib/firmware.
• La séparation des dépôts chez Debian est dictée par la politique : historiquement « main » reste libre ; le firmware n’était souvent pas éligible et vivait donc dans « non-free ».
• Debian 12 a introduit non-free-firmware : les paquets de firmware ont été déplacés vers un composant dédié pour alléger les installations sans mélanger tout dans « non-free ».
• Le comportement de l’installateur dépend de l’image : certaines ISOs d’installation incluent le firmware ; d’autres ne l’incluent pas intentionnellement. Même installateur, résultats différents.
• Le firmware NIC affecte souvent le lien et les offloads : l’interface peut apparaître mais sans carrier, avec un lien instable, ou des comportements étranges de checksum/TSO.
• Firmware HBA et pilotes kernel sont des couches séparées : le périphérique PCIe peut s’énumérer, mais la couche SAS peut ne jamais monter si le firmware n’est pas chargé ou est incompatible.
• Initramfs importe pour le stockage critique au démarrage : si votre système racine est derrière un HBA qui nécessite du firmware, le blob doit être disponible tôt (dans l’initramfs), pas seulement après le montage du root.
• Les paquets de firmware sont mis à jour pour la sécurité aussi : il ne s’agit pas seulement de « faire fonctionner le périphérique », mais aussi d’éviter d’expédier des microcodes/firmwares anciens et vulnérables.

Playbook de diagnostic rapide

Quand la machine n’a ni réseau ni stockage après l’installation, vous n’avez pas de temps pour les légendes. Lancez cette séquence et arrêtez-vous dès que vous obtenez un signal décisif.

Première étape : confirmer que le kernel voit le matériel

• PCIe visible ? Si lspci n’affiche pas le périphérique, ce n’est pas un problème de paquet de firmware. Pensez aux réglages BIOS/UEFI, à l’alimentation du slot, à la bifurcation, à un riser défectueux ou à une carte morte.
• Pilote lié ? Si le périphérique est visible mais sans pilote, vous êtes dans un cas de « pilote/module manquant », pas de « firmware manquant ».

Deuxième étape : rechercher les requêtes et échecs de firmware

• dmesg dit la vérité : cherchez « firmware », « Direct firmware load failed » ou « failed to load ». Cela vous donne le nom exact du fichier demandé par le pilote.
• Mapper le nom de fichier au paquet : les paquets Debian placent les fichiers sous /lib/firmware. Si le fichier n’existe pas, installez le paquet qui le fournit.

Troisième étape : décider si cela nécessite l’initramfs

• Root sur ce périphérique ? Si le firmware manquant affecte le périphérique qui fournit le root (HBA, NVMe derrière un contrôleur, etc.), vous devez vous assurer que le firmware est dans l’initramfs et régénérer celui-ci.
• NIC non-root ? Pour une carte réseau, l’initramfs n’est généralement pas requis à moins que vous ne fassiez un netboot, un root iSCSI, ou ayez besoin du réseau tôt au démarrage pour un déverrouillage à distance.

Quatrième étape : corriger la configuration des dépôts avant d’« installer le firmware »

• Activer non-free-firmware : n’ajoutez pas de blobs à la main sauf si vous êtes isolé et discipliné à ce sujet.
• Mettre à jour, installer, reconstruire l’initramfs, redémarrer : faites-le une fois, proprement, puis vérifiez avec les logs.

Tâches pratiques : commandes, sorties et décisions (12+)

Tâche 1 : Identifier le matériel exact (IDs PCI)

cr0x@server:~$ sudo lspci -nn | egrep -i 'ethernet|network|fibre|sas|raid|scsi'
03:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572]
04:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 [1000:0087]

Ce que ça signifie : Le kernel voit à la fois le NIC et le HBA au niveau PCIe. Bien.
Les IDs entre crochets (8086:1572, 1000:0087) sont votre vérité terrain.

Décision : Si votre périphérique n’apparaît pas ici, arrêtez de chasser les paquets de firmware. Vérifiez le BIOS/UEFI, l’enclenchement, l’alimentation et la topologie PCIe.

Tâche 2 : Vérifier quel pilote est lié (ou non)

cr0x@server:~$ sudo lspci -nnk -s 03:00.0
03:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572]
	Subsystem: Intel Corporation Ethernet Converged Network Adapter X710-2 [8086:0000]
	Kernel driver in use: i40e
	Kernel modules: i40e

Ce que ça signifie : Le NIC utilise i40e, donc le pilote existe et est lié.

Décision : Si « Kernel driver in use » est absent, il se peut que vous ayez besoin d’un kernel différent, d’un module, ou de corriger Secure Boot/signature de module — pas le firmware.

Tâche 3 : Trouver les erreurs de firmware dans le journal du kernel

cr0x@server:~$ sudo dmesg -T | egrep -i 'firmware|direct firmware|failed to load|i40e|mpt3sas' | tail -n 30
[Mon Dec 30 09:12:18 2025] i40e 0000:03:00.0: Direct firmware load for i40e/ddp/ppm.pkg failed with error -2
[Mon Dec 30 09:12:18 2025] i40e 0000:03:00.0: The DDP package was not found at i40e/ddp/ppm.pkg
[Mon Dec 30 09:12:19 2025] mpt3sas 0000:04:00.0: Direct firmware load for mpt3sas/mpi3mr.fw failed with error -2
[Mon Dec 30 09:12:19 2025] mpt3sas 0000:04:00.0: firmware: failed to load mpt3sas/mpi3mr.fw (-2)

Ce que ça signifie : L’erreur -2 est « fichier introuvable ». Le pilote demande des fichiers précis.

Décision : Vous avez besoin des paquets qui fournissent /lib/firmware/i40e/ddp/ppm.pkg et /lib/firmware/mpt3sas/mpi3mr.fw,
ou au moins de l’ensemble correct pour votre génération de matériel.

Tâche 4 : Confirmer que le fichier de firmware est absent (ne pas supposer)

cr0x@server:~$ ls -l /lib/firmware/i40e/ddp/ppm.pkg /lib/firmware/mpt3sas/mpi3mr.fw
ls: cannot access '/lib/firmware/i40e/ddp/ppm.pkg': No such file or directory
ls: cannot access '/lib/firmware/mpt3sas/mpi3mr.fw': No such file or directory

Ce que ça signifie : Pas présent. Ce n’est pas encore un « bug pilote ». C’est un fichier manquant.

Décision : Corrigez les sources apt et installez les paquets de firmware appropriés. Évitez les téléchargements manuels sauf si vous avez un bundle contrôlé et audité.

Tâche 5 : Inspecter les composants apt (est-ce que non-free-firmware est activé ?)

cr0x@server:~$ grep -R --no-filename -E '^[[:space:]]*deb ' /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>/dev/null
deb http://deb.debian.org/debian trixie main
deb http://deb.debian.org/debian-security trixie-security main
deb http://deb.debian.org/debian trixie-updates main

Ce que ça signifie : Seul main est activé. Les paquets de firmware se trouvent souvent dans non-free-firmware.

Décision : Ajoutez non-free-firmware (et généralement contrib) aux mêmes lignes.

Tâche 6 : Mettre à jour les sources en toute sécurité (éditer une fois, ne pas bricoler)

cr0x@server:~$ sudo sed -i 's/ main$/ main contrib non-free-firmware/' /etc/apt/sources.list
cr0x@server:~$ tail -n 3 /etc/apt/sources.list
deb http://deb.debian.org/debian trixie main contrib non-free-firmware
deb http://deb.debian.org/debian-security trixie-security main contrib non-free-firmware
deb http://deb.debian.org/debian trixie-updates main contrib non-free-firmware

Ce que ça signifie : Vous avez activé le composant qui contient le firmware dont vous avez besoin.

Décision : Maintenant apt devrait voir les paquets de firmware. Si vous n’avez toujours pas de réseau, vous aurez besoin d’un chemin hors-ligne — poursuivez la lecture.

Tâche 7 : Rafraîchir les métadonnées apt et vérifier la présence des paquets de firmware

cr0x@server:~$ sudo apt update
Hit:1 http://deb.debian.org/debian trixie InRelease
Hit:2 http://deb.debian.org/debian-security trixie-security InRelease
Hit:3 http://deb.debian.org/debian trixie-updates InRelease
Reading package lists... Done
Building dependency tree... Done
All packages are up to date.

Ce que ça signifie : Les dépôts sont accessibles et les métadonnées apt sont rafraîchies.

Décision : Si apt ne peut pas atteindre les dépôts parce que votre unique NIC nécessite du firmware, passez aux étapes d’installation hors-ligne dans la section checklist.

Tâche 8 : Installer le bundle de firmware général (souvent suffisant)

cr0x@server:~$ sudo apt install -y firmware-linux firmware-linux-nonfree firmware-misc-nonfree
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  firmware-linux firmware-linux-nonfree firmware-misc-nonfree
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 78.4 MB of archives.
After this operation, 210 MB of additional disk space will be used.
Setting up firmware-linux-nonfree (20250801-1) ...
Setting up firmware-misc-nonfree (20250801-1) ...
Setting up firmware-linux (20250801-1) ...

Ce que ça signifie : Ces paquets méta couvrent une grande partie des blobs courants. Sur les NICs et HBAs serveur, cela résout souvent le problème immédiatement.

Décision : Si un nom de fichier spécifique manque encore dans dmesg, il se peut que vous ayez besoin d’un paquet plus ciblé. Vérifiez ensuite.

Tâche 9 : Trouver quel paquet fournit un fichier de firmware spécifique

cr0x@server:~$ apt-file update
cr0x@server:~$ apt-file search -x '(^|/)i40e/ddp/ppm\.pkg$'
firmware-misc-nonfree: /lib/firmware/i40e/ddp/ppm.pkg

Ce que ça signifie : apt-file mappe les noms de fichiers aux paquets. C’est la façon propre d’en finir rapidement avec les discussions.

Décision : Installez le(s) paquet(s) identifié(s). Si vous êtes dans un environnement minimal sans apt-file, utilisez dpkg -S après avoir installé les bundles probables.

Tâche 10 : Rebuild initramfs quand le stockage est impliqué

cr0x@server:~$ sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.12.0-1-amd64
W: Possible missing firmware /lib/firmware/mpt3sas/mpi3mr.fw for module mpt3sas

Ce que ça signifie : La génération d’initramfs avertit quand un module pourrait nécessiter un firmware non inclus.
C’est un indice, pas un dogme — certains avertissements sont conservateurs.

Décision : Si cela avertit encore concernant le fichier exact vu dans dmesg, vous n’avez pas installé le bon paquet (ou le nom du firmware diffère pour votre génération).

Tâche 11 : Vérifier que le fichier de firmware existe maintenant

cr0x@server:~$ ls -l /lib/firmware/i40e/ddp/ppm.pkg
-rw-r--r-- 1 root root 1048576 Aug  1 12:01 /lib/firmware/i40e/ddp/ppm.pkg

Ce que ça signifie : Le fichier est présent. Le pilote peut le charger au prochain reset du périphérique ou au redémarrage.

Décision : Redémarrez si c’est un périphérique critique au boot, ou déchargez/rechargez le module si c’est sûr (souvent plus sûr de redémarrer sur des serveurs).

Tâche 12 : Confirmer que le NIC monte bien et obtient un lien

cr0x@server:~$ ip -br link show
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp3s0f0         DOWN           3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST>

Ce que ça signifie : L’interface existe. Elle est DOWN. Cela peut être administratif (non montée) ou physique (pas de carrier).

Décision : Montez-la et vérifiez le carrier ; si pas de carrier, vérifiez les optiques, le port du switch, et les logs firmware/driver.

Tâche 13 : Monter l’interface et vérifier carrier + vitesse

cr0x@server:~$ sudo ip link set enp3s0f0 up
cr0x@server:~$ ip -br link show enp3s0f0
enp3s0f0         UP             3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST,UP,LOWER_UP>
cr0x@server:~$ sudo ethtool enp3s0f0 | egrep -i 'link detected|speed|duplex'
Speed: 10000Mb/s
Duplex: Full
Link detected: yes

Ce que ça signifie : Le lien est up à 10G, ce qui suggère fortement que la situation de firmware du NIC est résolue (au moins suffisamment pour fonctionner).

Décision : Si Link detected: no, ne blâmez pas immédiatement le firmware. Vérifiez la compatibilité optique/DAC, la configuration du switch, et dmesg pour des resets répétés.

Tâche 14 : Confirmer que l’HBA énumère des périphériques

cr0x@server:~$ sudo lsscsi -g
[0:0:0:0]    disk    ATA      INTEL SSDSC2  DL2C  /dev/sda  /dev/sg0
[1:0:0:0]    disk    SEAGATE   ST16000NM00  SN03  /dev/sdb  /dev/sg1
[1:0:1:0]    disk    SEAGATE   ST16000NM00  SN03  /dev/sdc  /dev/sg2

Ce que ça signifie : La couche SCSI voit des disques. Votre HBA n’est pas seulement présent ; il est fonctionnel.

Décision : Si rien n’apparaît, vérifiez dmesg pour des échecs de chargement de firmware HBA ou pour phys down.

Tâche 15 : Vérifier les messages de firmware du module après reboot

cr0x@server:~$ sudo journalctl -b -k | egrep -i 'firmware|i40e|mpt3sas' | tail -n 40
Dec 30 09:24:01 server kernel: i40e 0000:03:00.0: firmware version 9.30 0x8000c6a8 1.2762.0
Dec 30 09:24:02 server kernel: i40e 0000:03:00.0: DDP package loaded successfully
Dec 30 09:24:02 server kernel: mpt3sas 0000:04:00.0: firmware version 16.00.12.00
Dec 30 09:24:02 server kernel: scsi host1: mpt3sas

Ce que ça signifie : C’est l’état de succès : lignes explicites de version de firmware et absence de messages « failed to load ».

Décision : Capturez ces logs dans vos notes de build/commissioning. Au prochain update du kernel, si quelque chose casse, vous saurez à quoi ressemblait l’état « bon ».

Corriger correctement : dépôts, paquets et initramfs

1) Préférer les firmwares packagés aux fichiers déposés manuellement

Copier un blob dans /lib/firmware fonctionne — jusqu’à ce que ça ne fonctionne plus. Cela contourne la propriété dpkg, complique l’audit,
et casse silencieusement lors d’une réinstallation parce que personne ne se souvient du fichier artisanal que vous avez scp’d à 2h du matin.

L’approche packagée vous apporte :
des mises à jour versionnées,
des checksums fournis par l’archive,
des emplacements de fichiers prévisibles,
et une suppression propre si vous construisez des images minimales.

2) Activer explicitement non-free-firmware

Sur Debian 13, la valeur raisonnable pour du matériel réel est main contrib non-free-firmware pour les dépôts de base.
Vous pouvez garder non-free désactivé si vous le souhaitez ; le firmware est séparé pour une raison.

Si vous gérez une flotte, ne laissez pas cela au hasard. Intégrez-le dans votre provisioning (preseed/autoinstall, images Golden, gestion de config).

3) Installer les bons paquets de firmware

Commencez par les ensembles communs :
firmware-linux,
firmware-linux-nonfree,
firmware-misc-nonfree.
Ils couvrent beaucoup : éléments Intel NIC, Realtek, divers firmwares de contrôleurs et charges utiles de type microcode.

Ensuite, allez cibler : utilisez le nom de fichier issu de dmesg et mappez-le à un paquet via apt-file search.
Cela vous garde honnête et évite d’« installer 600 Mo de firmware parce qu’un seul fichier manque ».

4) Décider si l’initramfs doit contenir le firmware

Voici la ligne de partage : si le firmware est nécessaire avant le montage du système racine, il doit être dans l’initramfs.
Les contrôleurs de stockage pour disques root en sont le cas classique. Les NICs pour root iSCSI et le réseau précoce pour déverrouillage distant aussi.

L’outil initramfs de Debian inclut généralement le firmware référencé par les modules inclus, mais il existe des cas limites :
modules chargés plus tard, requêtes de pilotes après un reset, ou changements de nom de firmware entre versions de kernel.
Si vous voyez des avertissements pendant update-initramfs, considérez-les comme une invitation à vérifier, pas comme du bruit de fond.

5) Redémarrer volontairement (ou réinitialiser proprement le périphérique)

Le firmware est chargé lorsque le pilote initialise le périphérique. Vous pouvez parfois déclencher cela par un reload de module.
Sur les serveurs, un redémarrage propre est souvent l’opération la moins coûteuse, surtout quand le stockage est impliqué.
« On va juste rmmod le pilote HBA sur le root live » est le genre d’expérience qui mène à des évolutions de carrière inattendues.

Citation (idée paraphrasée) de Gene Kim : les équipes opérationnelles performantes réduisent les défaillances en rendant le travail visible et répétable, pas en étant héroïques.

Spécificités NIC et HBA : ce qui échoue et à quoi ça ressemble

NICs : le périphérique est là, le réseau ne l’est pas

Les échecs de firmware NIC ont tendance à se présenter de trois façons :

• Interface manquante : rare pour « firmware manquant », plus courant pour des problèmes de pilote/module ou de PCI.
• Interface présente, pas de carrier : problème de blob firmware ou de configuration PHY ; aussi incompatibilité optique/DAC.
• Interface fonctionne mais est instable : resets répétés dans dmesg, lien qui claque, anomalies d’offload de checksum, ou effondrement des performances sous charge.

L’habitude la plus productive : quand le réseau est cassé, récupérez toujours les lignes dmesg autour du nom du pilote. Sur les NICs Intel serveur,
vous verrez souvent une requête pour des paquets DDP ou des messages liés au NVM. Sur Broadcom, vous verrez des noms de firmware bnx2/bnx2x.
Sur Realtek, des charges rtl_nic/ spécifiques apparaîtront.

HBAs : le démarrage peut fonctionner, puis le stockage se délite (ou n’apparaît jamais)

Les HBAs sont l’endroit où les erreurs de firmware coûtent cher car ils sont directement liés à la disponibilité des données.
Vous pouvez avoir un OS parfaitement installé et pourtant ne voir aucun disque si le microcode du HBA ne peut pas être chargé ou si la combinaison pilote/firmware est incompatible.

Modes de défaillance que vous verrez réellement :

• PCIe s’énumère, pas d’hôtes SCSI : le pilote se charge mais ne peut pas initialiser le contrôleur sans firmware.
• Hôte SCSI existant, pas de cibles : le contrôleur s’initialise mais ne monte pas les phys ; parfois câblage/backplane, parfois firmware.
• Cibles apparaissent de façon intermittente : resets, timeouts, tempêtes d’aborts de commandes ; peut être firmware, câbles SAS marginaux, ou bizarreries d’expander/backplane.

Sur les HBAs, traitez le firmware comme une partie de la compatibilité, pas seulement comme un blob à avoir une fois. Les mises à jour du kernel peuvent changer
les attentes du pilote, et les vendeurs expédient parfois un firmware qui « fonctionne » jusqu’à ce que vous atteigniez une certaine profondeur de file ou un chemin de récupération d’erreur.

Blague #2 : La seule chose plus permanente qu’un contournement temporaire est un contournement de stockage que quelqu’un a oublié de documenter.

Trois mini-histoires d’entreprise (toutes anonymisées, toutes plausibles)

Incident causé par une mauvaise hypothèse : « L’interface existe, donc le firmware doit être OK »

Une entreprise de taille moyenne a déployé Debian sur un lot de serveurs avec des NICs 10G double port. L’automatisation de type kickstart (oui, Debian peut aussi être automatisé)
vérifiait que ip link affichait les noms d’interface attendus puis procédait à la configuration des VLANs, des bonds et du routage.
Le test d’acceptation était simple : « interface présente » et « MAC correspond à l’inventaire ».

La première semaine, tout paraissait normal — jusqu’à ce que le trafic augmente. Sous charge soutenue, le NIC se réinitialisait, cassait le bond, puis revenait.
Le monitoring interprétait cela comme des pertes de paquets occasionnelles et des pics de latence étranges. L’équipe réseau accusait le switch. L’équipe serveurs accusait l’équipe réseau,
comme de coutume. Personne ne voulait regarder dmesg parce que la machine « avait manifestement une NIC ».

Les logs kernel disaient autre chose : le pilote fonctionnait sans package DDP et retombait périodiquement en défaut. Ce n’était pas un état binaire
« fonctionne/ne fonctionne pas ». C’était « fonctionne jusqu’à ce que vous lui demandiez ce pour quoi vous l’avez acheté ».
Le firmware manquant n’empêchait pas l’énumération ; il empêchait le NIC d’utiliser le bon datapath et de se comporter de façon cohérente.

La correction fut ennuyeuse : activer non-free-firmware, installer le bon paquet de firmware, redémarrer, puis mettre à jour le test d’acceptation.
Le nouveau test exigeait « link up », « pas d’échec de chargement de firmware » et « pas de réinitialisations sous un test de charge synthétique ».
Même matériel. Même kernel. Résultat différent parce qu’ils ont cessé de supposer.

Optimisation qui s’est retournée contre eux : images minimales et pureté « pas de paquets en trop »

Une autre organisation construisait des images Debian minimales pour des déploiements edge. L’objectif était sensé : réduire la surface d’attaque, réduire le churn de mises à jour, garder les images petites.
Ils ont retiré agressivement des « paquets inutiles », y compris des bundles de firmware, et ont compté sur le fait que « la plupart de notre matériel fonctionne out of the box ».

Puis l’approvisionnement a remplacé un modèle de NIC pendant une pénurie. Toujours le même vendeur, toujours un chipset « supporté », juste une révision différente.
Soudain, la moitié de la flotte se provisionnait correctement et l’autre moitié n’avait plus de réseau après le premier boot. L’automatisation ne pouvait même pas signaler l’échec
parce que le chemin de reporting était le réseau.

Les ingénieurs ont répondu par le hack classique d’urgence : ajouter une étape ponctuelle qui scp’d un fichier de firmware sur l’hôte pendant le provisioning.
Ça « réparait » le boot initial. Cela a aussi créé un nouveau problème : au prochain update du kernel, le nom du fichier firmware a changé subtilement, l’initramfs ne l’incluait pas,
et les redémarrages sont devenus une roue de roulette. Les images étaient minimales, mais le bazar opérationnel était maximal.

La réparation finale a été de traiter le firmware comme une dépendance plateforme, pas comme du bloat. Ils ont gardé une image compacte, mais ont mis en whitelist
des paquets de firmware spécifiques requis par leur matrice matérielle approuvée, et ont validé le contenu de l’initramfs dans leur CI.
Le minimalisme a survécu. Les hacks non reproductibles non.

Pratique ennuyeuse mais correcte qui a sauvé la mise : redémarrages de staging et capture des logs « bon boot »

Un établissement financier avait un processus de changement conservateur. Pas glamour. Mais ça marche.
Ils maintenaient un environnement de staging avec le même mix NIC/HBA que la production et exigeaient que chaque mise à jour kernel/firmware
passe un test de reboot plus un scrub de stockage et un test de débit réseau soutenu.

Un mois, une mise à jour a introduit une nouvelle exigence de firmware pour une voie fonctionnelle d’un HBA. Sur les systèmes où le paquet firmware était présent,
tout allait bien. Sur les systèmes construits à la main des années auparavant (et ayant dérivé), le paquet manquait.
Staging l’a détecté parce que la mise à jour a déclenché un avertissement initramfs et qu’un contrôle post-reboot a vu des chemins de stockage dégradés.

Le gain n’a pas été un débogage brillant ; c’était de la documentation. Ils avaient un « log de boot doré » pour chaque plateforme qui incluait
les lignes de version de firmware attendues et l’absence d’échecs de chargement. L’on-call pouvait comparer staging/production en quelques minutes.

Ils ont corrigé la dérive en forçant les composants de repo et les paquets de firmware via la gestion de configuration, puis ont regénéré l’initramfs sur la flotte.
La production n’a jamais vu d’incident. La seule victime fut la croyance de quelqu’un que la procédure soignée ne peut coexister avec l’orgueil d’ingénieur.

Erreurs courantes : symptôme → cause racine → correction

1) « L’installateur dit firmware manquant, mais le système boot. Je vais ignorer. »

Symptôme : Le boot réussit, mais la performance NIC est erratique ou le stockage lève des timeouts plus tard.
Cause racine : Le périphérique fonctionne en mode dégradé sans firmware, ou ne plante que sous certaines fonctionnalités/charge.
Correction : Lisez dmesg pour obtenir les noms exacts des firmwares, activez non-free-firmware, installez les bons paquets,
redémarrez et vérifiez les versions de firmware dans les logs.

2) « J’ai ajouté non-free, mais apt ne trouve toujours pas les paquets firmware. »

Symptôme : apt install firmware-… retourne « Unable to locate package ».
Cause racine : Vous avez activé le mauvais composant (non-free au lieu de non-free-firmware), ou vos sources pointent vers la mauvaise suite.
Correction : Assurez-vous que chaque ligne deb inclut non-free-firmware et correspond à votre nom de release ; lancez apt update, puis réessayez.

3) « Le fichier firmware existe, mais dmesg dit toujours qu’il ne peut pas le charger. »

Symptôme : /lib/firmware/… contient le fichier, pourtant les logs montrent des échecs de chargement.
Cause racine : Mauvais nom/chemin pour cette version de pilote, initramfs qui ne le contient pas pour le boot précoce, ou permissions/SELinux-like (rare sur Debian par défaut).
Correction : Confirmez le chemin exact demandé dans dmesg ; vérifiez que le fichier existe à ce chemin précis. Si c’est critique pour le boot, régénérez l’initramfs et assurez-vous qu’il contient le fichier.

4) « Le réseau est mort donc je ne peux pas apt installer le firmware qui répare le réseau. »

Symptôme : Pas d’interface, pas de lien, ou pas de DHCP ; apt ne peut atteindre les miroirs.
Cause racine : Carte unique nécessitant du firmware et vous ne l’avez pas fourni pendant l’installation.
Correction : Utilisez une installation hors-ligne : montez l’ISO Debian, ajoutez-la comme source apt, installez les paquets firmware depuis elle (si présents),
ou utilisez une clé USB/ISO contrôlée avec les .deb requis.

5) « J’ai regénéré initramfs et maintenant le système ne boot plus. »

Symptôme : Le boot tombe sur un shell initramfs ou ne trouve pas root.
Cause racine : Pilote/firmware critique au boot non inclus, ou vous avez modifié des hooks/modules initramfs incorrectement.
Correction : Boot sur un kernel/initramfs précédent depuis GRUB si disponible. Installez les paquets firmware manquants, lancez update-initramfs -u -k all, et conservez au moins une entrée de boot connue bonne.

6) « J’ai mis le pilote en blacklist parce qu’il spammait des erreurs de firmware. »

Symptôme : Les logs sont plus calmes, mais vous n’avez plus de NIC/stockage.
Cause racine : Traiter le symptôme au lieu d’installer le firmware.
Correction : Retirez le blacklist, installez les paquets firmware corrects, et validez le fonctionnement stable. Le logging n’est pas votre ennemi ; c’est votre témoin.

Listes de vérification / plan étape par étape

Checklist A : Correction en ligne (vous avez quand même un réseau fonctionnel)

1. Capturer la preuve :

   cr0x@server:~$ sudo dmesg -T | egrep -i 'firmware|direct firmware|failed to load' | tail -n 80
   [Mon Dec 30 09:12:18 2025] i40e 0000:03:00.0: Direct firmware load for i40e/ddp/ppm.pkg failed with error -2
   

   Décision : Notez le(s) nom(s) exact(s) de fichier. Ne devinez pas.

2. Activer le bon composant de dépôt :

   cr0x@server:~$ sudo editor /etc/apt/sources.list
   

   Décision : Assurez-vous que main contrib non-free-firmware figure sur les lignes concernées.

3. Mettre à jour et installer les paquets de firmware :

   cr0x@server:~$ sudo apt update
   cr0x@server:~$ sudo apt install -y firmware-linux firmware-linux-nonfree firmware-misc-nonfree
   

   Décision : Si un fichier spécifique manque toujours, mappez-le avec apt-file et installez le fournisseur exact.

4. Reconstruire l’initramfs si le stockage/boot précoce en dépend :

   cr0x@server:~$ sudo update-initramfs -u -k all
   

   Décision : Les avertissements concernant le firmware de votre périphérique signifient que vous n’avez pas terminé.

5. Redémarrer et vérifier le chargement du firmware :

   cr0x@server:~$ sudo reboot
   

   cr0x@server:~$ sudo journalctl -b -k | egrep -i 'firmware|failed to load' | tail -n 60
   Dec 30 09:24:02 server kernel: i40e 0000:03:00.0: DDP package loaded successfully
   

   Décision : Absence de lignes « failed to load » et messages explicites de version de firmware : critère de réussite.

Checklist B : Correction hors-ligne (pas de réseau fonctionnel)

Ici beaucoup de guides deviennent vagues. Vous avez besoin d’une approche répétable qui ne dépend pas de l’interface cassée.
Choisissez une option :

• Monter une ISO d’installateur et l’utiliser comme source apt (fonctionne si l’ISO contient ce dont vous avez besoin).
• Utiliser une clé USB contrôlée avec des .deb firmware depuis votre miroir interne.
• Utiliser temporairement une clé USB NIC connue fonctionnelle pour amorcer la vraie NIC (oui, peu glamour ; c’est aussi efficace).

Option 1 : Utiliser une ISO montée comme dépôt

cr0x@server:~$ sudo mkdir -p /mnt/iso
cr0x@server:~$ sudo mount -o ro /dev/sr0 /mnt/iso
cr0x@server:~$ ls /mnt/iso
README.html  dists  doc  install.amd  pool

Ce que ça signifie : L’ISO est montée et contient une structure de dépôt Debian.

Décision : Ajoutez-la à apt et tentez d’installer les paquets firmware depuis elle.

cr0x@server:~$ echo "deb [trusted=yes] file:/mnt/iso trixie main contrib non-free-firmware" | sudo tee /etc/apt/sources.list.d/iso.list
deb [trusted=yes] file:/mnt/iso trixie main contrib non-free-firmware
cr0x@server:~$ sudo apt update
Get:1 file:/mnt/iso trixie InRelease
Reading package lists... Done

Ce que ça signifie : apt peut lire les métadonnées de paquets depuis un média local.

Décision : Installez les paquets firmware. Si apt ne les trouve pas, cette ISO ne contient probablement pas les firmwares nécessaires.

cr0x@server:~$ sudo apt install -y firmware-linux firmware-linux-nonfree firmware-misc-nonfree
Reading package lists... Done
Building dependency tree... Done
Selecting previously unselected package firmware-linux-nonfree.
Setting up firmware-linux-nonfree (20250801-1) ...

Option 2 : Installer des .deb firmware depuis une clé USB (bundle contrôlé)

cr0x@server:~$ sudo mount /dev/sdb1 /mnt
cr0x@server:~$ ls /mnt
firmware-linux-nonfree_20250801-1_all.deb
firmware-misc-nonfree_20250801-1_all.deb
firmware-linux_20250801-1_all.deb

Ce que ça signifie : Vous avez les paquets localement.

Décision : Installez via dpkg, puis corrigez les dépendances avec apt si possible (depuis l’ISO ou plus tard le réseau).

cr0x@server:~$ sudo dpkg -i /mnt/firmware-linux-nonfree_20250801-1_all.deb /mnt/firmware-misc-nonfree_20250801-1_all.deb /mnt/firmware-linux_20250801-1_all.deb
Selecting previously unselected package firmware-linux-nonfree.
Unpacking firmware-linux-nonfree (20250801-1) ...
Setting up firmware-linux-nonfree (20250801-1) ...

Décision : Après l’installation, regénérez l’initramfs si nécessaire et redémarrez.

Checklist C : Vérifier et verrouiller (pour éviter la régression)

1. Confirmer l’absence d’échecs de firmware au démarrage :

   cr0x@server:~$ sudo journalctl -b -k | egrep -i 'Direct firmware load|failed to load' || true
   

   Décision : Une sortie vide est bonne. Toute ligne ici nécessite une action.

2. Vérifier la propriété des paquets (pas de blobs mystères) :

   cr0x@server:~$ dpkg -S /lib/firmware/i40e/ddp/ppm.pkg
   firmware-misc-nonfree: /lib/firmware/i40e/ddp/ppm.pkg
   

   Décision : Si dpkg n’appartient pas à un fichier firmware, vous avez un artefact non géré. Décidez de le remplacer par un firmware packagé.

3. S’assurer que l’initramfs contient le firmware nécessaire (chemins boot-critiques) :

   cr0x@server:~$ lsinitramfs /boot/initrd.img-$(uname -r) | grep -E 'mpt3sas/|i40e/'
   usr/lib/firmware/i40e/ddp/ppm.pkg
   usr/lib/firmware/mpt3sas/mpi3mr.fw
   

   Décision : Si le firmware est requis avant le montage du root et qu’il manque ici, regénérez l’initramfs et investiguez hooks/modules.

FAQ

1) Pourquoi Debian installe-t-il sans le firmware dont j’ai manifestement besoin ?

Parce que la position par défaut de Debian est conservatrice quant à ce qui entre dans « main », et le licensing du firmware ne le rend souvent pas éligible.
Selon l’image de l’installateur et vos choix, vous pouvez vous retrouver sans paquets de firmware même si le pilote kernel est présent.

2) Est-ce que l’activation de non-free-firmware suffit, ou ai-je besoin de non-free aussi ?

Pour le firmware en particulier, non-free-firmware est le composant clé. Vous pouvez vouloir contrib pour certaines relations de packaging,
mais non-free n’est nécessaire que si vous voulez d’autres logiciels non-libres au-delà du firmware.

3) L’installateur a averti d’un firmware manquant, mais mon NIC fonctionne maintenant. Dois-je m’en préoccuper ?

Oui. L’avertissement signifie généralement « un pilote a demandé quelque chose et ne l’a pas obtenu ». Parfois le périphérique fonctionne en mode fallback ; parfois il échoue plus tard.
Vérifiez journalctl -b -k pour les échecs de chargement de firmware et résolvez-les de manière intentionnelle.

4) Puis-je simplement télécharger le fichier firmware et le placer dans /lib/firmware ?

Vous pouvez, mais vous prenez en charge la gestion du cycle de vie : mises à jour, provenance, audit et inclusion dans l’initramfs quand c’est nécessaire.
En production, préférez les paquets Debian sauf si vous êtes air-gapped et gérez un bundle interne approuvé.

5) Pourquoi dois-je regénérer l’initramfs ? J’ai déjà installé le paquet.

Si le périphérique a besoin du firmware avant le montage du root (cas fréquent pour les contrôleurs de stockage qui hébergent root), le blob doit être présent dans l’initramfs.
Installer un paquet le place simplement sur le disque, pas dans l’image initramfs déjà générée.

6) Comment savoir quel paquet contient mon fichier firmware manquant ?

Utilisez apt-file search sur le nom de fichier rapporté dans dmesg. C’est le mappage le plus rapide et précis de « fichier manquant » vers « installer ce paquet ».

7) Après avoir installé le firmware, dois-je redémarrer ?

Souvent oui. Les pilotes chargent généralement le firmware lors de l’initialisation du périphérique. Vous pouvez parfois recharger le module pour un NIC,
mais pour les HBAs et les chemins de stockage, redémarrer est plus sûr et souvent plus rapide que déboguer un contrôleur partiellement réinitialisé.

8) Et si je suis sur un serveur distant sans hors-bande et que la seule NIC a besoin de firmware ?

Vous êtes dans un coin d’architecture dangereux. Pratiquement : utilisez une NIC USB temporaire (si vous pouvez y accéder physiquement),
ou démarrez depuis un média de secours incluant le firmware, ou organisez un accès hors-bande pour l’avenir.
Opérationnellement : ne déployez pas de serveurs sans un chemin de reprise pour l’amorçage réseau.

9) Est-ce un bug du kernel ou un bug Debian ?

Habituellement ni l’un ni l’autre. C’est un problème de packaging/disponibilité de dépôt combiné à la conception matérielle moderne.
Vous confirmez en vérifiant : le pilote est présent et lié, le firmware est demandé, le fichier est absent. Ce n’est pas un bug ; c’est une dépendance manquante.

Conclusion : étapes suivantes pour réduire la douleur future

Corriger un « firmware manquant » sur Debian 13 n’est pas difficile. Le faire d’une manière qui ne vous mordra pas plus tard est le vrai travail.
La recette est cohérente : identifiez le périphérique et le nom de fichier de firmware demandé, activez non-free-firmware, installez
le paquet approprié, regénérez l’initramfs si le boot précoce le requiert, redémarrez, et vérifiez dans les logs.

Étapes que je ferais réellement sur une flotte :

• Standardiser les composants apt (inclure non-free-firmware) via la gestion de configuration.
• Ajouter un contrôle de commissioning qui échoue si journalctl -b -k contient des échecs de chargement de firmware.
• Enregistrer les versions de firmware « bon boot » par modèle de plateforme pour repérer facilement les régressions.
• S’assurer d’un chemin d’amorçage hors-ligne (dépôt ISO, miroir interne, ou accès hors-bande) avant d’en avoir besoin.

Vous n’avez pas besoin d’héroïsme. Vous avez besoin de mécanismes reproductibles et de la discipline de croire vos logs.