Ubuntu 24.04: Actualizaciones rompieron módulos — Reconstruir initramfs correctamente (Caso #88)

enero 28, 2026 • febrero 3, 2026 • Lectura: 25 min • Views: 8

¿Te fue útil?

Aplicas parches a Ubuntu, reinicias como una persona responsable y la máquina te recompensa con un prompt de initramfs, NICs ausentes o un sistema raíz que de repente “no existe”.
Bienvenido al caso #88: la actualización no “rompió Linux”. Rompió el contrato entre tu kernel, tus módulos y el initramfs que debe unirlos durante el arranque.

La solución suele ser aburrida: reconstruir initramfs correctamente, para el kernel que realmente estás arrancando, con los módulos que realmente necesitas, y sin engañarte sobre Secure Boot, DKMS o ZFS.
El truco es hacerlo con la disciplina suficiente para que permanezca arreglado tras la siguiente actualización.

Lo que realmente se rompió: la cadena de arranque y el contrato de módulos

En Ubuntu 24.04, la clásica historia del initramfs sigue aplicando: GRUB carga un kernel (vmlinuz) y una imagen initramfs (initrd.img).
El initramfs es un pequeño sistema raíz en RAM que contiene early userspace, scripts y un conjunto seleccionado de módulos del kernel necesarios para localizar y montar el sistema raíz real.

Cuando una actualización “rompe módulos”, rara vez es que el kernel haya olvidado hacer su trabajo. Usualmente es una de estas:

Estás arrancando un kernel distinto al que crees (el valor por defecto de GRUB cambió, se eliminó el kernel antiguo o se escogió una entrada de fallback).
Tu initramfs no coincide con tu kernel (versión incorrecta, imagen obsoleta, regeneración fallida).
Los módulos existen en disco pero no se incluyeron en initramfs (hooks defectuosos, configuración errónea, metadatos de dependencias faltantes).
DKMS no compiló (faltan headers, incompatibilidad con el compilador, fallo al firmar por Secure Boot).
Secure Boot está bloqueando módulos sin firma (NVIDIA, ZFS DKMS, drivers de terceros).
La pila de almacenamiento cambió (el nuevo initramfs carece de LUKS, LVM, RAID, módulos NVMe o componentes de ZFS).

La mentalidad operativa es simple: la ruta de arranque es una tubería. Encuentra en qué etapa hay artefactos obsoletos y reconstruye esa etapa.
No titubees. No “simplemente reinstales el SO.” Eso no es ingeniería; es capitulación.

Datos y contexto interesantes (porque la historia se repite a las 3 a.m.)

initramfs reemplazó initrd en gran parte porque un archivo cpio comprimido es más flexible que una imagen ramdisk de tamaño fijo.
La herramienta predeterminada de Ubuntu es initramfs-tools con update-initramfs, mientras que otras distribuciones se apoyan en dracut; la memoria muscular puede sabotearte.
El “early userspace” se hizo popular cuando el almacenamiento se volvió complejo: LVM sobre LUKS sobre MDRAID no es algo que quieras incrustado en el kernel.
DKMS existe porque los módulos fuera del árbol son una realidad: NICs de proveedor, NVIDIA y sistemas de archivos especializados siguen apareciendo en flotas reales.
Secure Boot volvió la carga de módulos política: el kernel puede estar contento y aún así rechazar tu módulo porque la historia de firmas no lo permite.
ZFS en raíz es operativo y encantador hasta que no lo es: si tu initramfs no contiene los componentes de ZFS, no montarás la raíz por mucho que tu pool esté correcto.
GRUB puede arrancar “bien” mientras el SO está roto: la transferencia funciona y luego initramfs no encuentra la raíz; la gente culpa a GRUB de todas formas.
Los cambios en la ABI del kernel son intencionales: los paquetes de kernel de Ubuntu cambian uname -r, y cualquier módulo de terceros debe coincidir exactamente.

Una idea parafraseada de W. Edwards Deming: La calidad proviene de mejorar el proceso, no de inspeccionar fallas después de que ocurren.
El trabajo de fiabilidad consiste mayormente en construir procesos que no generen imágenes initramfs rotas desde el principio.

Guía rápida de diagnóstico

Cuando un reinicio sale mal tras actualizaciones, el tiempo importa. Este es el camino más corto hacia la verdad.
Comprueba estas cosas en orden; detente en cuanto encuentres la descoordinación.

Primero: ¿Estás arrancando el kernel que crees?

Si puedes iniciar sesión: compara uname -r con lo que crees haber instalado.
Si no puedes: usa “Advanced options” de GRUB para arrancar el kernel anterior y obtener una shell.

Segundo: ¿Existe initramfs y coincide con ese kernel?

Comprueba que /boot/initrd.img-$(uname -r) existe y es reciente.
Inspecciona si los módulos requeridos están presentes dentro de la imagen (almacenamiento + crypto + drivers de plataforma).

Tercero: ¿Fallaron compilaciones de módulos (DKMS / headers / Secure Boot)?

Revisa dkms status y el estado de paquetes.
Consulta journalctl -b -0 en busca de fallos de firma o carga de módulos.

Cuarto: ¿Está fallando el descubrimiento del dispositivo raíz?

“Gave up waiting for root device” significa controladores faltantes o UUIDs erróneos.
Verifica los UUIDs en /etc/fstab, crypttab y la línea de comandos de GRUB.

Chiste #1 (corto, relevante): El initramfs es como un kit de emergencia: solo notas lo que falta cuando ya tienes frío y estás molesto.

Tareas prácticas (comandos, salidas, decisiones)

Estas tareas están diseñadas para sistemas Ubuntu 24.04 que usan initramfs-tools (el predeterminado).
Cada tarea incluye: un comando, una salida realista, qué significa y la decisión que tomas.
Ejecútalas desde un arranque funcional (quizá un kernel anterior), una shell de rescate o un ISO live con el sistema raíz montado.

Tarea 1 — Confirma el kernel en ejecución y si estás en un arranque fallback

cr0x@server:~$ uname -r
6.8.0-41-generic

Significado: Tu kernel activo es 6.8.0-41-generic. Todo lo que depures debe coincidir con esta versión.
Decisión: Usa esta cadena exacta al comprobar directorios de módulos e imágenes initramfs. Nada de adivinar o “casi igual”.

Tarea 2 — Lista de kernels instalados (y detectar paquetes medio eliminados)

cr0x@server:~$ dpkg -l 'linux-image-*' | awk '/^ii|^rc/ {print $1, $2, $3}' | head -n 12
ii linux-image-6.8.0-40-generic 6.8.0-40.40
ii linux-image-6.8.0-41-generic 6.8.0-41.41
ii linux-image-generic-hwe-24.04 6.8.0-41.41
rc linux-image-6.8.0-39-generic 6.8.0-39.39

Significado: Tienes varios kernels, y uno está en “rc” (removido, queda la configuración).
Decisión: Si te falta un kernel previo conocido como bueno, reinstálalo. Mantén al menos un kernel de fallback hasta que el sistema demuestre estabilidad.

Tarea 3 — Verifica que exista la imagen initramfs para el kernel en ejecución

cr0x@server:~$ ls -lh /boot/initrd.img-$(uname -r)
-rw-r--r-- 1 root root 114M Dec 31 09:12 /boot/initrd.img-6.8.0-41-generic

Significado: El archivo initramfs existe y su tamaño es plausible.
Decisión: Si falta, es muy pequeño o tiene sello de tiempo anterior a la actualización, lo reconstruyes. Si parece correcto, aún puede ser necesario inspeccionar su contenido.

Tarea 4 — Comprueba si existe el directorio de módulos para ese kernel

cr0x@server:~$ ls -ld /lib/modules/$(uname -r)
drwxr-xr-x 7 root root 4096 Dec 31 09:10 /lib/modules/6.8.0-41-generic

Significado: Los módulos para el kernel en ejecución existen en disco.
Decisión: Si este directorio falta, la instalación del kernel está incompleta (o estás arrancando un kernel sin módulos). Arregla los paquetes primero.

Tarea 5 — Confirma que exista la metadata de dependencias de módulos (estado de depmod)

cr0x@server:~$ ls -1 /lib/modules/$(uname -r)/modules.dep /lib/modules/$(uname -r)/modules.alias
/lib/modules/6.8.0-41-generic/modules.alias
/lib/modules/6.8.0-41-generic/modules.dep

Significado: depmod ha producido mapas de dependencias.
Decisión: Si faltan o están vacíos, ejecuta depmod -a y reconstruye initramfs. initramfs-tools depende de esta metadata para incluir drivers.

Tarea 6 — Identifica el tipo de dispositivo raíz (NVMe/SATA/LVM/LUKS/ZFS)

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE /
/dev/mapper/cryptroot / ext4

Significado: La raíz está en un mapeo dm-crypt llamado cryptroot.
Decisión: initramfs debe incluir dm-crypt y el driver de almacenamiento que esté debajo (NVMe, AHCI, RAID, etc.). Si el arranque falla, sospecha módulos de crypto/almacenamiento faltantes o crypttab obsoleto.

Tarea 7 — Comprueba que crypttab y los UUIDs en fstab sean coherentes

cr0x@server:~$ sudo grep -v '^\s*#' /etc/crypttab
cryptroot UUID=3b5a2d2c-9f1a-4c3b-bfb6-9f8c7e4a1f0e none luks,discard

cr0x@server:~$ sudo blkid | grep 3b5a2d2c-9f1a-4c3b-bfb6-9f8c7e4a1f0e
/dev/nvme0n1p3: UUID="3b5a2d2c-9f1a-4c3b-bfb6-9f8c7e4a1f0e" TYPE="crypto_LUKS" PARTUUID="b6a0..."

Significado: crypttab apunta a un UUID de dispositivo real.
Decisión: Si hay desajuste de UUIDs, initramfs esperará indefinidamente por un dispositivo que no llegará. Corrige crypttab/fstab y luego reconstruye initramfs.

Tarea 8 — Inspecciona los módulos requeridos dentro de la imagen initramfs

cr0x@server:~$ lsinitramfs /boot/initrd.img-$(uname -r) | grep -E 'cryptsetup|dm-crypt|nvme|ahci|zfs' | head
usr/sbin/cryptsetup
lib/modules/6.8.0-41-generic/kernel/drivers/md/dm-crypt.ko.zst
lib/modules/6.8.0-41-generic/kernel/drivers/nvme/host/nvme.ko.zst

Significado: initramfs contiene cryptsetup y los módulos dm-crypt y NVMe.
Decisión: Si falta tu módulo crítico, arregla la configuración de initramfs-tools o los hooks, y luego reconstruye.

Tarea 9 — Verifica si las reconstrucciones de initramfs están fallando (revisa logs)

cr0x@server:~$ sudo journalctl -u systemd-update-utmp -b -0 | tail -n 5
Dec 31 09:12:24 server systemd[1]: Starting Update UTMP about System Boot/Shutdown...
Dec 31 09:12:24 server systemd[1]: Finished Update UTMP about System Boot/Shutdown.

cr0x@server:~$ sudo grep -R "update-initramfs" -n /var/log/apt/term.log | tail -n 6
2025-12-31 09:11:57 update-initramfs: Generating /boot/initrd.img-6.8.0-41-generic
2025-12-31 09:12:03 cryptsetup: WARNING: Resume target cryptswap uses a key file

Significado: initramfs se generó durante la actualización; hay advertencias pero no un fallo claro aquí.
Decisión: Si ves “failed” o “cannot find module”, trátalo como un stop duro: arregla el problema subyacente y regenera de nuevo.

Tarea 10 — Revisa el estado de DKMS para módulos fuera del árbol

cr0x@server:~$ dkms status
nvidia/550.90.07, 6.8.0-41-generic, x86_64: installed
zfs/2.2.2, 6.8.0-41-generic, x86_64: built

Significado: NVIDIA está instalado para este kernel; ZFS está compilado (no necesariamente instalado).
Decisión: Cualquier elemento que no esté “installed” para tu kernel es una probable razón por la que los módulos no se cargan. Reconstruye DKMS y vuelve a ejecutar initramfs.

Tarea 11 — Confirma el estado de Secure Boot (y anticipa fallos de firma)

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

Significado: Secure Boot está habilitado; módulos de terceros sin firmar pueden fallar al cargarse.
Decisión: Si la carga de módulos falla con errores de firma, o bien inscribe un MOK y firma los módulos, o desactiva Secure Boot. Elige una opción; no finjas que puedes ignorarlo.

Tarea 12 — Detecta fallos de carga de módulos en el arranque actual

cr0x@server:~$ sudo journalctl -k -b -0 | grep -E "module verification failed|Unknown symbol|taint|Lockdown" | tail -n 8
Dec 31 09:13:01 server kernel: Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7
Dec 31 09:13:01 server kernel: nvidia: module verification failed: signature and/or required key missing - tainting kernel

Significado: El kernel está en modo lockdown; los módulos sin firmar pueden ser bloqueados o marcar el kernel como tainted según la política.
Decisión: Si el módulo está bloqueado (no solo tainting), tu solución es firmar/inscribir claves o desactivar Secure Boot. Reconstruir initramfs solo no ayudará.

Tarea 13 — Verifica que no hayas cambiado accidentalmente el generador de initramfs

cr0x@server:~$ dpkg -l | awk '/initramfs-tools|dracut/ {print $1, $2, $3}'
ii initramfs-tools 0.142ubuntu25.2

Significado: Estás usando initramfs-tools. Bien: mantente con un sistema a menos que tengas una política de migración.
Decisión: Si dracut está instalado y se está haciendo cargo, confirma qué herramienta actualiza tu initrd y estandariza. Mezclar herramientas es un fallo lento.

Tarea 14 — Valida artefactos de arranque y enlaces simbólicos en /boot

cr0x@server:~$ ls -l /boot | grep -E 'vmlinuz|initrd|System.map' | head -n 10
lrwxrwxrwx 1 root root      27 Dec 31 09:12 initrd.img -> initrd.img-6.8.0-41-generic
-rw-r--r-- 1 root root 119458690 Dec 31 09:12 initrd.img-6.8.0-41-generic
lrwxrwxrwx 1 root root      24 Dec 31 09:12 vmlinuz -> vmlinuz-6.8.0-41-generic
-rw-r--r-- 1 root root  14901248 Dec 31 09:12 vmlinuz-6.8.0-41-generic

Significado: Los enlaces simbólicos apuntan al kernel más reciente. Eso es normal en Ubuntu.
Decisión: Si apuntan a un kernel que carece de módulos o tiene un initramfs roto, fija GRUB a un kernel conocido como bueno mientras reparas el nuevo.

Reconstruir initramfs correctamente (y demostrar que funcionó)

El objetivo no es “ejecutar update-initramfs y confiar”. El objetivo es crear un initramfs determinista para una versión de kernel específica,
que contenga los módulos adecuados, con la metadata de dependencias actualizada y con la configuración del bootloader actualizada en consecuencia.

Paso 0 — Elige la versión de kernel que vas a arreglar

Decide explícitamente la versión de kernel objetivo. Usualmente es el kernel más nuevo instalado que deseas arrancar.
Para el resto de esta sección, asume KVER=6.8.0-41-generic.

Tarea 15 — Asegura que la imagen del kernel y los headers estén instalados

cr0x@server:~$ KVER=6.8.0-41-generic
cr0x@server:~$ sudo apt-get update
Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Reading package lists... Done

cr0x@server:~$ sudo apt-get install -y linux-image-$KVER linux-headers-$KVER
Reading package lists... Done
Building dependency tree... Done
linux-image-6.8.0-41-generic is already the newest version (6.8.0-41.41).
linux-headers-6.8.0-41-generic is already the newest version (6.8.0-41.41).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Significado: Kernel y headers están presentes. DKMS tiene una oportunidad.
Decisión: Si faltan headers, instálalos antes de tocar DKMS o initramfs. De lo contrario regenerarás un initramfs que nunca podrá contener los módulos que necesitas.

Tarea 16 — Reconstruye los módulos DKMS (si los usas)

cr0x@server:~$ sudo dkms autoinstall -k $KVER
Sign command: /usr/bin/kmodsign
Signing key: /var/lib/shim-signed/mok/MOK.priv
Public certificate (MOK): /var/lib/shim-signed/mok/MOK.der
Building module:
Cleaning build area...
Building module(s)... done.
Installing /lib/modules/6.8.0-41-generic/updates/dkms/nvidia.ko.zst
depmod...

Significado: DKMS recompiló e instaló un módulo para ese kernel y luego ejecutó depmod.
Decisión: Si DKMS falla, no reconstruyas initramfs todavía. Arregla DKMS primero (headers, compilador, firma por Secure Boot) y luego continúa.

Tarea 17 — Actualiza explícitamente la metadata de dependencias de módulos

cr0x@server:~$ sudo depmod -a $KVER

Significado: Se regeneran los mapas de dependencias de módulos para el kernel objetivo.
Decisión: Si depmod imprime errores sobre archivos faltantes, tu árbol de módulos es inconsistente. Resuelve eso antes de generar un initramfs que heredará la inconsistencia.

Tarea 18 — Reconstruye initramfs para exactamente un kernel (el sane default)

cr0x@server:~$ sudo update-initramfs -u -k $KVER
update-initramfs: Generating /boot/initrd.img-6.8.0-41-generic
W: Possible missing firmware /lib/firmware/i915/rlc.bin for module i915

Significado: initramfs se reconstruyó para el kernel objetivo. Una advertencia de firmware puede o no afectar tu ruta de arranque.
Decisión: Si indica “failed” o sale con código distinto de cero, detente y arregla. Si finaliza con advertencias, decide si la advertencia afecta hardware crítico para el arranque.

Tarea 19 — Inspecciona el contenido de initramfs para confirmar la reparación

cr0x@server:~$ lsinitramfs /boot/initrd.img-$KVER | grep -E 'dm-crypt.ko|nvme.ko|mlx|bnx2|zfs.ko' | head -n 20
lib/modules/6.8.0-41-generic/kernel/drivers/md/dm-crypt.ko.zst
lib/modules/6.8.0-41-generic/kernel/drivers/nvme/host/nvme.ko.zst

Significado: Los módulos críticos de almacenamiento/crypto están presentes.
Decisión: Si el módulo que necesitas no está en initramfs, añádelo (ver pasos siguientes) en lugar de regenerar repetidamente como en una máquina tragamonedas.

Tarea 20 — Forzar inclusión de un módulo (cuando la autodetección falla)

initramfs-tools normalmente hace lo correcto. A veces no lo hace—especialmente en controladores de almacenamiento inusuales, almacenamiento en capas o cuando los hooks fallan.
Puedes forzar módulos mediante /etc/initramfs-tools/modules.

cr0x@server:~$ echo -e "nvme\ndm-crypt\n" | sudo tee -a /etc/initramfs-tools/modules
nvme
dm-crypt

cr0x@server:~$ sudo update-initramfs -u -k $KVER
update-initramfs: Generating /boot/initrd.img-6.8.0-41-generic

Significado: Has fijado módulos requeridos en la generación del initramfs.
Decisión: Usa esto solo para elementos críticos para el arranque. No llenes initramfs con cada driver “por si acaso”. Así conviertes el arranque en una novela de misterio.

Tarea 21 — Asegura que la configuración del bootloader conozca el kernel

cr0x@server:~$ sudo update-grub
Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-41-generic
Found initrd image: /boot/initrd.img-6.8.0-41-generic
done

Significado: GRUB detectó el par kernel/initrd.
Decisión: Si GRUB no lista el kernel/initrd que esperas, arregla el montaje de /boot, las instalaciones de paquetes o problemas de espacio antes de reiniciar.

Tarea 22 — Confirma que /boot no esté lleno (a las reconstrucciones silenciosas les encanta esto)

cr0x@server:~$ df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  975M  912M   11M  99% /boot

Significado: /boot está al 99%. Esa es la zona de peligro; la regeneración puede fallar o truncarse.
Decisión: Elimina kernels antiguos de forma segura (apt-get autoremove --purge) y mantén al menos un kernel de fallback. Luego reconstruye initramfs otra vez.

Tarea 23 — Eliminar kernels antiguos de forma segura (recuperar espacio sin autoboicot)

cr0x@server:~$ sudo apt-get autoremove --purge
Reading package lists... Done
Building dependency tree... Done
The following packages will be REMOVED:
  linux-image-6.8.0-40-generic* linux-modules-6.8.0-40-generic*
After this operation, 412 MB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 214233 files and directories currently installed.)
Removing linux-image-6.8.0-40-generic (6.8.0-40.40) ...
Processing triggers for initramfs-tools (0.142ubuntu25.2) ...
update-initramfs: Generating /boot/initrd.img-6.8.0-41-generic
Processing triggers for grub-pc (2.12-1ubuntu7) ...

