Actualizaciones de Ubuntu 24.04 rompieron módulos del kernel: reconstruir initramfs correctamente (caso #28)

Cómo se manifiesta esta falla (y por qué confunde)

“Se rompieron los módulos” es un diagnóstico perezoso, pero generalmente es lo que te muestra la consola.
En Ubuntu 24.04, los modos de falla se concentran en el arranque temprano: el punto donde el kernel está ejecutándose,
pero tu sistema de archivos raíz real todavía no está montado.

Patrones comunes de síntomas

• Cae a la shell de initramfs (BusyBox) con “ALERT! /dev/… does not exist”.
  El kernel no puede cargar el controlador de almacenamiento (NVMe, virtio, RAID HBA, dm-crypt, LVM, ZFS) desde la imagen initramfs.
• Arranca, pero la red está muerta hasta más tarde—o para siempre.
  Un módulo o firmware de la NIC ausente en initramfs puede bloquear root por red o iSCSI, o romper requisitos de red en etapas tempranas.
• Módulos de NVIDIA / ZFS / WireGuard / del proveedor dejaron de cargarse.
  Usualmente DKMS no compiló para el nuevo kernel, o Secure Boot rechaza módulos sin firmar.
• “Unknown symbol” / “invalid module format” en dmesg.
  Eso es un desajuste: módulo compilado para otro build del kernel, o la vermagic no coincide.
• Servicios systemd fallan después del arranque porque módulos que “antes estaban” ya no lo están.
  Si el sistema arranca con un kernel de respaldo pero tus paquetes de módulos siguen “la última versión”, el desajuste persiste y aparece como errores en tiempo de ejecución.

La confusión viene por el momento en que ocurre. Una vez que estás en el entorno initramfs, tienes una imagen de sistema de archivos diminuta
con un conjunto mínimo de binarios y módulos del kernel. Si esa imagen está mal, el kernel puede estar bien y aún así no llegar al userspace.
La solución típicamente es regenerar la imagen para que los módulos y la configuración correctos estén embebidos para el kernel que deseas arrancar.

Chiste #1: Un initramfs es como un paracaídas—la mayoría de días olvidas que existe, y el día que importa realmente quieres que esté empaquetado correctamente.

Hechos y contexto interesantes (para que el comportamiento tenga sentido)

Algunos hechos concretos te ayudan a dejar de adivinar y empezar a diagnosticar. No son trivia; explican por qué “funcionó ayer” es plausible.

1. initramfs reemplazó a initrd como el mecanismo principal de arranque temprano en Linux.
   El cambio (hace años) importó porque initramfs es un archivo cpio desempaquetado en un sistema de archivos en RAM; es flexible y scriptable.
2. La herramienta por defecto de Ubuntu sigue siendo initramfs-tools.
   Algunos ecosistemas prefieren dracut, pero en Ubuntu 24.04 usualmente solucionas con update-initramfs y hooks en /etc/initramfs-tools.
3. La compatibilidad de módulos del kernel está ligada a la “vermagic”.
   Si la vermagic del módulo no coincide con el kernel en ejecución, obtienes “invalid module format” y no se cargará.
4. DKMS es un sistema de compilación, no una pegamento mágico.
   Compila módulos fuera del árbol contra los headers del kernel instalados. Si los headers no están instalados, o la compilación falla, no tendrás módulo para el nuevo kernel.
5. Secure Boot puede convertir silenciosamente la carga de módulos en una decisión de política.
   Si Secure Boot está activado, módulos sin firmar pueden ser rechazados. Puedes reconstruir initramfs perfectamente y aún fallar si las firmas no coinciden con la política.
6. Algunas pilas de almacenamiento son necesarias antes de montar la raíz.
   LVM, dm-crypt, MD RAID, NVMe, virtio-blk/scsi y ZFS pueden ser requeridos dentro de initramfs. Si faltan, no alcanzas el sistema de archivos real.
7. Las actualizaciones de microcódigo pueden cambiar el comportamiento del arranque temprano.
   El microcódigo de CPU puede incluirse en initramfs; actualizarlo puede cambiar temporizaciones y revelar carreras o dependencias de firmware.
8. Ubuntu mantiene varios kernels instalados por defecto.
   Esa red de seguridad es la razón por la que a menudo puedes arrancar con un kernel antiguo y reparar initramfs del más nuevo desde un entorno estable.
9. Los formatos comprimidos de initramfs varían (gzip, zstd).
   Si copias imágenes entre sistemas o manipulas la compresión, puedes crear problemas de “unpacking initramfs failed” que parecen problemas de módulos.

Una idea parafraseada de John Allspaw (operaciones/confiabilidad): La fiabilidad viene de aprender cómo fallan los sistemas realmente, no de fingir que no fallarán.
Ese es el tono aquí: deja de tratar initramfs como una caja negra.

Guía de diagnóstico rápido (primero/segundo/tercero)

Cuando un arranque falla, tu objetivo no es “arreglarlo todo.” Tu objetivo es encontrar el cuello de botella en la cadena de arranque.
Piensa en capas: firmware → bootloader → kernel → initramfs → raíz real → servicios.
La rotura de módulos suele vivir en las capas 3–5.

Primero: determina qué kernel estás realmente arrancando

• Si puedes acceder a una shell, comprueba uname -r.
• Si no puedes, revisa GRUB y arranca un kernel más antiguo para obtener un entorno funcional.
• Decisión: si un kernel más antiguo arranca, tienes una vía de reparación sin medios de rescate.

Segundo: decide si es “initramfs no puede montar la raíz” o “módulos faltan post-arranque”

• Si caes en BusyBox de initramfs con el dispositivo raíz faltante, es arranque temprano: contenido/configuración de initramfs o módulo/firmware de almacenamiento.
• Si el sistema arranca pero módulos específicos fallan, suele ser DKMS, firma de módulos o headers incorrectos.
• Decisión: fallos de arranque temprano requieren reconstruir initramfs para el kernel objetivo; fallos en tiempo de ejecución pueden requerir reconstruir módulos DKMS y luego regenerar initramfs si es necesario.

Tercero: comprueba si hay desajuste de módulo vs ausencia de módulo

• “Invalid module format” → desajuste (compilación para otro kernel, headers equivocados).
• “Module not found” → ausencia (no instalado, no compilado, no incluido en initramfs).
• Decisión: el desajuste te lleva a reconstrucción DKMS/headers; la ausencia te lleva a instalación de paquetes e hooks de initramfs.

Cuarto: verifica el estado de Secure Boot antes de perder tiempo

• Secure Boot habilitado + módulos de terceros = las firmas importan.
• Decisión: o inscribes una clave/firman módulos, o deshabilitas Secure Boot según la política operativa del host.

La ruta más rápida casi siempre es: arranca un kernel conocido bueno, arregla paquetes/headers/DKMS, regenera initramfs para el kernel que realmente quieres,
actualiza GRUB y reinicia una vez. No hagas “reiniciar y esperar” repetidamente. Eso no es ingeniería; es superstición con pasos adicionales.

Un modelo práctico: kernel, módulos, initramfs, DKMS

Aquí está el modelo que te evita hacer conjeturas costosas.

Kernel y módulos

La imagen del kernel (vmlinuz) es el ejecutable central. La mayor parte del soporte de hardware y las funciones viven en módulos cargables bajo
/lib/modules/<kernel-version>/. Esos módulos están fuertemente acoplados al build del kernel.
Ese acoplamiento lo hace cumplir la vermagic y las versiones de símbolos.

initramfs no es tu sistema de archivos raíz

initramfs es una imagen de sistema de archivos de arranque temprano. El kernel la desempaqueta en RAM, ejecuta /init,
y ese script monta el sistema de archivos raíz real (tu disco, RAID, LUKS, dataset ZFS, lo que sea).
Si no puedes cargar el módulo que habla con tu almacenamiento, no puedes montar la raíz real, y te detienes ahí.

Por qué las actualizaciones lo desencadenan

Una actualización de kernel típicamente instala:
linux-image-…, linux-modules-…, y quizá linux-modules-extra-….
También dispara hooks para regenerar initramfs.
Si cualquiera de esos pasos falla (disco lleno, error en hook, fallo de DKMS, headers faltantes, actualización interrumpida),
puedes terminar con un kernel que existe en disco pero un initramfs que no contiene lo que el arranque necesita.

DKMS es un sospechoso usual

DKMS compila módulos como ZFS, NVIDIA, VirtualBox, algunos drivers NIC/RAID de proveedores y varios módulos especializados.
Tras una actualización de kernel, DKMS debería compilar módulos para el nuevo kernel automáticamente.
Pero “debería” es la palabra más peligrosa en ops. Si la compilación falla, podrías reiniciar al nuevo kernel y descubrir que nada carga.

Por qué reconstruir initramfs funciona (cuando se hace bien)

Una reconstrucción correcta hace tres cosas:

• Asegura que los metadatos de dependencias de módulos sean correctos (la salida de depmod coincide con los módulos del kernel).
• Asegura que los módulos y firmware necesarios estén incluidos en la imagen initramfs para ese kernel.
• Asegura que las entradas del bootloader apunten a un par kernel+initramfs que coincida.

Si reconstruyes initramfs para el kernel equivocado, o reconstruyes mientras DKMS sigue roto, producirás un artefacto hermoso y perfectamente equivocado.
Así es como la gente termina en bucles de reinicio.

Tareas prácticas: comandos, significados de salida, decisiones

Esta sección es la parte central. Comandos reales, qué deberías ver y qué decisión tomar a partir de cada salida.
Úsala como un runbook de diagnóstico. Ejecuta comandos como root cuando se requiera.

Tarea 1: Identificar el kernel en ejecución (y si estás en un fallback)

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

Significado: Este es el kernel que se está ejecutando. Si estás solucionando una falla de arranque de un kernel más nuevo,
puede que hayas arrancado uno más antiguo vía GRUB.
Decisión: Mantén este valor. Reconstruirás initramfs para el kernel que quieres arrancar, no necesariamente para el que estás ejecutando.

Tarea 2: Listar kernels instalados (para conocer tus objetivos)

cr0x@server:~$ dpkg -l | awk '/^ii  linux-image-[0-9]/{print $2}' | sort -V
linux-image-6.8.0-49-generic
linux-image-6.8.0-50-generic

Significado: Estas imágenes de kernel están instaladas. Tu arranque roto probablemente involucra la más reciente.
Decisión: Elige la versión de kernel que quieres arreglar (usualmente la última instalada).

Tarea 3: Confirmar que existen imágenes initramfs para el kernel objetivo

cr0x@server:~$ ls -lh /boot/initrd.img-6.8.0-50-generic /boot/vmlinuz-6.8.0-50-generic
-rw-r--r-- 1 root root  98M Dec 30 10:12 /boot/initrd.img-6.8.0-50-generic
-rw------- 1 root root  14M Dec 30 10:11 /boot/vmlinuz-6.8.0-50-generic

Significado: Los artefactos de kernel e initramfs existen. Si initrd falta o es diminuto, tienes una falla en empaquetado/hook.
Decisión: Si falta o parece sospechosamente pequeño, reconstruye initramfs y revisa los logs de hooks.

Tarea 4: Comprobar si /boot está lleno (el clásico asesino silencioso)

cr0x@server:~$ df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       974M  942M     0 100% /boot

Significado: Sin espacio libre. Las actualizaciones de kernel pueden “instalarse” pero fallar al escribir initramfs, o escribir imágenes truncadas.
Decisión: Libera espacio antes de reconstruir: elimina kernels antiguos o amplía /boot. Reconstruye cuando haya espacio disponible.

Tarea 5: Encontrar los últimos errores de construcción de initramfs en los logs

cr0x@server:~$ journalctl -b -1 -u systemd-update-done.service --no-pager
Dec 30 09:58:12 server systemd[1]: Finished Wait for System Update to Complete.

cr0x@server:~$ grep -R "update-initramfs" -n /var/log/apt/term.log | tail -n 20
Log started: 2025-12-30  09:54:18
Setting up linux-image-6.8.0-50-generic (6.8.0-50.51) ...
update-initramfs: Generating /boot/initrd.img-6.8.0-50-generic
W: Possible missing firmware /lib/firmware/i915/skl_dmc_ver1_27.bin for module i915

Significado: Los logs de APT muestran si initramfs fue generado y si ocurrieron advertencias de firmware.
Decisión: Las advertencias no siempre son fatales, pero si ves errores (errores de I/O, sin espacio, fallo de hooks), arregla eso primero.

Tarea 6: Verificar que existan los directorios de módulos para el kernel

cr0x@server:~$ ls -ld /lib/modules/6.8.0-50-generic
drwxr-xr-x 6 root root 4096 Dec 30 10:10 /lib/modules/6.8.0-50-generic

Significado: Los módulos para ese kernel están instalados.
Decisión: Si faltan, reinstala los paquetes linux-modules-* para ese kernel.

Tarea 7: Comprobar depmod por errores (metadatos de dependencia)

cr0x@server:~$ sudo depmod -a 6.8.0-50-generic

Significado: Sin salida es bueno. Errores aquí significan que tu árbol de módulos es inconsistente.
Decisión: Si depmod se queja de archivos faltantes, reinstala paquetes de módulos del kernel antes de reconstruir initramfs.

Tarea 8: Confirmar que el módulo que necesitas existe (ejemplo controlador de almacenamiento)

cr0x@server:~$ modinfo -k 6.8.0-50-generic nvme | sed -n '1,6p'
filename:       /lib/modules/6.8.0-50-generic/kernel/drivers/nvme/host/nvme.ko.zst
license:        GPL
description:    NVM Express block device driver
author:         Matthew Wilcox <willy@linux.intel.com>
alias:          pci:v0000106Bd00002001sv*sd*bc*sc*i*

Significado: El módulo existe en disco para ese kernel.
Decisión: Si modinfo falla, instala el paquete de módulos faltante (a menudo linux-modules-extra) o corrige la selección del kernel.

Tarea 9: Comprobar estado de DKMS (módulos fuera del árbol)

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

Significado: Los módulos DKMS pueden no estar instalados para el kernel nuevo.
Decisión: Arregla fallos de DKMS antes de reconstruir initramfs si el arranque temprano depende de esos módulos (por ejemplo, raíz ZFS).

Tarea 10: Confirmar estado de Secure Boot (política de firma de módulos)

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

Significado: Secure Boot está habilitado. Módulos de terceros sin firmar pueden no cargarse.
Decisión: Si tu módulo roto es de terceros (NVIDIA, proveedor, ZFS DKMS en algunas configuraciones), planifica firmar/inscribir claves o deshabilitar Secure Boot (decisión de política).

Tarea 11: Inspeccionar el contenido de initramfs para un módulo específico

cr0x@server:~$ lsinitramfs /boot/initrd.img-6.8.0-50-generic | grep -E '/nvme\.ko|/zfs\.ko|/virtio_blk\.ko' | head
usr/lib/modules/6.8.0-50-generic/kernel/drivers/nvme/host/nvme.ko.zst

Significado: El initramfs incluye el módulo. Si no lo incluye, el arranque temprano puede no ver el dispositivo.
Decisión: Si los módulos necesarios están ausentes, fuerza su inclusión (config de initramfs-tools) y regenera.

Tarea 12: Validar el mapeo del dispositivo raíz (UUID vs nombres de dispositivo)

cr0x@server:~$ findmnt -no SOURCE /
/dev/mapper/vg0-root

cr0x@server:~$ cat /etc/fstab | sed -n '1,8p'
# /etc/fstab: static file system information.
UUID=8b7f5f4a-2f15-4e5a-a6b3-7c9e0c03c7b0 / ext4 defaults 0 1

Significado: Estás usando UUIDs (bien). Si /etc/fstab usa nombres de dispositivo crudos (como /dev/sda3),
el arranque puede romperse cuando la enumeración cambie.
Decisión: Usa UUIDs/LABELs y asegúrate de que initramfs tenga los módulos necesarios para encontrar esos dispositivos.

Tarea 13: Reconstruir initramfs para un kernel específico (la solución central)

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

Significado: La imagen fue regenerada. Advertencias sobre firmware pueden ser aceptables, dependiendo del hardware y si ese driver se necesita en el arranque.
Decisión: Si ves errores (no advertencias), detente y arréglalos. Si dependes de ese firmware (consola GPU en algunos sistemas), instala los paquetes de firmware.

Tarea 14: Reconstruir todas las imágenes initramfs (útil tras arreglos sistémicos)

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

Significado: Todos los kernels instalados obtuvieron imágenes initramfs actualizadas.
Decisión: Usa esto después de arreglar DKMS o firmware para que tanto el “actual” como el kernel de respaldo sean consistentes.

Tarea 15: Actualizar las entradas de GRUB (evitar arrancar artefactos desparejados)

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

Significado: GRUB ve pares coincidentes de kernel e initrd.
Decisión: Si GRUB no lista tu initrd, estás arrancando sin lo que intentas arreglar. Vuelve a la integridad/nombre de /boot.

Tarea 16: Verificar errores de carga de módulos en el log del kernel

cr0x@server:~$ dmesg -T | egrep -i 'invalid module format|Unknown symbol|module verification failed|failed to load' | tail -n 20
[Mon Dec 30 10:22:41 2025] nvidia: module verification failed: signature and/or required key missing - tainting kernel
[Mon Dec 30 10:22:41 2025] nvidia: loading out-of-tree module taints kernel.

Significado: Esto indica política de firma y tainting. Si Secure Boot está aplicando, podría rechazar en vez de taint.
Decisión: Decide si vas a firmar módulos (preferible para flotas con Secure Boot) o cambiar la política de Secure Boot para esta clase de hosts.

Reconstruir initramfs correctamente (por escenario)

Escenario A: El sistema arranca con un kernel más antiguo, pero el más nuevo falla

Este es el caso de fallo con mejor situación. Tienes un userland estable para reparar desde allí.
No “arregles” eliminando el kernel nuevo a menos que estés realmente acorralado; solo pospondrás el problema hasta la próxima ventana de actualización.

1. Libera espacio en /boot si es necesario. Ese es el paso cero, no el siete.
2. Asegúrate de que los headers para el kernel objetivo estén instalados (especialmente si DKMS entra en juego).
3. Repara módulos DKMS para el kernel objetivo.
4. Regenera initramfs para ese kernel.
5. Actualiza GRUB y reinicia una vez.

cr0x@server:~$ sudo apt-get update
Hit:1 Ubuntu noble InRelease
Reading package lists... Done

cr0x@server:~$ sudo apt-get install -y linux-headers-6.8.0-50-generic
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  linux-headers-6.8.0-50-generic
Setting up linux-headers-6.8.0-50-generic (6.8.0-50.51) ...

Significado: Los headers están presentes. Las compilaciones DKMS tienen una oportunidad.
Decisión: Si faltaban headers, espera fallos de DKMS antes. Vuelve a ejecutar DKMS ahora.

cr0x@server:~$ sudo dkms autoinstall -k 6.8.0-50-generic
Sign command: /usr/bin/kmodsign
Signing key: /var/lib/shim-signed/mok/MOK.priv
Public certificate (MOK): /var/lib/shim-signed/mok/MOK.der
Installing module zfs/2.2.2 for kernel 6.8.0-50-generic

Significado: DKMS compiló/instaló módulos para el kernel objetivo. Si la firma está configurada, los firma.
Decisión: Si DKMS falla, lee el log de compilación y arréglalo primero. No reconstruyas initramfs mientras DKMS esté roto si el arranque depende de esos módulos.

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

cr0x@server:~$ sudo update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-50-generic
Found initrd image: /boot/initrd.img-6.8.0-50-generic
done

Escenario B: Caíste en initramfs BusyBox, no puedes montar la raíz

Si ya estás en el prompt de initramfs, estás en un entorno restringido. El objetivo es reunir suficiente señal para decidir:
“módulo/firmware faltante” vs “parámetro root= equivocado” vs “corrupción del sistema de archivos”.

En el prompt de initramfs, comprueba qué puede ver el kernel y qué puede cargar.

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.0-50-generic root=UUID=8b7f5f4a-2f15-4e5a-a6b3-7c9e0c03c7b0 ro quiet splash

Significado: La raíz está especificada por UUID. Bien. Ahora verifica que el UUID aparezca en los dispositivos de bloque.
Decisión: Si root está especificado como /dev/sdX y la letra cambió, arregla GRUB/cmdline y fstab para usar UUID.

cr0x@server:~$ ls /dev/disk/by-uuid | head
2c1f9b55-0a69-4b59-9c4d-2b0a7dc3c77a

Significado: Si tu UUID raíz falta aquí, el kernel no puede ver el disco o la tabla de particiones.
Decisión: Eso apunta a un controlador de almacenamiento faltante, firmware ausente o problema hardware. Reconstruye initramfs desde un kernel funcional o desde un entorno de rescate.

cr0x@server:~$ modprobe nvme
modprobe: module nvme not found in modules.dep

Significado: El initramfs no contiene el módulo nvme ni los metadatos de dependencias.
Decisión: Necesitas arrancar otro kernel (o medios de rescate), asegurarte de que linux-modules esté instalado, y regenerar initramfs con nvme incluido.

En este escenario, no intentes reparaciones ingeniosas dentro del initramfs roto a menos que sepas exactamente lo que haces.
Típicamente es más rápido reiniciar en un kernel más antiguo, o usar modo de recuperación, arreglar, reconstruir y reiniciar.

Escenario C: Raíz ZFS o “raíz en almacenamiento exótico” falla tras la actualización

ZFS es un caso frecuente porque a menudo depende de módulos fuera del árbol (vía DKMS) y es requerido antes de montar la raíz.
Si los módulos ZFS no están presentes en initramfs, el arranque se detiene temprano.

Tu orden de prioridades:
Estado de DKMS → presencia de módulos → regeneración initramfs → verificar initramfs contiene ZFS → reiniciar.

cr0x@server:~$ dkms status | grep -i zfs
zfs/2.2.2, 6.8.0-50-generic, x86_64: installed

cr0x@server:~$ lsinitramfs /boot/initrd.img-6.8.0-50-generic | grep -E '/zfs\.ko|/zcommon\.ko' | head
usr/lib/modules/6.8.0-50-generic/updates/dkms/zfs.ko
usr/lib/modules/6.8.0-50-generic/updates/dkms/zcommon.ko

Significado: Los módulos ZFS están embebidos. Si no lo están, el arranque fallará antes de importar pools.
Decisión: Si faltan, asegúrate de que los hooks de initramfs-tools para ZFS estén presentes (estado del paquete) y vuelve a ejecutar update-initramfs.

Escenario D: NVIDIA u otros módulos de terceros fallan en tiempo de ejecución

Para módulos en tiempo de ejecución, initramfs aún puede importar (si quieres KMS temprano, peticiones de LUKS por consola GPU, etc.),
pero la mayoría de las veces es un problema de DKMS/firma.

cr0x@server:~$ dkms status | grep -i nvidia
nvidia/550.90.07, 6.8.0-50-generic, x86_64: installed

cr0x@server:~$ modprobe nvidia
modprobe: ERROR: could not insert 'nvidia': Key was rejected by service

Significado: Rechazo por política de firma (común con Secure Boot). El módulo existe pero no es de confianza.
Decisión: O firmas el módulo con una clave inscrita, o inscribes MOK, o deshabilitas Secure Boot para esa máquina.

Chiste #2: Secure Boot es genial hasta que decide que tu módulo cuidadosamente construido está “no autorizado”, como un portero en la discoteca del kernel.

Tres microhistorias corporativas desde el terreno

1) El incidente causado por una suposición errónea: “El initramfs siempre se reconstruye en la actualización”

