Debian 13: Firmware faltante tras la instalación — Soluciona el soporte de NIC y HBA de forma correcta

Qué está pasando realmente (y por qué Debian actúa así)

“Firmware faltante” en Debian casi nunca significa que falte el controlador del kernel. Significa que el controlador se cargó, intentó inicializar
el hardware y luego solicitó un archivo de firmware desde el espacio de usuario (típicamente vía udev/systemd-udevd) desde
/lib/firmware. El controlador está presente; el blob de microcódigo no lo está.

En las NICs y HBAs modernas, el firmware no es una decoración opcional. Es la forma en que el dispositivo activa el entrenamiento de enlace, los motores de offload, la gestión de colas,
el comportamiento del PHY y, a veces, la capacidad completa de enumerar o reiniciarse correctamente. Muchos controladores se acoplan sin firmware,
pero expondrán un “netdev” que nunca estampa enlace, o un HBA que muestra presencia PCIe pero no logra poner en marcha los phys SAS/SATA.

Debian históricamente separó el software “libre” de los paquetes de firmware “no-libres”. Es una decisión de política con consecuencias técnicas:
el instalador y las fuentes apt por defecto pueden no incluir los paquetes de firmware que necesitas para arrancar con red o almacenamiento.
Debian 12 introdujo non-free-firmware como un componente de repositorio de primera clase, lo que ayudó, pero las actualizaciones, las imágenes personalizadas
y las instalaciones mínimas aún pueden dejarte en el purgatorio del firmware.

La solución correcta no es “copiar un archivo al azar en /lib/firmware una vez y olvidarlo.” La solución correcta es:
instalar los paquetes de firmware Debian adecuados (para obtener actualizaciones, hashes y seguimiento de dependencias),
asegurarte de que estén disponibles en el initramfs si es necesario,
y verificar que el dispositivo realmente cargó el firmware después del reinicio.

Una regla operativa: si la máquina necesita el firmware para acceder a la red que provee el firmware, necesitas un camino fuera de banda.
Eso puede ser soporte físico, un mirror local, una segunda NIC que funcione, o IPMI/iKVM con una ISO montada. Si te ríes,
es porque ya has estado allí.

Broma #1: El firmware es como el café: todo el mundo finge que puede operar sin él hasta que la producción empieza a hacer preguntas.

Algunos hechos e historia que vale la pena conocer

• La carga de firmware pasó de “caso marginal” a comportamiento por defecto: muchos dispositivos PCIe traen ROMs mínimas y dependen de blobs cargados por el SO para funciones y correcciones.
• Linux usa un mecanismo estándar de petición: los controladores llaman a request_firmware() y el kernel pide al espacio de usuario proveer el archivo desde /lib/firmware.
• La división de repositorios de Debian es impulsada por política: históricamente “main” se mantuvo libre; el firmware a menudo no calificaba, por eso vivía en “non-free”.
• Debian 12 introdujo non-free-firmware: los paquetes de firmware se movieron a un componente dedicado para hacer las instalaciones menos dolorosas sin mezclar todo en “non-free”.
• El comportamiento del instalador depende de la imagen: algunos ISOs del instalador incluyen firmware; otros intencionalmente no. Mismo instalador, diferente resultado.
• El firmware de NICs suele afectar enlace y offloads: puedes ver la interfaz pero seguir sin carrier, con enlace inestable o comportamiento extraño de checksum/TSO.
• Firmware de HBA y controladores del kernel son capas separadas: el dispositivo PCIe puede enumerarse, pero el transporte SAS nunca arrancará si el firmware no se carga o es incompatible.
• Initramfs importa para almacenamiento crítico de arranque: si tu sistema raíz está detrás de un HBA que necesita firmware, el blob debe estar temprano (dentro del initramfs), no solo después del montaje de root.
• Los paquetes de firmware se actualizan también por seguridad: no es solo “hacer que el dispositivo funcione”, sino también “evitar distribuir microcódigo/firmware antiguo y vulnerable”.

Guion rápido de diagnóstico

Cuando la caja no tiene red o almacenamiento después de la instalación, no tienes tiempo para folclore. Ejecuta esta secuencia y para cuando tengas una
señal decisiva.

Primero: confirma que el kernel ve el hardware