Significado: Kernel antiguo eliminado; initramfs regenerado; GRUB actualizado.
Decisión: Verifica que aún tengas al menos un kernel anterior como fallback. Luego procede a las pruebas de reinicio.

Tarea 24 — Reinicia para probar (y mantén una consola abierta)

cr0x@server:~$ sudo reboot

Significado: Estás probando la ruta de arranque reparada.
Decisión: Si esto es remoto, usa tu consola fuera de banda (IPMI/iDRAC/console virtual). Reinicios sin consola son la forma de practicar correos de disculpa.

Chiste #2 (corto, relevante): Secure Boot es genial hasta que eres tú intentando cargar un módulo a las 2 a.m. y empieza a pedirte “papeles”.

Tres microrelatos corporativos desde el campo

Microrelato 1: El incidente causado por una suposición incorrecta

Una empresa mediana gestionaba flotas Ubuntu en bare metal con discos raíz cifrados. Tenían una cadencia limpia de parches: stage, test, roll out.
Un viernes, la entrega se lanzó igual—porque el clúster preprod “se veía bien”.

El lunes por la mañana, una parte de producción no volvió tras un reinicio rutinario. Los sistemas aterrizaron en initramfs con “cannot find /dev/mapper/cryptroot.”
El on-call sospechó del array de discos. Storage recibió la llamada. Todos miraban números de iostat como si fueran hojas de té.