Una compañía mediana operaba una flota de servidores Ubuntu que alojaban runners de CI internos y cachés de artefactos.
Nada exótico—hasta que notas que su “imagen estándar” tenía una partición /boot diminuta heredada de un diseño de 2018.
Funcionó durante años porque los kernels eran poco frecuentes y nadie vigilaba el uso de /boot.

Un martes, una actualización desatendida trajo un nuevo kernel. La instalación del paquete tuvo éxito, pero /boot llegó al 100% mientras se generaba initramfs.
El proceso de instalación registró errores, pero la canalización de actualizaciones no lo trató como fatal. Los servidores siguieron funcionando con el kernel antiguo.
Todo parecía verde.

Llegó la siguiente ventana programada de reinicio. Las máquinas se reiniciaron en un kernel cuyo initramfs faltaba o estaba truncado.
La mitad de la flota cayó en BusyBox de initramfs con dispositivos raíz faltantes. La otra mitad arrancó sólo porque accidentalmente seleccionaron el kernel antiguo en las opciones por defecto de GRUB.
El comandante del incidente asumió “no puede ser initramfs; la actualización lo habría reconstruido.”

La solución fue poco glamurosa: ampliar /boot en la imagen base, aplicar una verificación de que la generación de initramfs tuvo éxito, y mantener al menos un kernel antiguo como respaldo.
También cambiaron su automatización de reinicios: ahora verifica que /boot/vmlinuz y /boot/initrd existan como pares para la entrada por defecto antes de reiniciar.