• ¿PCIe visible? Si lspci no muestra el dispositivo, esto no es un problema de paquetes de firmware. Piensa en ajustes del BIOS, alimentación del slot, bifurcación, riser roto o tarjeta muerta.
• ¿Controlador enlazado? Si el dispositivo es visible pero no tiene controlador, estás en terreno de “falta driver/module”, no de “falta firmware”.

Segundo: busca peticiones y fallos de firmware

• dmesg dice la verdad: busca “firmware”, “Direct firmware load failed” o “failed to load”. Eso te da el nombre exacto de archivo que el controlador solicita.
• Mapa de nombre de archivo a paquete: los paquetes Debian colocan archivos bajo /lib/firmware. Si el archivo no existe, instala el paquete que lo proporciona.

Tercero: decide si esto necesita initramfs

• ¿Root en ese dispositivo? Si el firmware faltante afecta al dispositivo que provee root (HBA, NVMe detrás de un controlador, etc.), debes asegurarte de que el firmware llegue al initramfs y regenerarlo.
• ¿NIC no-root? Para una NIC, usualmente initramfs no es necesario a menos que hagas netboot, uses root iSCSI o necesites red en arranque temprano para desbloqueos remotos.

Cuarto: arregla la configuración del repo antes de “arreglar firmware”

• Habilita non-free-firmware: no introduzcas blobs a mano a menos que estés air-gapped y seas disciplinado al respecto.
• Actualizar, instalar, reconstruir initramfs, reiniciar: hazlo una vez, hazlo limpio, y luego verifica con los logs.

Tareas prácticas: comandos, salidas y decisiones (12+)

Task 1: Identifica el hardware exacto (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]

Qué significa: El kernel puede ver tanto la NIC como el HBA a nivel PCIe. Bien.
Los IDs entre corchetes (8086:1572, 1000:0087) son tu verdad fundamental.

Decisión: Si tu dispositivo no aparece aquí, deja de perseguir paquetes de firmware. Revisa BIOS/UEFI, asientos, alimentación y topología PCIe.

Task 2: Comprueba qué controlador está enlazado (o no)

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

Qué significa: La NIC está usando i40e, así que el controlador existe y está enlazado.

Decisión: Si falta “Kernel driver in use”, puede que necesites un kernel diferente, un módulo, o corregir Secure Boot/firmado de módulos—no es un problema de firmware.

Task 3: Encuentra errores de firmware en el log del 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)

Qué significa: El error -2 es “archivo no encontrado.” El controlador está pidiendo nombres de archivo específicos.

Decisión: Necesitas paquetes que provean /lib/firmware/i40e/ddp/ppm.pkg y /lib/firmware/mpt3sas/mpi3mr.fw, o al menos el conjunto correcto para la generación de tu hardware.

Task 4: Confirma que el archivo de firmware falta (no asumas)

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

Qué significa: No está presente. Esto todavía no es un “bug del controlador”. Es un archivo faltante.

Decisión: Arregla las fuentes de apt e instala los paquetes de firmware apropiados. Evita descargas manuales salvo que tengas un bundle controlado y auditado.

Task 5: Inspecciona los componentes de apt (¿está activado non-free-firmware?)

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

Qué significa: Solo main está habilitado. Los paquetes de firmware comúnmente viven en non-free-firmware.

Decisión: Añade non-free-firmware (y normalmente contrib) a las mismas líneas.

Task 6: Actualiza fuentes de forma segura (edita una vez, no improvises)

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

Qué significa: Has habilitado el componente que realmente contiene el firmware que necesitas.

Decisión: Ahora apt debería poder ver paquetes de firmware. Si aún no tienes red, necesitarás una vía offline—sigue leyendo.

Task 7: Refresca metadata de apt y busca paquetes 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.

Qué significa: Los repos son alcanzables y apt actualizó su metadata.

Decisión: Si apt no puede alcanzar los repos porque tu única NIC necesita firmware, pasa a los pasos de instalación offline en la sección de listas de comprobación.

Task 8: Instala el paquete general de firmware (a menudo suficiente)

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) ...

Qué significa: Estos paquetes meta cubren una gran porción de blobs comunes. En NICs y HBAs de servidor, esto a menudo soluciona las cosas inmediatamente.

Decisión: Si aún te falta un nombre de archivo específico en dmesg, puede que necesites un paquete más enfocado. Verifica a continuación.

Task 9: Encuentra qué paquete provee un archivo de firmware específico

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

Qué significa: apt-file mapea nombres de archivo a paquetes. Esta es la manera limpia de resolver discusiones rápidamente.