La falla real fue mundana: el initramfs generado durante la actualización no incluyó un módulo del controlador de almacenamiento necesario para ver los dispositivos NVMe.
La suposición errónea fue que “cryptsetup falla implica crypto.” Pero la capa crypto era inocente; estaba esperando por un disco que aún no era visible.

La solución fue forzar la inclusión del módulo controlador faltante en /etc/initramfs-tools/modules, regenerar para el kernel objetivo y desplegar eso como baseline de configuración.
Después añadieron una prueba de validación de la ruta de arranque: “¿initramfs puede ver el dispositivo bloque raíz?” Esa sola comprobación lo habría detectado antes del lunes.

Microrelato 2: La optimización que salió mal

Otro equipo quería reinicios más rápidos para una app de trading de baja latencia. Abarataron milisegundos donde pudieron.
Alguien propuso un “initramfs lean”: eliminar módulos “innecesarios”, deshabilitar la mayoría de las autodetecciones y mantener solo exactamente lo que el servidor usaba.

Funcionó—hasta la siguiente actualización del kernel. Una revisión de kernel cambió qué módulo proporcionaba una característica de almacenamiento concreta.
La generación del initramfs aún “triunfaba”, pero ahora faltaba el nombre correcto del módulo para el nuevo empaquetado del kernel.