La suposición errónea no fue ignorancia técnica. Fue pereza operativa: confundir “los scripts de paquetes se ejecutaron” con “el artefacto producido es válido.”
En ops, no te dan crédito por pretender generar un initramfs.

2) La optimización que salió mal: “Recortar initramfs para acelerar el arranque”

Otra organización ejecutaba cargas sensibles a latencia y tenía la costumbre de recortar milisegundos de todo lo que se moviera.
Alguien notó el tamaño de initramfs y decidió que era “bloat”. Editaron las configuraciones de initramfs-tools para ser agresivos:
menos módulos, menos hooks, y la creencia de que udev descubriría todo más tarde.

Funcionó en su hardware principal por un tiempo. El tiempo de arranque mejoró ligeramente. El cambio se desplegó en la flota con poca fanfarria.
El truco, por supuesto, es que las flotas nunca son uniformes, y la realidad adora los casos límite.

Llegó un nuevo lote de servidores con un controlador de almacenamiento diferente que requería un módulo que no estaba en el kernel.
El initramfs recortado no lo incluía. Las máquinas no pudieron montar la raíz y nunca alcanzaron la gestión de configuración.
Eso significó que no pudieron auto-repararse, no pudieron descargar arreglos y ni siquiera pudieron reportar el fallo correctamente.