Decisión: Instala el/los paquete(s) identificados. Si estás en un entorno mínimo sin apt-file, usa dpkg -S después de instalar los bundles de firmware probables.

Task 10: Reconstruye initramfs cuando el almacenamiento esté involucrado

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

Qué significa: La generación de initramfs advierte cuando un módulo podría necesitar firmware que no está incluido.
Es una pista, no el evangelio—algunas advertencias son conservadoras.

Decisión: Si sigue advirtiendo sobre el archivo exacto que viste en dmesg, no has instalado el paquete correcto aún (o el nombre del firmware difiere según la generación del hardware).

Task 11: Verifica que el archivo de firmware ahora exista

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

Qué significa: El archivo está presente. El controlador puede cargarlo en el próximo reinicio o al resetear el dispositivo.

Decisión: Reinicia si se trata de un dispositivo crítico para el arranque, o descarga/carga el módulo si es seguro (usualmente es más seguro reiniciar en servidores).

Task 12: Confirma que la NIC realmente sube y enlaza

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>

Qué significa: La interfaz existe. Está DOWN. Eso puede ser administrativo (no levantada) o físico (sin carrier).

Decisión: Súbela y comprueba el carrier; si no hay carrier, revisa ópticas, puerto del switch y logs del firmware/controlador.

Task 13: Sube la interfaz y comprueba carrier + velocidad

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

Qué significa: El enlace está arriba a 10G, lo que sugiere firmemente que la situación del firmware de la NIC está resuelta (al menos lo suficiente para funcionar).

Decisión: Si Link detected: no, no culpes de inmediato al firmware. Revisa compatibilidad de ópticas/DAC, configuración del switch y dmesg por resets repetidos.

Task 14: Confirma que el HBA está enumerando dispositivos

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

Qué significa: La capa SCSI ve discos. Tu HBA no solo está presente; es funcional.

Decisión: Si no aparece nada, revisa dmesg por fallos de carga de firmware del HBA o enlace caído en los phys.

Task 15: Verifica mensajes de firmware del módulo tras el reinicio

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

Qué significa: Este es el estado de éxito: líneas explícitas de versión de firmware y sin spam de “failed to load”.

Decisión: Captura estos logs en tus notas de construcción/puesta en servicio. En la próxima actualización del kernel, si algo falla, sabrás cómo “se veía bien”.

Arréglalo de la manera correcta: repositorios, paquetes e initramfs

1) Prefiere firmware empaquetado sobre copiar archivos manualmente

Copiar un blob a /lib/firmware funciona—hasta que no. Evita la propiedad dpkg, complica la auditoría y
rompe silenciosamente en una reinstalación porque nadie recuerda el archivo artesanal que hiciste scp a las 2 a.m.

El enfoque empaquetado te da:
actualizaciones versionadas,
checksums desde el archivo,
ubicaciones de archivo previsibles,
y una eliminación limpia si estás construyendo imágenes mínimas.

2) Habilita explícitamente non-free-firmware

En Debian 13, el valor sensato para hardware real es main contrib non-free-firmware para los repositorios base.
Puedes mantener non-free desactivado si quieres; el firmware está separado por una razón.

Si gestionas flotas, no dejes esto al azar. Insértalo en tu aprovisionamiento (preseed/autoinstall, imágenes doradas, gestión de configuración).

3) Instala los paquetes de firmware adecuados

Empieza con los conjuntos comunes:
firmware-linux,
firmware-linux-nonfree,
firmware-misc-nonfree.
Estos cubren mucho: piezas de NIC Intel, Realtek, varios firmwares de controladoras y cargas útiles parecidas a microcódigo.

Luego ve a lo específico. Usa el nombre de archivo de dmesg y mapea a un paquete mediante apt-file search.
Eso te mantiene honesto y evita el hábito de “instalar 600MB de firmware porque falta un archivo”.

4) Decide si initramfs necesita el firmware

Aquí está la línea divisoria: si el firmware es necesario antes de que se monte el filesystem root, debe estar en initramfs.
Los controladores de almacenamiento para discos root son el caso clásico. También lo son las NICs con root iSCSI y el networking para desbloqueo remoto en arranque temprano.

La herramienta initramfs de Debian generalmente incluye firmware referenciado por los módulos incluidos, pero existen casos límite:
módulos que se cargan más tarde, solicitudes de firmware después de un reset, o cambios de nombre de firmware entre versiones de kernel.
Si ves advertencias durante update-initramfs, trátalas como un aviso para verificar, no como ruido de fondo.