El síntoma fue brutal: máquinas arrancaban en initramfs al reiniciar, y la reversión se demoró porque su proceso había eliminado kernels antiguos para mantener /boot limpio.
Optimizaron lo que no se debe optimizar con avaricia: la capacidad de recuperación.

Revirtieron la política de initramfs mínimo, mantuvieron un kernel de fallback adicional y añadieron una regla de cambio:
si ajustas el contenido de initramfs, además envías una validación que inspeccione el initrd real buscando módulos requeridos por patrón, no por nombres frágiles.

Microrelato 3: La práctica aburrida pero correcta que salvó el día

Una gran empresa tenía una política aburrida: cada ticket de actualización de kernel requería capturar tres artefactos antes del reinicio:
uname -r, la lista de kernels instalados y la salida de lsinitramfs comprobando módulos de almacenamiento y crypto.
A nadie le gustaba. Parecía papeleo.

Luego una actualización introdujo un fallo de reconstrucción DKMS para un driver de red de terceros en un subconjunto de hosts.
La actualización terminó, pero el módulo no estuvo disponible para el kernel nuevo. Sin él, la NIC no subía tras el reinicio.

Porque la política obligaba a recolectar el estado de DKMS y el contenido de initramfs, detectaron el fallo en staging antes de producción.
Fijaron la versión afectada del paquete, recompilaron DKMS con los headers correctos y programaron una ventana de mantenimiento con un kernel de rollback verificado aún instalado.

