Ubuntu 24.04: Secure Boot bloquea controladores — solución sin arruinar tu equipo

enero 15, 2026 • febrero 3, 2026 • Lectura: 27 min • Views: 7

¿Te fue útil?

Secure Boot debería mantener tu sistema más seguro. Luego actualizas un controlador, reinicias y de repente tu GPU desaparece del planeta, el Wi‑Fi se esfuma o VirtualBox actúa como si nunca hubiese conocido tu kernel. Los registros dicen “verification failed.” La máquina dice “no.” Y tu calendario dice que tienes una reunión en seis minutos.

Esta es la realidad de Ubuntu 24.04 en sistemas UEFI modernos: Secure Boot + módulos del kernel fuera del árbol (NVIDIA, VirtualBox, ZFS DKMS, controladores de Wi‑Fi de proveedores, agentes EDR) es un contrato. Si no firmas, no se ejecuta. La solución no es “reinstalar Ubuntu.” La solución es diagnosticar qué se está bloqueando y o bien (a) inscribir una clave y firmar los módulos, o (b) desactivar Secure Boot deliberadamente con los ojos abiertos. Puedes mantener tu configuración intacta.

Lista de diagnóstico rápido

Si necesitas un sistema funcionando cuanto antes, no empieces por reinstalar controladores. No empieces por recompilar el kernel. Empieza por demostrar qué política te afecta y qué exactamente está siendo rechazado.

Primero: confirma el estado de Secure Boot y la aplicación de firmas en módulos

¿Está activado Secure Boot? Si está desactivado, deja de culparlo y busca en otra parte.
¿El kernel está aplicando la exigencia de firmas a módulos? Ubuntu puede hacer cumplir las firmas cuando Secure Boot está activado. Eso convierte muchos “antes funcionaba” en “ahora está bloqueado.”
¿Qué módulo falla al cargar? Quieres el nombre del módulo y la cadena de error exacta.

Segundo: identifica el origen y ciclo de vida del módulo

¿Es un módulo DKMS? DKMS significa “reconstruido en actualizaciones,” lo que implica “seguirá rompiéndose hasta que la firma se automatice.”
¿Proviene de paquetes de Ubuntu? Si es así, hay puntos de integración oficiales (como los avisos MOK durante la instalación) que puedes aprovechar.
¿Lo proporciona el fabricante? Si es así, puede incluir binarios sin firmar o su propio proceso de firma.

Tercero: decide entre dos estrategias de remediación sensatas

Preferida para flotas gestionadas: mantener Secure Boot activado, inscribir una Machine Owner Key (MOK) y firmar tus módulos fuera del árbol (preferiblemente de forma automática).
Aceptable para estaciones de trabajo de un solo usuario con tolerancia al riesgo: desactivar Secure Boot desde el firmware y seguir adelante—documenta la decisión para que el Futuro Tú no pase una noche persiguiendo fantasmas.

Una verdad operativa: la “solución” más rápida suele ser desactivar Secure Boot, y la mejor solución casi nunca es esa. La diferencia es si esta máquina necesita ser defendible en una auditoría y si quieres que las actualizaciones dejen de ser una aventura.

Qué hace realmente Secure Boot en Ubuntu 24.04

Secure Boot es una función de UEFI que verifica las firmas de cargadores de arranque y (en la mayoría de distribuciones Linux modernas) puede extender la confianza hasta la ruta de carga de módulos del kernel. En Ubuntu, la cadena suele ser: el firmware verifica shim, shim verifica GRUB y el kernel, y luego el kernel usa claves (incorporadas y enroladas) para decidir qué módulos del kernel pueden cargarse.

La conclusión: si Secure Boot está activado y tu kernel está en modo que exige firmas, un módulo del kernel sin una firma de confianza se comporta como una identificación falsa en una discoteca—no importa cuánto te parezca “legítimo”.

Ubuntu intenta hacer esto tolerable usando el sistema de MOK (Machine Owner Key): generas o instalas una clave de firma, enrolas la parte pública mediante el MOK Manager en el arranque y luego firmas tus módulos con la clave privada. Una vez enrolada, el kernel confía en los módulos firmados por esa clave.

Lo que suele pillar a la gente es el momento. Instalas un controlador, DKMS construye un módulo y todo parece bien—hasta el reinicio donde la aplicación de Secure Boot hace que el kernel lo rechace. Tu controlador “se instaló” y aun así no funciona. Bienvenido a la informática gobernada por políticas.

Una idea parafraseada (no textual) de James Hamilton (Amazon, fiabilidad): “Logras fiabilidad diseñando para que la falla sea un estado normal, no un evento sorpresa.” El rechazo de módulos por Secure Boot es una falla por política; trátala como una condición diseñada, no como un bug extraño.