El postmortem fue doloroso porque la “optimización” era correcta en el hardware antiguo y errónea en el nuevo.
La lección no fue “nunca optimices”. Fue: si vas a optimizar artefactos de arranque temprano, debes tener perfiles conscientes del hardware o incluir controladores de almacenamiento amplios por defecto.
La corrección del arranque vence a la velocidad del arranque. Siempre.

3) La práctica aburrida pero correcta que salvó el día: “Siempre mantener una vía de arranque conocida buena”

Una organización financiera ejecutaba hosts Ubuntu con raíz encriptada y personal de soporte remoto costoso.
Su regla era clásica: nunca eliminar el kernel previo hasta que el nuevo haya arrancado con éxito al menos una vez,
y siempre tener acceso a la consola probado trimestralmente. Aburrido. Predecible. Muy poco sexy.

En un ciclo de actualización, un módulo DKMS falló al compilar para el kernel más nuevo debido a una incompatibilidad de toolchain.
El initramfs para el kernel nuevo se generó, pero no contenía el módulo requerido para su pila de raíz.
El siguiente reinicio habría sido un ladrillo.

Pero no reiniciaron a ciegas. Su proceso de cambios incluía una comprobación previa al reinicio:
verificar estado de DKMS para el kernel objetivo, verificar que initramfs contiene los módulos requeridos, verificar espacio en /boot,
y verificar que GRUB apunta a un par kernel+initrd coincidente. La comprobación previa falló, así que el reinicio se pospuso.