El evento no se convirtió en incidente. Se convirtió en un punto en el informe semanal.
Las prácticas aburridas no reciben aplausos, pero sí te dejan el fin de semana intacto.

Errores comunes: síntoma → causa raíz → solución

1) Caída a initramfs con “Gave up waiting for root filesystem device”

Síntoma: El arranque cae en el prompt de initramfs; UUID de la raíz no encontrado.
Causa raíz: Módulo del controlador de almacenamiento faltante en initramfs, o UUID erróneo en fstab/crypttab.
Solución: Verifica UUIDs con blkid. Inspecciona el initrd con lsinitramfs. Fuerza inclusión de módulos en /etc/initramfs-tools/modules. Reconstruye con update-initramfs -u -k KVER.

2) La red desaparece tras reinicio (driver NIC faltante)

Síntoma: El host arranca pero no hay interfaces además de loopback; ip link no muestra nada útil.
Causa raíz: Driver NIC fuera del árbol (DKMS) falló al compilar para el kernel nuevo; initramfs también puede carecer de firmware.
Solución: Revisa dkms status. Instala headers. Ejecuta dkms autoinstall -k KVER. Confirma que el módulo carga con modprobe y revisa logs del kernel, luego reconstruye initramfs.

3) Driver NVIDIA “funcionaba ayer, pantalla negra hoy”