Hechos y contexto que te gustaría haber sabido antes

Secure Boot llegó con los requisitos de hardware de la era Windows 8 (más o menos 2012) y se generalizó porque los OEM comenzaron a activarlo por defecto.
Ubuntu usa “shim” específicamente para encajar en el ecosistema UEFI CA de Microsoft para que los sistemas puedan arrancar Linux sin que cada usuario gestione sus propias claves de plataforma.
MOK existe porque pedir a cada usuario que sustituya las claves del firmware es poco realista y a menudo imposible en portátiles bloqueados.
La aplicación de firmas en módulos no es universal en todas las distros; algunas la tratan como opcional aun con Secure Boot activado, mientras que Ubuntu tiende a imponerla para módulos fuera del árbol sin firmar.
DKMS es una espada de doble filo: reconstruye módulos automáticamente para nuevos kernels, lo cual es genial—hasta que descubres que las reconstrucciones sin firmar se rompen bajo Secure Boot.
Los controladores NVIDIA son un punto conflictivo recurrente porque viven fuera del árbol del kernel y muchas configuraciones dependen de builds DKMS para el kernel exacto en ejecución.
vboxdrv de VirtualBox es un ejemplo clásico de módulo que “funciona hasta el reinicio” cuando Secure Boot exige firmas.
El kernel tiene varios keyrings involucrados (builtin, secondary, MOK/Platform); depurar es más fácil cuando aceptas que tratas con keyrings, no con sensaciones.
Algunos sistemas silenciosamente restablecen la configuración de Secure Boot durante actualizaciones de firmware, lo que explica por qué puedes “de repente” ver rechazos de módulos en una estación que antes era estable.

Tareas de diagnóstico principales (comandos, salidas, decisiones)

Estas son las tareas que ejecuto en producción cuando Secure Boot bloquea controladores. Cada una incluye: comando, salida realista, qué significa y qué decisión tomar.

Tarea 1: Comprobar si Secure Boot está activado

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

Significado: El firmware indica que Secure Boot está activo, y shim/mokutil pueden verlo.

Decisión: Procede asumiendo que los módulos sin firmar probablemente serán bloqueados. Si dice “disabled”, tu problema probablemente no sea Secure Boot—cambia de pista y revisa compatibilidad del controlador, desajuste del ABI del kernel o blobs de firmware faltantes.

Tarea 2: Confirmar que arrancaste en modo UEFI (no legacy/CSM)