Arreglaron el problema de compilación de DKMS, regeneraron initramfs y luego reiniciaron en una ventana controlada.
Sin outage. Sin héroes. Sin sala de guerra. El mejor incidente es el que nunca llega a convocarse.

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

1) Cae a la shell de initramfs: “ALERT! UUID=… does not exist”

Causa raíz: Controlador de almacenamiento faltante en initramfs, o initramfs construido para un kernel distinto al que se arrancó.
A veces es un blob de firmware faltante para el dispositivo de almacenamiento/NIC.

Solución: Arranca con un kernel conocido bueno, asegura los paquetes correctos linux-modules instalados, luego update-initramfs -u -k <target> y update-grub.
Verifica con lsinitramfs que el módulo necesario esté presente.

2) “Invalid module format” al cargar un módulo

Causa raíz: El módulo fue compilado para otra versión del kernel/opciones de build (desajuste de vermagic) o artefactos DKMS obsoletos.

Solución: Instala headers coincidentes, reconstruye el módulo DKMS para el kernel objetivo, ejecuta depmod -a <kernel>, y luego reconstruye initramfs.

3) “Key was rejected by service” para módulos NVIDIA/ZFS/proveedor

Causa raíz: Secure Boot aplicando la política de firma de módulos; el módulo está sin firmar o firmado con una clave no confiable.