Síntoma: La GUI falla, el display manager entra en bucle, los logs del kernel muestran errores del módulo nvidia.
Causa raíz: Mismatch de módulo DKMS o aplicación de firma por Secure Boot.
Solución: Verifica Secure Boot con mokutil --sb-state. Reconstruye DKMS. Si Secure Boot está activado, inscribe/firma correctamente o desactívalo. Luego reconstruye initramfs y reinicia.

4) “Unknown symbol” al insertar un módulo

Síntoma: Fallan las inserciones de módulo; dmesg muestra símbolos desconocidos.
Causa raíz: Módulo compilado contra headers de kernel distintos al kernel en ejecución (mismatch ABI).
Solución: Asegura que linux-headers-KVER coincida. Reconstruye DKMS para ese kernel únicamente, ejecuta depmod -a KVER y regenera initramfs.

5) initramfs se reconstruye “con éxito”, pero el arranque sigue fallando

Síntoma: Ejecutaste update-initramfs; nada cambió; sigue fallando al arrancar.
Causa raíz: Reconstruiste la versión de kernel equivocada, o GRUB arranca una entrada distinta.
Solución: Confirma uname -r del kernel con el que arrancaste exitosamente, inspecciona los enlaces en /boot, ejecuta update-grub y establece GRUB por defecto al kernel conocido bueno mientras arreglas el nuevo.