cr0x@server:~$ [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
UEFI

Significado: Estás realmente en el mundo de Secure Boot. El arranque legacy significa que Secure Boot no está en juego.

Decisión: Si ves “BIOS”, detente—las soluciones relacionadas con Secure Boot no aplicarán. Averigua por qué estás en modo legacy (configuración del firmware, orden de arranque, instalación antigua) y corrige si hace falta.

Tarea 3: Comprobar el estado de lockdown del kernel

cr0x@server:~$ cat /sys/kernel/security/lockdown
integrity

Significado: El lockdown del kernel está activo en modo “integrity”, desencadenado comúnmente por Secure Boot. Esto suele ir acompañado de la exigencia de firmas y restringe ciertas operaciones a bajo nivel.

Decisión: Espera un comportamiento más estricto. Si intentas cargar módulos sin firmar o usar herramientas que tocan memoria del kernel, te toparás con muros. Planea firmar en lugar de “forzar”.

Tarea 4: Identificar el síntoma del controlador que falta (módulo no carga)

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

Significado: El módulo estaba presente pero rechazado por fallo de confianza/firmas.

Decisión: Esto no es un problema de “controlador no instalado”. Es un problema de confianza/firmas. Ve hacia la inscripción MOK y la firma.

Tarea 5: Leer el registro del kernel para la razón exacta del rechazo

cr0x@server:~$ sudo dmesg -T | tail -n 12
[Sat Dec 28 10:11:41 2025] Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7
[Sat Dec 28 10:11:41 2025] nvidia: module verification failed: signature and/or required key missing - tainting kernel
[Sat Dec 28 10:11:41 2025] nvidia: loading out-of-tree module taints kernel.
[Sat Dec 28 10:11:41 2025] nvidia: module license 'NVIDIA' taints kernel.

Significado: Tienes tanto errores de lockdown como de verificación. Nota la diferencia: “tainting kernel” es informativo; “restricted” puede significar que no se cargará en absoluto.

Decisión: Si está restringido/rechazado, debes firmar/enrolar o desactivar la aplicación desactivando Secure Boot. Si se carga pero marca el kernel como tainted, el controlador está en ejecución; tu problema está en otro lado.

Tarea 6: Comprobar si el módulo está presente y qué archivo se está cargando

cr0x@server:~$ modinfo -n nvidia
/lib/modules/6.8.0-41-generic/updates/dkms/nvidia.ko

Significado: El módulo proviene de la salida de DKMS (updates/dkms). Es un objetivo prioritario para firmar.

Decisión: Trátalo como “se reconstruirá en la actualización del kernel,” por tanto “debe firmarse automáticamente tras la reconstrucción”.

Tarea 7: Comprobar el estado de DKMS (qué está construido para qué kernel)

cr0x@server:~$ dkms status
nvidia/550.90.07, 6.8.0-41-generic, x86_64: installed
vboxhost/7.0.20, 6.8.0-41-generic, x86_64: installed

Significado: DKMS ha construido módulos para tu kernel actual. “Installed” no significa “cargable bajo Secure Boot”.

Decisión: Si Secure Boot está activado, asume que estos productos DKMS necesitan firma (a menos que el empaquetado lo maneje y la clave esté enrolada).

Tarea 8: Comprobar si hay claves MOK inscritas

cr0x@server:~$ sudo mokutil --list-enrolled | head
[key 1]
SHA1 Fingerprint: 7a:9d:2b:1c:2f:7c:de:aa:8b:10:1b:6c:4f:5b:89:9a:1d:00:aa:41
Subject: CN=Ubuntu Secure Boot Module Signature key
Issuer: CN=Ubuntu Secure Boot Module Signature key

Significado: Hay una MOK inscrita. Es buena noticia, pero puede no ser la clave que estés usando (o el módulo puede no estar firmado en absoluto).

Decisión: Si no hay claves inscritas, necesitas inscribir una. Si hay claves, verifica que tu módulo esté firmado por una de ellas.

Tarea 9: Verificar si un módulo está firmado (y por quién)

cr0x@server:~$ modinfo nvidia | egrep -i 'signer|sig_key|sig_hash'
signer:         CN=My DKMS Signing Key
sig_key:        3A:7F:1C:2D:4F:AA:11:9B:5A:1C:0D:32:77:2B:10:8F:DE:55:21:90
sig_hashalgo:   sha256

Significado: El módulo está firmado. Ahora la pregunta es si la clave del firmante es de confianza para el kernel (es decir, está inscrita vía MOK o en el keyring incorporado).

Decisión: Si está sin firmar (sin campos signer), fírmalo. Si está firmado pero aún rechazado, probablemente inscribiste una clave diferente a la usada para firmar.

Tarea 10: Confirmar qué keyrings tiene el kernel disponibles (chequeo de sanidad operativa)

cr0x@server:~$ sudo keyctl list %:.system_keyring
3 keys in keyring:
  260754792: --alswrv     0     0 asymmetric: Ubuntu Secure Boot Module Signature key: X509.rsa
  412884911: --alswrv     0     0 asymmetric: Microsoft Windows Production PCA 2011: X509.rsa
  101388220: --alswrv     0     0 asymmetric: Canonical Ltd. Secure Boot Signing: X509.rsa

Significado: El keyring del sistema incluye claves de Ubuntu/Canonical y a menudo la cadena CA UEFI de Microsoft. Las claves MOK pueden aparecer en un keyring secundario según la configuración.

Decisión: Si tu clave personalizada no aparece en ningún keyring relevante, no la inscribiste (o la inscripción no se completó en el MOK Manager al arrancar).

Tarea 11: Comprobar si un módulo está siendo bloqueado por la política de Secure Boot vs. dependencia faltante

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

Significado: Mismo patrón de exigencia de firmas. VirtualBox es clásico en este caso.

Decisión: No reinstales VirtualBox diez veces. Firma el módulo e inscribe la clave. Reinstalar produce el mismo módulo sin firmar, solo con decepción fresca.

Tarea 12: Inspeccionar variables de Secure Boot rápidamente (ayuda a detectar incidentes de “reseteo de firmware”)

cr0x@server:~$ sudo bootctl status | sed -n '1,18p'
System:
     Firmware: UEFI 2.70 (American Megatrends 5.17)
  Secure Boot: enabled
   Setup Mode: user
 TPM2 Support: yes
 Boot into FW: supported

Current Boot Loader:
      Product: systemd-boot 255.4-1ubuntu8
     Features: ✓ Boot counting
               ✓ Menu timeout control
               ✓ One-shot menu timeout control
               ✓ EFI variable boot loader control

Significado: Secure Boot está activado y el firmware está en modo user (no setup). El modo setup puede indicar que se borraron/reescribieron claves.

Decisión: Si ves “Setup Mode: setup,” trátalo como “posible borrado de claves de plataforma,” lo que puede romper cadenas de arranque previamente confiables y el comportamiento de MOK. Escala a pasos de gestión de firmware/claves.

Tarea 13: Confirmar el kernel en ejecución y kernels instalados (evita perseguir el ABI equivocado)

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

cr0x@server:~$ dpkg -l 'linux-image-*' | awk '/^ii/{print $2,$3}' | tail -n 5
linux-image-6.8.0-40-generic 6.8.0-40.40
linux-image-6.8.0-41-generic 6.8.0-41.41
linux-image-generic 6.8.0.41.44

Significado: Si DKMS construyó para un kernel pero arrancaste otro, los módulos no coincidirán y pueden fallar por razones no relacionadas con firmas.

Decisión: Asegúrate de que DKMS construyó para el kernel en ejecución. Si no, reconstruye DKMS para el kernel activo antes de firmar.

Tarea 14: Reconstruir DKMS para el kernel actual (cuando las salidas no coinciden)

cr0x@server:~$ sudo dkms autoinstall -k 6.8.0-41-generic
Sign command: /lib/modules/6.8.0-41-generic/build/scripts/sign-file
Signing key: /var/lib/shim-signed/mok/MOK.priv
Public certificate (MOK): /var/lib/shim-signed/mok/MOK.der

Building module:
Cleaning build area...
make -j16 KERNELRELEASE=6.8.0-41-generic...
Installing to /lib/modules/6.8.0-41-generic/updates/dkms/

Significado: Esta salida muestra una ruta saludable: DKMS conoce una clave de firma e invoca sign-file.

Decisión: Si la salida de DKMS no menciona firma en absoluto y Secure Boot está habilitado, necesitas configurar la integración de la clave de firma (o firmar módulos manualmente tras la compilación).

Tarea 15: Verificar la firma de un módulo a nivel de archivo (cuando modinfo es ambiguo)

cr0x@server:~$ sudo tail -c 256 /lib/modules/6.8.0-41-generic/updates/dkms/vboxdrv.ko | strings | tail -n 5
~Module signature appended~
PKCS#7
X.509
sha256

Significado: El módulo contiene un blob de firma añadido. Esto es burdo pero efectivo cuando necesitas prueba rápidamente.

Decisión: Si no hay marcador de firma, fírmalo. Si lo hay, pero es rechazado, tienes un desajuste de confianza/inscripción.

Tarea 16: Asegurarte de que completaste la inscripción MOK en el reinicio

cr0x@server:~$ sudo mokutil --test-key /var/lib/shim-signed/mok/MOK.der
/var/lib/shim-signed/mok/MOK.der is already enrolled

Significado: La clave está inscrita. Si aún recibes rechazos, probablemente estás firmando con una clave diferente, o el módulo no está firmado.

Decisión: Alinea “clave usada para firmar” con “clave inscrita.” Una clave privada, un certificado público inscrito, sin improvisaciones.

Vías de solución: elige la opción menos mala

Hay tres enfoques en el mundo real. Dos son defendibles. Uno es “me arrepentiré después”.

Camino A (mejor): Mantener Secure Boot activado, inscribir MOK, firmar módulos

Esto es lo que haces en sistemas de flota, portátiles corporativos y cualquier cosa que necesite una historia de seguridad limpia. También es lo que haces si no quieres que cada actualización del kernel rompa tus controladores de nuevo.

A grandes rasgos:

Genera un par de claves de firma (la privada permanece en la máquina, idealmente con permisos de sistema de ficheros apropiados).
Inscribe el certificado público mediante MOK.
Firma los módulos fuera del árbol (NVIDIA, VirtualBox, ZFS DKMS, módulos de proveedores).
Asegura que DKMS firme automáticamente en la reconstrucción, o añade un hook post-build.

Camino B (aceptable en ocasiones): Desactivar Secure Boot en el firmware

Esta es una decisión legítima cuando eres dueño del riesgo y necesitas que la máquina funcione ahora. Es común en estaciones de trabajo de laboratorio de propósito único, cajas air‑gapped o máquinas de hobby. También es habitual cuando tratas con ciertos agentes de seguridad de proveedores que no llevan bien el kernel lockdown.

Pero si haces esto en endpoints gestionados sin documentarlo, básicamente dejas una trampa para el siguiente ingeniero de guardia (que podría ser tú a las 2 AM).

Camino C (no lo hagas): “Forzar la carga” de módulos sin firmar

La gente busca parámetros de arranque y sysctls para evitar la aplicación. Ese camino es inconsistente entre kernels, a menudo bloqueado por lockdown y tiende a venirse abajo en la siguiente actualización. Además, acabarás con un estado del sistema no auditable.

Broma corta #1: Secure Boot no está “siendo exigente.” Simplemente hace el único trabajo para el que lo pedimos, a diferencia de la mitad del software que enviamos.

Listas de verificación / plan paso a paso

Esta sección es el plan “hazlo, no lo debatas”. Elige el escenario que coincida con tu sistema.

Escenario 1: Controlador NVIDIA instalado, pero bloqueado tras reiniciar

Confirma que el bloqueo está relacionado con firmas (Tareas 4 y 5). Si ves “Key was rejected by service,” estás en el lugar correcto.
Identifica la ruta del módulo (Tarea 6). Si está bajo updates/dkms, firmarás el módulo construido por DKMS.
Comprueba claves inscritas (Tarea 8) y si el módulo está firmado (Tarea 9).
Si falta la clave: inscríbete en MOK:
```
cr0x@server:~$ sudo update-secureboot-policy --new-key
Creating new MOK key pair...
Key created in /var/lib/shim-signed/mok/
Importing new key into MOK...
input password:
```
Significado: Ubuntu generó un par de claves y puso en cola el certificado público para inscripción. Pide una contraseña de una sola vez usada por el MOK Manager al arrancar.

Decisión: Reinicia ahora y completa la inscripción en la pantalla azul del MOK Manager. Si lo omites, nada cambia y perderás una hora culpando a la capa equivocada.
Después del reinicio, confirma la inscripción (Tarea 16).

Reconstruye + firma vía DKMS (Tarea 14). Luego carga el módulo:

cr0x@server:~$ sudo modprobe nvidia

Significado: Sin salida es éxito. Linux es educado así.

Decisión: Si se carga, verifica con:

cr0x@server:~$ nvidia-smi
Sat Dec 28 10:26:12 2025
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.90.07              Driver Version: 550.90.07      CUDA Version: 12.4   |
+---------------------------------------------------------------------------------------+

Significado: El controlador está activo.

Decisión: Hecho. No toques la configuración del firmware.

Escenario 2: Controlador de kernel de VirtualBox falla (“vboxdrv not loaded”)

Demuestra que es rechazo por firmas (Tarea 11).
Comprueba el estado de DKMS (Tarea 7).
Si DKMS no está instalado, instala el paquete correcto:
```
cr0x@server:~$ sudo apt-get install virtualbox-dkms
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  virtualbox-dkms
```
Significado: DKMS construirá módulos para tu kernel actual.

Decisión: Con Secure Boot activado, todavía debes asegurarte de que la firma esté en su lugar (inscripción MOK).
Inscribir/confirmar la clave MOK (Escenario 1, paso 4/5).

Reconstruir DKMS y confirmar firma (Tarea 14). Luego:

cr0x@server:~$ sudo modprobe vboxdrv

Significado: Éxito silencioso.

Decisión: Confirma que VirtualBox ve el controlador:

cr0x@server:~$ VBoxManage list hostinfo | sed -n '1,12p'
Host Information:
Host name:            server
Operating system:     Linux
Operating system version: Ubuntu 24.04.1 LTS
Processor online count: 16
VirtualBox kernel modules: loaded

Escenario 3: ZFS DKMS u otros módulos de almacenamiento no se cargan

Si ejecutas ZFS-on-Linux vía DKMS, Secure Boot puede morderte en el peor momento: cuando reinicias tras una actualización de kernel y tus pools no se importan porque el módulo no carga. Los incidentes de almacenamiento siempre llegan en el mejor momento.

Comprueba la falla al cargar el módulo:
```
cr0x@server:~$ sudo modprobe zfs
modprobe: ERROR: could not insert 'zfs': Key was rejected by service
```
Decisión: Esto es firma/inscripción, no “ZFS está roto”.

Confirma la ruta del módulo:

cr0x@server:~$ modinfo -n zfs
/lib/modules/6.8.0-41-generic/updates/dkms/zfs.ko

Confirma que tienes una clave inscrita y que DKMS está firmando (Tareas 8, 14, 16).

Tras la corrección, importa los pools:

cr0x@server:~$ sudo zpool import
   pool: tank
     id: 1034459023344556677
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        tank        ONLINE
          mirror-0  ONLINE
            sda     ONLINE
            sdb     ONLINE

Significado: El módulo del kernel está cargado y ZFS puede ver los discos.

Decisión: Procede a importar. Si los pools no aparecen, tienes un problema de detección de almacenamiento (HBA, multipath, cifrado), no de Secure Boot.

Escenario 4: No puedes arrancar el gráfico (pantalla negra) después de activar Secure Boot

A veces el síntoma “controlador bloqueado” se manifiesta como pantalla negra o un framebuffer de reserva. Esto es común cuando los módulos NVIDIA están bloqueados y el sistema intenta (y falla) recuperarse con elegancia.

Arranca en modo recuperación o en una consola de texto (intenta cambiar de TTY).
Confirma errores de firma vía dmesg (Tarea 5).
Si necesitas un retorno rápido a la GUI: usa temporalmente controladores abiertos o elimina paquetes conflictivos. Luego realiza el flujo correcto de firma para Secure Boot.

cr0x@server:~$ sudo apt-get purge 'nvidia*'
Reading package lists... Done
The following packages will be REMOVED:
  nvidia-dkms-550 nvidia-driver-550 ...

Significado: Estás eliminando el conjunto de módulos bloqueados para que el sistema pueda usar rutas no NVIDIA.

Decisión: Usa esto solo para recuperar el acceso. Luego reinstala NVIDIA con un plan de firma, no con esperanza a ciegas.

Tres microhistorias corporativas desde el campo

Microhistoria 1: El incidente causado por una suposición equivocada

La compañía tenía un estándar de estación de trabajo ordenado: Ubuntu LTS, Secure Boot activado, cifrado de disco en portátiles. Tenía sentido. Luego un equipo desplegó un paquete de controlador Wi‑Fi de un proveedor para varios portátiles nuevos porque el controlador en el kernel tenía peor rendimiento en una oficina con RF ruidoso.

La suposición fue casual y letal: “Si el paquete se instala limpio, el controlador se cargará.” Era verdad en su máquina de pruebas porque Secure Boot se había desactivado meses antes durante un intercambio de hardware y nadie lo documentó.

En producción, el nuevo controlador se instaló, DKMS construyó y todo parecía verde en los logs de despliegue. Tras la ventana de reinicio programada, los portátiles volvieron sin Wi‑Fi. No Wi‑Fi inestable. Ninguno. La gente usó tethering de teléfonos para asistir a reuniones, lo que indica que tenías un incidente real.

La causa raíz fue visible en cinco segundos de dmesg: “Key was rejected by service.” La solución no fue complicada—inscribir una MOK y firmar el módulo DKMS—pero la recuperación fue lenta porque las máquinas estaban remotas y la inscripción MOK requiere un paso interactivo en el reinicio. Acabaron desplegando un rollback temporal al controlador incluido en el kernel solo para recuperar conectividad, y luego hicieron el trabajo de firma en un segundo cambio controlado.

Lección: si tu despliegue depende de DKMS y Secure Boot está activado, no tienes un proceso de “instalación de controladores.” Tienes un proceso de “gestión de claves” que resulta en un controlador.

Microhistoria 2: La optimización que se volvió en contra

Un equipo de plataforma quería adopción más rápida de parches de kernel. Ajustaron el ritmo de actualizaciones para que las estaciones recibieran nuevos kernels rápidamente, y limpiaron kernels antiguos agresivamente para mantener los discos limpios y los menús de arranque cortos. Ordenado. Eficiente. A todos les encanta la eficiencia hasta que muerde.

También confiaban en un módulo de seguridad de endpoints fuera del árbol distribuido como paquete DKMS. Había sido firmado correctamente una vez, y todo funcionó durante meses. Luego la “optimización”: después de actualizaciones de kernel, forzaban reinicios inmediatos para reducir el tiempo de exposición. La ventana entre “DKMS construyó un módulo” y “la máquina reinició en un kernel nuevo” se hizo mucho más corta.

Un subconjunto de máquinas reinició en el kernel nuevo antes de que el paso post‑instal de DKMS completara la firma—or antes de que la clave de firma estuviera disponible por un desvío de configuración. El resultado fue una interrupción dispersa: el agente de seguridad no se cargó y el escáner de cumplimiento marcó los endpoints como “no protegidos”.

Habían creado un bug de fiabilidad apretando el tiempo. La solución no fue ralentizar todas las actualizaciones; fue hacer la firma determinística y observable. Añadieron una puerta: si el módulo firmado esperado no está presente para el kernel objetivo, se pospone el reinicio. Aburrido, sí. Efectivo, absolutamente.

Lección: velocidad no es lo mismo que control. Si un proceso incluye criptografía y políticas del kernel, elimina condiciones de carrera o ellas te eliminarán a ti.

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

Un equipo de almacenamiento ejecutaba ZFS en una flota de servidores Ubuntu para artefactos de build. No era a la moda, pero funcionaba. También tenían una regla estricta: cada servidor tenía un playbook “romper el cristal” impreso en su runbook, incluyendo comprobaciones de estado de Secure Boot, procedimientos de inscripción MOK y un pequeño conjunto de kernels conocidos y buenos retenidos de la autopurgación.

Un día, un update de firmware se desplegó desde el proveedor de hardware. Tras esa actualización, un puñado de servidores volvieron con Secure Boot activado cuando antes estaba desactivado (o al revés, según el modelo). El síntoma inmediato fue simple: tras el reinicio, ZFS no se cargaba en dos nodos. Los pools estaban bien. Los discos estaban bien. El kernel estaba exigiendo firmas y el módulo ZFS construido por DKMS no era de confianza.

Porque tenían un proceso aburrido, la respuesta fue aburrida también: comprobar estado de Secure Boot, confirmar rechazo de firma, inscribir la MOK correcta, reconstruir DKMS, firmar, verificar carga, importar pools. Sin “fsck” en pánico, sin experimentos aleatorios en la ruta de datos, sin degradar producción por capricho.

Tomó esfuerzo, porque la inscripción de claves es interactiva, pero evitaron el gran modo de fallo: hacer cambios desesperados en la pila de almacenamiento mientras el sistema ya estaba degradado. Recuperaron el servicio sin daños colaterales, que es el único tipo de recuperación que vale la pena celebrar.

Lección: la mejor herramienta de respuesta a incidentes es el runbook que escribiste cuando estabas aburrido.

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

1) “Controlador instalado, pero dispositivo ausente tras reinicio”