Solución: Elige: inscribir una Machine Owner Key y firmar módulos (amigable para flotas), o deshabilitar Secure Boot (más simple pero dependiente de la política).
Reconstruye initramfs si el arranque temprano necesita ese módulo.

4) El kernel se instala pero initrd falta o es diminuto

Causa raíz: /boot lleno, actualización interrumpida, errores de sistema de archivos, o scripts de hook fallando.

Solución: Libera espacio, ejecuta comprobaciones de sistema de archivos si es necesario, vuelve a ejecutar update-initramfs. Confirma tamaño y timestamps del artefacto.

5) El arranque funciona solo con un kernel más antiguo después de la actualización

Causa raíz: DKMS no compiló para el kernel nuevo, o falta linux-modules-extra para el kernel nuevo.

Solución: Repara estado de DKMS, instala paquetes faltantes, regenera initramfs y actualiza GRUB.

6) “unpacking initramfs failed” o pánico temprano del kernel

Causa raíz: Imagen initramfs corrupta (disco lleno al escribir, almacenamiento malo, o ediciones manuales), o herramienta de compresión incompatible.

Solución: Recrea initramfs desde cero con update-initramfs -c -k <kernel>, y verifica salud y espacio del sistema de archivos /boot.

7) La raíz se monta, pero dispositivos faltan más tarde