5) Reinicia deliberadamente (o resetea el dispositivo limpiamente)

El firmware se carga cuando el controlador inicializa el dispositivo. A veces puedes desencadenarlo con una recarga del módulo.
En servidores, un reinicio limpio suele ser la operación más barata, especialmente cuando está involucrado el almacenamiento.
“Vamos a rmmod el controlador del HBA en el root vivo” es el tipo de desarrollo profesional que ocurre inesperadamente.

Cita (idea parafraseada) de Gene Kim: los equipos operativos de alto desempeño reducen fallos haciendo el trabajo visible y repetible, no heroico.

Especificaciones NIC y HBA: qué falla y cómo se ve

NICs: el dispositivo está, pero la red no

Las fallas de firmware en NICs tienden a presentarse de tres maneras:

• Interfaz ausente: raro para “firmware faltante”, más común para problemas de driver/module o PCI.
• Interfaz presente, sin carrier: blob de firmware o problemas de configuración del PHY; también incompatibilidad de ópticas/DAC.
• Interfaz funciona pero es inestable: resets repetidos en dmesg, enlace oscilante, rarezas en checksum offload, o colapso de rendimiento bajo carga.

El hábito más productivo: cuando la red está rota, siempre extrae las líneas de dmesg alrededor del nombre del controlador. En NICs Intel de servidor,
a menudo verás una petición de paquetes DDP o mensajes relacionados con NVM. En Broadcom, verás nombres de firmware bnx2/bnx2x.
En Realtek, verás cargas útiles específicas rtl_nic/.

HBAs: el arranque puede funcionar, luego el almacenamiento se desmorona (o nunca aparece)

Los HBAs son donde los errores de firmware se vuelven caros porque se acoplan directamente a la disponibilidad de datos.
Puedes tener un SO perfectamente instalado y aun así ver cero discos si el microcódigo del HBA no puede cargarse o la combinación controlador/firmware está desajustada.

Modos de fallo que realmente verás:

• PCIe se enumera, no hay hosts SCSI: el controlador se carga pero no puede inicializarse sin firmware.
• Host SCSI existe, no hay targets: el controlador se inicializa pero no puede levantar los phys; a veces cableado/backplane, a veces firmware.
• Los targets aparecen intermitentemente: resets, timeouts, tormentas de abortos de comando; podría ser firmware, cables SAS marginales o peculiaridades de expander/backplane.

En HBAs, trata el firmware como parte de la compatibilidad, no solo como un blob que necesitas una vez. Las actualizaciones del kernel pueden cambiar expectativas del controlador,
y los proveedores ocasionalmente envían firmware que “funciona” hasta que llegas a una profundidad de cola o ruta de recuperación de errores específica.

Broma #2: Lo único más permanente que un parche temporal es un parche de almacenamiento que alguien olvidó documentar.

Tres micro-historias corporativas (todas plausibles en el mundo real)

Incidente causado por una suposición errónea: “La interfaz existe, así que el firmware debe estar bien”

Una compañía mediana desplegó Debian en una nueva tanda de servidores con NICs de 10G de doble puerto. La automatización tipo kickstart (sí, Debian también puede automatizarse)
verificó que ip link mostraba los nombres de interfaz esperados y luego procedió a configurar VLANs, bonds y enrutamiento.
La prueba de aceptación fue simple: “interfaz presente” y “MAC coincide con el inventario.”

La primera semana todo parecía normal—hasta que el tráfico aumentó. Bajo carga sostenida, la NIC se reiniciaba, rompía el bond y se recuperaba.
El monitoreo lo vio como pérdida ocasional de paquetes y picos de latencia extraños. El equipo de red culpó al switch. El equipo de servidores culpó al
equipo de red, como es tradición. Nadie quería mirar dmesg porque la caja “obviamente tenía una NIC.”

Los logs del kernel contaron otra historia: el controlador operaba sin un paquete DDP y repetidamente caía en fallback. No era una situación binaria
“funciona/no funciona”. Era “funciona hasta que le pides lo que compraste.”
El firmware faltante no impedía la enumeración; impedía que la NIC usara la vía de datos correcta y se comportara de forma consistente.