Síntoma: GPU/Wi‑Fi/VirtualBox parece bien hasta el reinicio; luego el módulo no carga.

Causa raíz: Secure Boot activado + módulo sin firmar/no confiable, por lo que se rechaza en tiempo de carga.

Solución: Usa mokutil --sb-state, lee dmesg buscando “Key was rejected by service,” inscribe MOK, firma el módulo (o desactiva Secure Boot deliberadamente).

2) “Inscribí una MOK pero aún falla”

Síntoma: Realizaste un paso de inscripción MOK, pero los módulos siguen rechazándose.

Causa raíz: Inscribiste un certificado público distinto de la clave privada usada para firmar, o nunca completaste la UI del MOK Manager en el reinicio.

Solución: Ejecuta mokutil --test-key sobre el certificado que crees inscrito. Confirma que modinfo muestra el firmante correcto. Si hay desajuste, vuelve a firmar con la clave inscrita o reinscribe el certificado correcto.

3) “DKMS dice installed, así que debe funcionar”

Síntoma: dkms status muestra “installed,” pero el módulo falla al cargarse.

Causa raíz: DKMS installed solo significa “construido y copiado,” no “confiable bajo Secure Boot”.

Solución: Confirma la firma con modinfo. Configura la firma de DKMS (herramientas de Ubuntu vía update-secureboot-policy, o tus propios hooks de firma).