Causa raíz: Desajuste de paquetes de módulos o paquete de firmware faltante; initramfs no se regeneró tras cambios de firmware/módulos.

Solución: Instala paquetes de firmware según sea necesario, ejecuta update-initramfs -u -k all, y reinicia.

Listas de verificación / plan paso a paso

Lista 1: Reglas de “no empeorar”

• No elimines el único kernel funcional. Mantén al menos una entrada conocida buena hasta que el nuevo arranque correctamente.
• No reconstruyas initramfs mientras /boot esté lleno.
• No asumas que DKMS tuvo éxito porque APT salió con 0. Verifica el estado de DKMS.
• No cambies la política de Secure Boot durante un incidente sin registrar la decisión y la ruta de rollback.
• No depures problemas de módulos sin confirmar qué kernel estás arrancando.

Lista 2: Recuperación paso a paso cuando puedes arrancar un kernel más antiguo

1. Confirma el kernel actual:

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

   Decisión: Si ya estás en el kernel más nuevo, tu problema probablemente es runtime/DKMS/firma, no initramfs para otro kernel.

2. Identifica el kernel objetivo que quieres arrancar:

   cr0x@server:~$ dpkg -l | awk '/^ii  linux-image-[0-9]/{print $2}' | sort -V | tail -n 2
   linux-image-6.8.0-49-generic
   linux-image-6.8.0-50-generic
   

   Decisión: El objetivo suele ser el último instalado.

3. Comprueba espacio en /boot:

   cr0x@server:~$ df -h /boot
   Filesystem      Size  Used Avail Use% Mounted on
   /dev/sda2       974M  620M  305M  68% /boot
   

   Decisión: Si >90% usado, limpia kernels antiguos antes de regenerar.

4. Asegura que exista el árbol de módulos:

   cr0x@server:~$ test -d /lib/modules/6.8.0-50-generic && echo ok
   ok
   

   Decisión: Si no está ok, reinstala los paquetes de módulos del kernel.

5. Asegura que existan headers si DKMS está en juego:

   cr0x@server:~$ dpkg -l | awk '/^ii  linux-headers-6.8.0-50-generic/{print $2, $3}'
   linux-headers-6.8.0-50-generic 6.8.0-50.51
   

   Decisión: Si faltan, instala headers y vuelve a ejecutar DKMS.

6. Repara DKMS y comprueba estado:

   cr0x@server:~$ sudo dkms autoinstall -k 6.8.0-50-generic
   Installing module zfs/2.2.2 for kernel 6.8.0-50-generic
   

   Decisión: Si aparecen fallos, abre el log de compilación DKMS y arregla compilación/firma antes de continuar.

7. Regenera initramfs para el kernel objetivo:

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

   Decisión: Si ves errores, no reinicies. Arregla el error. Las advertencias requieren juicio.

8. Verifica que los módulos requeridos estén dentro del initramfs:

   cr0x@server:~$ lsinitramfs /boot/initrd.img-6.8.0-50-generic | grep -E '/(nvme|virtio_blk|dm_crypt|zfs)\.ko' | head
   usr/lib/modules/6.8.0-50-generic/kernel/drivers/nvme/host/nvme.ko.zst
   

   Decisión: Si el módulo requerido para la raíz no está, necesitas cambios en initramfs-tools o paquetes faltantes.

9. Actualiza la configuración del bootloader:

   cr0x@server:~$ sudo update-grub
   Found linux image: /boot/vmlinuz-6.8.0-50-generic
   Found initrd image: /boot/initrd.img-6.8.0-50-generic
   done
   

   Decisión: Si GRUB no ve initrd, arregla nombres en /boot y regenera nuevamente.

10. Reinicia una vez y valida:

    cr0x@server:~$ sudo reboot
    ...connection closed...
    

    Decisión: Después del arranque, verifica uname -r y revisa logs por errores de carga de módulos.

Lista 3: Si debes reconstruir initramfs desde un entorno de rescate