La reparación fue aburrida: habilitar non-free-firmware, instalar el paquete correcto de firmware, reiniciar y luego actualizar la prueba de aceptación.
La nueva prueba exigía “link up”, “sin fallos de carga de firmware” y “sin resets bajo una prueba de carga sintética.”
Mismo hardware. Mismo kernel. Diferente resultado porque dejaron de asumir.

Optimización que salió mal: imágenes mínimas y pureza de “sin paquetes extra”

Otra organización construyó imágenes Debian mínimas para despliegues edge. El objetivo era sensato: reducir la superficie de ataque, reducir el churn de parches, mantener imágenes pequeñas.
Eliminaron agresivamente paquetes “innecesarios”, incluidos bundles de firmware, y confiaron en que “la mayoría de nuestro hardware funciona out of the box.”

Entonces el procurement cambió un modelo de NIC durante una escasez de suministros. Sigue siendo el mismo proveedor, mismo chipset “soportado”, solo una revisión diferente.
De repente, la mitad de la flota se aprovisionó bien y la otra mitad no mostró red tras el primer arranque. La automatización ni siquiera pudo reportar el fallo
porque la ruta de reporte era la red.

Los ingenieros respondieron con el clásico parche de emergencia: añadir un paso único que scp un archivo de firmware al host durante el aprovisionamiento.
“Arregló” el arranque inicial. También creó un nuevo problema: en la siguiente actualización del kernel, el nombre del firmware cambió sutilmente, el initramfs
no lo incluyó y reiniciar se convirtió en una ruleta. Las imágenes eran mínimas, pero el lío operacional fue máximo.

La reparación eventual fue tratar el firmware como dependencia de plataforma, no como bloat. Aún mantenían la imagen acotada, pero
incluyeron en una whitelist paquetes de firmware específicos requeridos por su matriz de hardware aprobada, y validaron el contenido del initramfs como parte del CI.
El minimalismo sobrevivió. Los hacks irreproducibles no.

Práctica aburrida pero correcta que salvó el día: reinicios por etapas y capturar logs de “arranque bueno”

Una empresa de servicios financieros tenía un proceso de cambios conservador. No glamouroso. Pero funcionó.
Mantenían un entorno de staging con la misma mezcla de NIC/HBA que la producción y requerían que cada actualización de kernel/firmware
pasara una prueba de reinicio más un scrub de almacenamiento y una prueba de throughput de red sostenida.

Un mes, una actualización introdujo un nuevo requisito de firmware para una ruta de features del HBA. En sistemas donde el paquete de firmware estaba presente,
todo estuvo bien. En sistemas que se habían construido a mano años antes (y habían derivado), faltaba el paquete.
Staging lo atrapó porque la actualización disparó una advertencia en initramfs y una comprobación post-reinicio vio rutas de almacenamiento degradadas.

La victoria no fue una depuración ingeniosa; fue documentación. Tenían un “log de arranque dorado” por plataforma que incluía
las versiones de firmware esperadas y la ausencia de fallos de firmware. El on-call pudo comparar staging/producción en minutos.

Arreglaron la deriva imponiendo componentes de repo y paquetes de firmware vía gestión de configuración, luego reconstruyeron initramfs en toda la flota.
Producción nunca vio una caída. La única víctima fue la creencia de alguien de que el proceso cuidadoso no puede coexistir con el orgullo ingenieril.

Errores comunes: síntoma → causa raíz → arreglo

1) “El instalador dice que falta firmware, pero el sistema arranca bien. Lo ignoraré.”

Síntoma: El arranque tiene éxito, pero el rendimiento de la NIC es errático o el almacenamiento muestra timeouts posteriormente.
Causa raíz: El dispositivo funciona en modo degradado sin firmware, o solo falla bajo ciertas funciones/cargas.
Arreglo: Lee dmesg para los nombres exactos de firmware, habilita non-free-firmware, instala los paquetes correctos, reinicia y verifica las versiones de firmware en los logs.

2) “Añadí non-free, pero apt aún no encuentra paquetes de firmware.”

Síntoma: apt install firmware-… dice “Unable to locate package”.
Causa raíz: Habilitaste el componente equivocado (non-free en vez de non-free-firmware), o tus fuentes apuntan a la suite equivocada.
Arreglo: Asegura que cada línea deb incluya non-free-firmware y coincida con tu nombre de release; ejecuta apt update, luego reintenta.

3) “El archivo de firmware existe, pero dmesg aún dice que no puede cargarlo.”