4) “Pantalla negra tras activar Secure Boot”

Síntoma: El sistema arranca a pantalla negra; el TTY puede funcionar.

Causa raíz: Módulo GPU bloqueado; el gestor de pantalla arranca sin aceleración hardware o falla.

Solución: Arranca a recuperación/TTY, inspecciona dmesg, o bien elimina temporalmente el controlador problemático o fírmalo correctamente y asegúrate de la inscripción de la clave.

5) “Tras actualización de firmware, todo se rompió”

Síntoma: Módulos DKMS previamente estables ahora rechazados, el estado de Secure Boot parece haber cambiado.

Causa raíz: El firmware restableció o alternó Secure Boot o alteró el estado de claves; puede que se requiera reinscripción MOK o que el flujo de arranque cambió.

Solución: Confirma con mokutil --sb-state y bootctl status. Reinscribe MOK si es necesario; verifica keyrings; vuelve a firmar módulos.

6) “Desactivé Secure Boot, pero sigue diciendo ‘rejected’”

Síntoma: Aseguras que Secure Boot está apagado, pero los módulos aún fallan.

Causa raíz: Cambiaste la entrada de firmware equivocada (algunos UEFI tienen ajustes separados), o estás arrancando una entrada de arranque diferente, o confundes Secure Boot con kernel lockdown causado por otras configuraciones.