6) “No hay suficiente espacio en /boot” conduce a initrd parcialmente escrito

Síntoma: El initrd existe pero es inusualmente pequeño; los logs de regeneración muestran problemas de espacio.
Causa raíz: La partición /boot casi llena; kernels antiguos no limpiados.
Solución: Elimina kernels antiguos vía apt-get autoremove --purge (mantén un fallback). Reconstruye initramfs y actualiza GRUB.

7) ZFS root no se importa al arranque

Síntoma: El arranque cae en initramfs; pool no encontrado / import falla.
Causa raíz: Módulo ZFS no presente en initramfs, compilación DKMS no instalada o mismatch entre kernel y módulo ZFS.
Solución: Confirma el estado de ZFS DKMS, asegura que el módulo ZFS aparezca en el initrd (lsinitramfs), reconstruye DKMS e initramfs para el kernel objetivo.

Listas de verificación / plan paso a paso

Checklist A — Si el sistema aún arranca (mejor caso)

Confirma kernel en ejecución: uname -r.
Confirma kernels instalados y detecta paquetes rotos: dpkg -l 'linux-image-*'.
Comprueba espacio en /boot: df -h /boot. Si >90%, limpia primero.
Verifica que el kernel objetivo tenga módulos: ls /lib/modules/KVER.
Revisa DKMS: dkms status. Arregla lo que no esté “installed”.
Ejecuta depmod -a KVER.
Reconstruye initramfs: update-initramfs -u -k KVER.
Verifica presencia de módulos dentro del initrd: lsinitramfs y busca tus drivers.
Actualiza GRUB: update-grub.
Reinicia con acceso a consola y verifica logs post-arranque.

Checklist B — Si el sistema no arranca (modo incidente real)

Usa “Advanced options” de GRUB para arrancar un kernel más antiguo (si existe).
Si ninguno arranca: usa un ISO live, monta root y boot, luego chroot.
Dentro del chroot: asegura que /boot esté montado y sea escribible.
Reinstala la imagen del kernel + headers para la versión objetivo.
Arregla fallos de DKMS, especialmente módulos de almacenamiento/red y ZFS.
Reconstruye initramfs para el kernel objetivo.
Ejecuta update-grub y confirma que ve el kernel/initrd.
Reinicia y valida.

Tarea 25 — Flujo de recuperación con chroot (cuando necesitas reparar desde un live ISO)

cr0x@server:~$ sudo mount /dev/nvme0n1p2 /mnt/boot
cr0x@server:~$ sudo mount /dev/mapper/cryptroot /mnt
cr0x@server:~$ for d in /dev /proc /sys /run; do sudo mount --bind $d /mnt$d; done
cr0x@server:~$ sudo chroot /mnt /bin/bash

cr0x@server:/# update-initramfs -u -k 6.8.0-41-generic
update-initramfs: Generating /boot/initrd.img-6.8.0-41-generic

cr0x@server:/# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-41-generic
Found initrd image: /boot/initrd.img-6.8.0-41-generic
done

Significado: Reconstruiste artefactos de arranque en el contexto del SO instalado, no del entorno live.
Decisión: Si update-grub no encuentra tu kernel, /boot puede no estar montado correctamente o faltan paquetes. Arregla eso antes de reiniciar.

Preguntas frecuentes

1) ¿Debo usar `update-initramfs` o `mkinitramfs`?

Usa update-initramfs para operaciones rutinarias. Gestiona las rutas estándar y funciona con los triggers de empaquetado.
Usa mkinitramfs cuando quieras generar un archivo específico manualmente para pruebas, pero no lo conviertas en tu hábito por defecto.