Síntoma: /lib/firmware/… contiene el archivo, sin embargo el log muestra fallos de carga.
Causa raíz: Nombre/ruta incorrectos para esa versión de controlador, initramfs sin incluirlo para arranque temprano, o permisos/SELinux-like (raro en Debian por defecto).
Arreglo: Confirma la ruta exacta solicitada en dmesg; verifica que el archivo exista en esa ruta exacta. Si es crítico para el arranque, reconstruye initramfs y asegúrate que lo contenga.

4) “La red está muerta así que no puedo apt install el firmware que arregla la red.”

Síntoma: Sin interfaz, sin enlace, o sin DHCP; apt no alcanza mirrors.
Causa raíz: La NIC única necesita firmware y no lo proveíste durante la instalación.
Arreglo: Usa instalación offline: monta la ISO de Debian, añádela como fuente apt, instala paquetes de firmware desde ella (si están presentes), o usa un USB/ISO controlado con los .deb necesarios.

5) “Reconstruí initramfs y ahora el sistema no arranca.”

Síntoma: El arranque cae a la shell del initramfs o no encuentra root.
Causa raíz: Controlador/firmware crítico para el arranque no incluido, o cambiaste hooks/módulos de initramfs incorrectamente.
Arreglo: Arranca el kernel/initramfs previo desde GRUB si está disponible. Instala los paquetes de firmware faltantes, ejecuta update-initramfs -u -k all, y conserva al menos una entrada de arranque conocida buena.

6) “Blacklisté el controlador porque estaba spameando errores de firmware.”

Síntoma: El log está más tranquilo, pero ahora no tienes NIC/almacenamiento.
Causa raíz: Tratar el síntoma en vez de instalar firmware.
Arreglo: Quita la blacklist, instala los paquetes de firmware correctos y valida operación estable. El logging no es tu enemigo; es tu testigo.

Listas de comprobación / plan paso a paso

Lista A: Arreglo online (aún tienes red funcional de alguna forma)

1. Captura la evidencia:

   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
   

   Decisión: Anota el/los nombre(s) exacto(s) de archivo. No adivines.

2. Habilita el componente de repositorio correcto:

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

   Decisión: Asegura que main contrib non-free-firmware exista en las líneas relevantes.

3. Actualiza e instala paquetes de firmware:

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

   Decisión: Si falta un archivo específico, mapea con apt-file e instala el proveedor exacto.

4. Reconstruye initramfs si el arranque/almacenamiento depende de ello:

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

   Decisión: Las advertencias sobre el firmware de tu dispositivo significan que no has terminado.

5. Reinicia y verifica que el firmware se cargó:

   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
   

   Decisión: Ausencia de líneas “failed to load” y mensajes explícitos de versión de firmware es tu criterio de éxito.

Lista B: Arreglo offline (sin red funcional)

Aquí es donde muchas guías son vagas. Necesitas un enfoque repetible que no dependa de la interfaz rota.
Elige uno:

• Monta una ISO del instalador y úsala como fuente apt (funciona si la ISO contiene lo que necesitas).
• Usa un USB controlado con paquetes .deb de firmware desde tu mirror interno.
• Temporalmente usa una NIC USB conocida que funcione para bootstrappear la NIC real (sí, no es glamouroso; también es efectivo).

Opción 1: Usa una ISO montada como repositorio

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

Qué significa: La ISO está montada y contiene la estructura de repositorio Debian.

Decisión: Añádela a apt e intenta instalar firmware desde ella.

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

Qué significa: apt puede leer metadata de paquetes desde el medio local.

Decisión: Instala paquetes de firmware. Si apt no los encuentra, es probable que la ISO no incluya los paquetes necesarios.

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) ...

Opción 2: Instalar paquetes .deb de firmware desde USB (bundle controlado)

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

Qué significa: Tienes los paquetes localmente.

Decisión: Instálalos con dpkg, luego arregla dependencias con apt si es posible (desde ISO o red después).

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) ...

Decisión: Tras instalar, reconstruye initramfs si es necesario y reinicia.

Lista C: Verificar y consolidar (para que no regrese)

1. Confirma ausencia de fallos de firmware al arrancar:

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

   Decisión: Salida vacía es buena. Cualquier línea aquí requiere acción.

2. Comprueba propiedad de paquetes (sin blobs misteriosos):

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

   Decisión: Si dpkg no posee un archivo de firmware, tienes un artefacto no gestionado. Decide si reemplazarlo por firmware empaquetado.