Solución: Verifica el estado desde el OS (mokutil --sb-state) y comprueba el modo UEFI. No confíes solo en la UI del firmware.

7) “Firmé el módulo pero las actualizaciones lo rompen otra vez”

Síntoma: Funciona hasta la siguiente actualización del kernel; luego se rompe.

Causa raíz: DKMS rebuild crea un nuevo módulo sin firmar en cada instalación de kernel; tu firma fue manual y no automatizada.

Solución: Integra la firma con DKMS (asegura que la clave de firma exista donde DKMS la espera; verifica que la salida de DKMS incluya firma). Añade comprobaciones operativas antes de reiniciar en un kernel nuevo.

Broma corta #2: La forma más rápida de aprender sobre Secure Boot es ignorarlo una vez, y luego programar tu sesión de aprendizaje para el siguiente reinicio.

Preguntas frecuentes

1) ¿Simplemente debería desactivar Secure Boot?

Si es una máquina personal y aceptas el intercambio, sí—es una elección válida. En sistemas gestionados, es preferible mantener Secure Boot activado y firmar módulos. Desactivar Secure Boot es fácil; defenderlo después no lo es.

2) ¿Qué es MOK, en términos sencillos?

MOK (Machine Owner Key) es una forma de añadir tu propio certificado de firma confiable en la cadena de confianza de arranque sin reescribir las claves de plataforma del firmware. Inscribes un certificado público; luego el kernel confía en los módulos firmados por la clave privada correspondiente.