Usa esto cuando no puedas arrancar ningún kernel instalado. Los pasos de alto nivel son consistentes:
montar la raíz, montar /boot, bind mount de /dev /proc /sys, chroot, luego reconstruir.
Los detalles varían según tu pila de almacenamiento, pero la disciplina es la misma.

cr0x@server:~$ sudo mount /dev/mapper/vg0-root /mnt
cr0x@server:~$ sudo mount /dev/sda2 /mnt/boot
cr0x@server:~$ for i in dev proc sys run; do sudo mount --bind /$i /mnt/$i; done
cr0x@server:~$ sudo chroot /mnt /bin/bash

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

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

Decisión: Si update-initramfs falla dentro del chroot, arregla el estado de paquetes (headers, módulos, DKMS) dentro del chroot, no en el OS de rescate.

Preguntas frecuentes

1) ¿Debo usar update-initramfs -u -k all o apuntar a un kernel?

Apunta a un kernel cuando estás en modo incidente y quieres reducir variables.
Usa -k all después de haber arreglado problemas sistémicos (DKMS, firmware) y quieres consistencia entre kernels de respaldo.

2) ¿Cuál es la diferencia entre -u y -c para update-initramfs?

-u actualiza una imagen initramfs existente; -c crea una nueva desde cero.
Si sospechas corrupción o un resultado incremental malo, usa -c para el kernel objetivo.

3) Reconstruí initramfs, pero aún no encuentra la raíz. ¿Y ahora qué?

Verifica que el módulo esté presente dentro de initramfs (lsinitramfs | grep), verifica que el UUID raíz exista en /dev/disk/by-uuid en la shell de initramfs,
y verifica la línea de comandos del kernel (/proc/cmdline). Si el UUID no existe, te falta un controlador de almacenamiento/firmware o tienes un problema hardware real.

4) DKMS muestra “built” pero no “installed”. ¿Importa?

Sí. “Built” significa que se compiló; “installed” significa que colocó el módulo donde el kernel lo cargará y ejecutó la integración de depmod.
Para módulos críticos de arranque (raíz ZFS), quieres que esté “installed” para el kernel objetivo.

5) ¿Cómo sé si necesito linux-modules-extra?

Si un módulo que esperas (sistema de archivos, controlador de almacenamiento, NIC poco común) falta en /lib/modules/<kernel>,
puede residir en el paquete “extra” según el empaquetado de Ubuntu.
Compruébalo con modinfo -k <kernel> <module>; si falla, instala el paquete extra de módulos para ese flavor de kernel.

6) ¿Las advertencias de firmware durante la generación de initramfs son fatales?

No automáticamente. Se vuelven fatales si el firmware es necesario para inicializar hardware requerido para el arranque (algunos dispositivos de almacenamiento/NIC).
Si el sistema falla temprano y la advertencia menciona tu almacenamiento o NIC crítico para el arranque, trátalo como probablemente relevante.

7) Uso LUKS + LVM. ¿Qué debo verificar en initramfs?

Asegúrate de que dm-crypt y las herramientas LVM estén presentes y que initramfs incluya los hooks relevantes.
Prácticamente: comprueba que los módulos y binarios existan en initramfs y que tu /etc/crypttab sea correcto.
Luego regenera initramfs para el kernel objetivo.

8) ¿Puedo arreglar esto fijando el kernel antiguo y ignorando el nuevo?

Temporalmente, sí, como medida de contención. Operativamente, es una bomba de deuda.
Aún necesitas reparar la cadena de construcción (DKMS, headers, espacio /boot, firmas) o repetirás el outage más adelante en peores condiciones.

9) ¿Y si GRUB está arrancando el kernel equivocado incluso después de actualizar?

Confirma lo que GRUB cree que es por defecto, regenera la config con update-grub, y verifica que el initrd referenciado exista.
También revisa ediciones manuales en /etc/default/grub que fijen un kernel antiguo.

10) ¿Por qué esto ocurre “aleatoriamente” después de actualizaciones?

No es aleatorio. Usualmente es uno de: capacidad de /boot, actualizaciones interrumpidas, fallos de compilación DKMS, política de Secure Boot, headers faltantes,
o un hook de initramfs fallando. Son problemas deterministas con síntomas ruidosos.

Próximos pasos que deberías hacer realmente

Si estás aquí porque la producción acaba de caer, haz la reparación disciplinada:
arranca un kernel conocido bueno, confirma que /boot tiene espacio, verifica headers y estado de DKMS para el kernel objetivo,
reconstruye initramfs para ese kernel, verifica que los módulos requeridos estén embebidos, actualiza GRUB y reinicia una vez.
Ni más ni menos.

Luego evita la secuela. Añade comprobaciones a tus flujos de actualización y reinicio:
alerta sobre uso de /boot, trata errores de generación de initramfs como fallos, verifica estado DKMS por kernel,
y mantén al menos un kernel de respaldo hasta que el nuevo se haya probado. Las prácticas aburridas no son glamorosas,
pero son más baratas que el downtime y menos emocionantes que una sesión de consola a las 2 a.m.