2) Reconstruí initramfs pero aún arranca el kernel antiguo. ¿Por qué?

Porque GRUB está arrancando lo que está configurado para arrancar. Ejecuta update-grub, revisa los enlaces en /boot y confirma la entrada por defecto del menú.
También confirma que no reconstruiste initramfs para un kernel que no estás seleccionando.

3) ¿Cómo sé qué módulos deben estar en initramfs?

Necesitas todo lo requerido para descubrir y montar la raíz: controlador de almacenamiento (NVMe/AHCI/HBA), RAID/LVM/dm-crypt, driver del sistema de archivos y cualquier cosa necesaria para la ruta del dispositivo raíz.
Puedes comprobarlo inspeccionando el initrd con lsinitramfs y buscando esos módulos.

4) ¿Es seguro forzar módulos en `/etc/initramfs-tools/modules`?

Sí, cuando lo haces deliberadamente para drivers críticos de arranque. Mantén la lista reducida.
Si lo conviertes en un vertedero, inflarás el initramfs y dificultarás la depuración del arranque, no la facilitarás.

5) ¿Por qué importa Secure Boot si el módulo está en initramfs?

Estar presente en initramfs no garantiza que pueda cargarse. Las políticas de Secure Boot pueden rechazar módulos sin firmar durante el arranque.
Si ves mensajes de firma/lockdown en los logs del kernel, maneja la firma/inscripción o desactiva Secure Boot.

6) DKMS dice “built” pero no “installed.” ¿Cuál es la diferencia?

“Built” significa que la compilación tuvo éxito. “Installed” significa que el módulo se copió al árbol de módulos del kernel (típicamente bajo /lib/modules/KVER/updates) y se ejecutó depmod.
Necesitas que diga “installed” para que cargue de forma fiable y se incluya en initramfs cuando sea relevante.

7) Mi /boot es pequeño. ¿Debería simplemente agrandarlo?

Si puedes, sí—los kernels modernos y los initramfs no son pequeños. Pero en muchos entornos redimensionar particiones implica gestiones de cambio.
Operativamente, mantén un kernel de fallback, limpia los antiguos regularmente y alerta sobre el uso de /boot.

8) ¿Puedo reconstruir initramfs para todos los kernels a la vez?

Puedes: update-initramfs -u -k all. Es útil tras cambios amplios (por ejemplo añadir un módulo requerido).
Pero en respuesta a incidentes, apunta a un kernel primero para poder razonar sobre lo que cambió.

9) Aparece el prompt de initramfs y quiero depurar en vivo. ¿Qué hago?

En la shell de initramfs, comprueba qué dispositivos de bloque existen, confirma que el UUID de la raíz sea visible e intenta cargar módulos con modprobe.
Si cargar el driver faltante hace que aparezca el dispositivo raíz, has demostrado la causa raíz: módulo faltante en initramfs.

10) ¿Reinstalar el paquete de kernel arregla la mayoría de esto?

A menudo, sí—porque restaura el árbol de módulos y dispara la regeneración de initramfs.
Pero si el problema real es DKMS + Secure Boot, reinstalar el kernel solo te da una nueva etapa para fallar.

Próximos pasos que deberías hacer realmente

Si estás en medio de un outage: arranca un kernel conocido como bueno, verifica la alineación de versiones kernel/initramfs/módulos, arregla DKMS y las reales implicaciones de Secure Boot, y luego reconstruye initramfs para el kernel que quieres.
Demuestra la reparación inspeccionando el contenido del initramfs y confirmando que GRUB ve el par correcto.

Luego haz el trabajo poco glamuroso de seguimiento:

Mantén al menos un kernel de fallback instalado hasta que el kernel nuevo sobreviva a reinicios reales.
Monitorea el uso de /boot y limpia kernels antiguos según un calendario, no cuando esté al 99%.
En staging, valida la ruta de arranque comprobando que initramfs contenga tus módulos críticos de raíz (almacenamiento/crypto/ZFS/NIC según aplique).
Si usas módulos DKMS, trata “DKMS installed para KVER” como una puerta de lanzamiento, no como algo opcional.
Elige una estrategia de Secure Boot y documentala. “Lo haremos después” no es estrategia; es un incidente futuro.

La mayoría de los casos “las actualizaciones del sistema rompieron módulos” son solo artefactos descoordinados. Una vez que empiezas a tratar initramfs como un producto de construcción que puedes inspeccionar y validar, el drama baja notablemente.
Linux no es frágil. Nuestras suposiciones sí lo son.