3) ¿Por qué Ubuntu bloquea módulos que están “instalados correctamente”?

Porque “instalado” significa que los archivos están en disco. La aplicación de Secure Boot trata de si esos archivos son confiables en tiempo de carga. El kernel hace cumplir la política; los gestores de paquetes no anulan esa política.

4) ¿Cómo sé si es Secure Boot y no un controlador roto?

Busca “Key was rejected by service” o “module verification failed: signature and/or required key missing” en dmesg. También comprueba mokutil --sb-state. Si Secure Boot está desactivado, tu fallo probablemente tiene otra causa.

5) ¿Firmar módulos “reduce la seguridad”?

Cambia el límite de confianza. Le estás diciendo al kernel que confíe en código firmado por tu clave. Eso está bien si proteges la clave privada y controlas lo que se firma. Es mejor que desactivar Secure Boot por completo.

6) ¿Y NVIDIA específicamente—por qué siempre aparece?

Porque el controlador está fuera del árbol y a menudo se construye con DKMS. Esa combinación significa que nuevos kernels disparan reconstrucciones, las reconstrucciones requieren firma, y la firma requiere una clave inscrita. Si faltas en cualquiera de esos pasos, se rompe en el reinicio.

7) ¿Puedo firmar módulos en una máquina y desplegarlos a otras?