3. Asegúrate de que initramfs contenga el firmware necesario (rutas críticas de arranque):

   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
   

   Decisión: Si el firmware es requerido antes del montaje de root y falta aquí, reconstruye initramfs e investiga hooks/módulos.

Preguntas frecuentes

1) ¿Por qué Debian instala sin el firmware que obviamente necesito?

Porque la postura por defecto de Debian es conservadora sobre lo que entra en “main”, y las licencias de firmware a menudo no califican.
Dependiendo de la imagen del instalador y tus elecciones, puedes quedarte sin paquetes de firmware aunque el controlador del kernel esté presente.

2) ¿Es suficiente habilitar non-free-firmware, o necesito non-free también?

Para firmware específicamente, non-free-firmware es el componente clave. Puede que aún quieras contrib para algunas relaciones de empaquetado,
pero no necesitas non-free a menos que quieras otro software no libre más allá del firmware.

3) El instalador advirtió sobre firmware faltante, pero mi NIC funciona ahora. ¿Debería seguir preocupándome?

Sí. La advertencia normalmente significa “un controlador solicitó algo y no lo obtuvo.” A veces el dispositivo funciona en modo fallback; otras veces falla después.
Revisa journalctl -b -k por fallos de carga de firmware y resuélvelos intencionalmente.

4) ¿Puedo simplemente descargar el archivo de firmware y colocarlo en /lib/firmware?

Puedes, pero estás asumiendo la gestión del ciclo de vida: actualizaciones, procedencia, auditoría y asegurar que initramfs lo incluya cuando sea necesario.
En producción, prefiere paquetes Debian de firmware a menos que estés air-gapped y gestiones un bundle interno vetado.

5) ¿Por qué necesito reconstruir initramfs? Ya instalé el paquete.

Si el dispositivo necesita firmware antes de que se monte el filesystem root (común para controladoras de almacenamiento que alojan root), el blob debe estar disponible en initramfs.
Instalar un paquete solo garantiza que está en disco, no en la imagen initramfs ya generada.

6) ¿Cómo sé qué paquete contiene mi archivo de firmware faltante?

Usa apt-file search contra el nombre de archivo reportado en dmesg. Esa es la forma más rápida y precisa de mapear “archivo faltante” a “instala este paquete.”

7) Después de instalar firmware, ¿necesito reiniciar?

A menudo sí. Los controladores típicamente cargan firmware durante la inicialización del dispositivo. A veces puedes recargar el módulo para una NIC,
pero en HBAs y rutas de almacenamiento es más seguro reiniciar y por lo general más rápido que depurar un controlador medio reseteado.

8) ¿Qué pasa si estoy en un servidor remoto sin acceso fuera de banda y la única NIC necesita firmware?

Estás en una mala esquina arquitectónica. Prácticamente: usa una NIC USB temporal (si puedes acceder físicamente),
o arranca desde medios de rescate que incluyan el firmware, o gestiona acceso fuera de banda para el futuro.
Operacionalmente: no despliegues servidores sin una vía recuperable para el bootstrap de red.

9) ¿Esto es un bug del kernel o un bug de Debian?

Usualmente ninguno de los dos. Es un tema de empaquetado/disponibilidad en repositorios más el diseño de hardware moderno. Confirmas revisando:
el controlador está presente y enlazado, se solicita el archivo de firmware, el archivo de firmware está ausente. Eso no es un bug; es una dependencia faltante.

Conclusión: siguientes pasos para reducir dolores futuros

Arreglar “firmware faltante” en Debian 13 no es difícil. Hacerlo de una manera que no te muerda después es el verdadero trabajo.
La receta es consistente: identifica el dispositivo y el nombre de archivo de firmware solicitado, habilita non-free-firmware, instala
el paquete apropiado, reconstruye initramfs si lo necesita el arranque temprano, reinicia y verifica en los logs.

Pasos siguientes que yo realmente haría en una flota:

• Estandarizar componentes apt (incluir non-free-firmware) vía gestión de configuración.
• Añadir una comprobación de puesta en servicio que falle si journalctl -b -k contiene fallos de carga de firmware.
• Registrar las versiones de firmware de “arranque bueno” por modelo de plataforma para que las regresiones sean fáciles de detectar.
• Asegurar una ruta bootstrap offline (ISO repo, mirror interno o acceso fuera de banda) antes de que la necesites.

No necesitas heroísmos. Necesitas mecánicas repetibles y la disciplina para creer en tus logs.