Puedes, pero cuidado: las máquinas destino deben confiar en el certificado de firma (MOK inscrito en todas ellas), y necesitas un proceso seguro para proteger la clave de firma. En flotas, esto se convierte en trabajo de PKI y aprovisionamiento—hazlo deliberadamente o no lo hagas.

8) ¿Qué pasa si perdí la clave privada usada para firmar módulos?

Genera un nuevo par de claves, inscribe el nuevo certificado público (MOK), luego vuelve a firmar los módulos con la nueva clave privada. Elimina claves antiguas si intentas mantener el conjunto de confianza restringido.

9) ¿Por qué la inscripción MOK requiere un reinicio interactivo?

Porque la inscripción forma parte del proceso de confianza de arranque. El firmware/shim presenta la UI del MOK Manager para confirmar que realmente pretendías añadir una clave. Es una decisión de diseño anti‑malware, no una característica de usabilidad.

10) ¿Cómo evito que esto vuelva a pasar en actualizaciones de kernel?

Asegura que la firma de DKMS sea automática y verificable. Tu proceso debería incluir: después de instalar un kernel, verificar que DKMS construyó módulos para ese kernel y que están firmados, luego reiniciar. Si no puedes verificar la firma, no reinicies todavía.

Conclusión: próximos pasos prácticos

Ubuntu 24.04 más Secure Boot no es frágil—es estricto. Tus controladores no están “fallando aleatoriamente.” Están siendo rechazados porque no son confiables según la política de arranque actual.

Haz esto a continuación, en orden:

Ejecuta mokutil --sb-state y confirma que estás en modo UEFI.
Intenta cargar el módulo que falla y captura el error exacto.
Lee dmesg para confirmar el rechazo por firma.
Elige una estrategia: inscribir MOK + firmar (preferido), o desactivar Secure Boot (riesgo aceptado explícitamente).
Si firmas: confirma la inscripción, confirma el firmante del módulo y automatiza la firma en DKMS antes de permitir que las actualizaciones de kernel reinicien tu sistema.

Si tratas Secure Boot como una política que gestionas—no como una casilla que temes—obtendrás el mejor resultado: cadena de arranque segura, controladores que funcionan y actualizaciones que no se convierten en cortes sorpresa.