La forma más rápida de arruinar un día perfecto es mezclar una instalación nueva de Linux, controladores NVIDIA y Secure Boot,
y suponer que las opciones por defecto te salvarán. No lo harán. Funcionarán la mayoría de las veces, hasta que llegue la primera actualización del kernel,
el primer monitor externo, o el momento en que necesites que tu portátil suspenda y reanude como un adulto responsable.
Esta es una guía de instalación orientada a producción para Pop!_OS 24.04 LTS: arranque predecible, comportamiento NVIDIA conocido-bueno,
y un escritorio lo bastante limpio como para permanecer así. Si quieres “ajustes bonitos”, podrás hacerlo después—cuando tengas registros.
Decisiones primero: elige tus batallas (y tu cadena de arranque)
Una instalación limpia de Pop!_OS no es difícil. Una instalación limpia de Pop!_OS que sobreviva a actualizaciones del kernel con NVIDIA y Secure Boot
es un pequeño ejercicio de diseño de sistemas. Necesitas decidir qué estás optimizando:
- Postura de seguridad: ¿requieres la aplicación de Secure Boot? (Política corporativa, measured boot, entornos regulados.)
- Postura de fiabilidad: ¿Necesitas comportamiento predecible de los controladores tras las actualizaciones? (Tiempo de actividad de estación de trabajo, usuarios remotos, sin babysitting.)
- Postura temporal: ¿Necesitas “funciona esta noche” más que “probablemente correcto”? (Aún necesitas registros.)
Aquí está la rúbrica honesta:
- Si esto es una estación de trabajo personal y controlas la máquina físicamente, desactivar Secure Boot suele ser la opción menos dolorosa.
- Si esto es un portátil corporativo con Secure Boot obligatorio, debes o (a) usar módulos firmados por una cadena de confianza del proveedor/distro,
o (b) inscribir tu propia Machine Owner Key (MOK) y firmar los módulos de NVIDIA tú mismo. - Si usas gráficos híbridos (iGPU Intel/AMD + dGPU NVIDIA), el enfoque de “forzar NVIDIA todo el tiempo” es como obtener
autonomía medida en pausas para café.
Una verdad seca: Secure Boot no está para facilitarte la vida. Está para dificultarle la vida a tu atacante, y lo consigue siendo quisquilloso.
El módulo del kernel que controla tu GPU es exactamente el tipo de cosa que Secure Boot desconfía por defecto.
Hechos interesantes y contexto (para que lo raro tenga sentido)
- UEFI Secure Boot llegó a PCs mainstream a principios de los 2010, mayormente para prevenir bootkits que manipulan antes de que cargue el SO.
- El controlador NVIDIA en Linux ha sido históricamente privativo, lo que complica cómo las distros lo integran con flujos de trabajo de kernel abierto.
- DKMS (Dynamic Kernel Module Support) existe para que módulos de terceros se reconstruyan automáticamente cuando el kernel se actualiza—genial hasta que Secure Boot rechaza el módulo reconstruido.
- nouveau es el controlador comunitario para GPUs NVIDIA; es suficiente para pantalla básica en muchas tarjetas, pero no reemplaza a CUDA en trabajos exigentes.
- Wayland lleva años siendo el futuro de los escritorios Linux; el soporte de NVIDIA mejoró sustancialmente en generaciones recientes de controladores, pero quedan casos límite.
- systemd-boot es un gestor de arranque UEFI simple; Pop!_OS tradicionalmente lo prefiere, lo cual es rápido y limpio—hasta que necesitas manejar múltiples SO.
- Encriptación LUKS de disco completo es madura y aburrida ahora, y eso es exactamente lo que quieres de la encriptación.
- El cambio entre gráficos híbridos en Linux solía ser un desastre. Ahora es mayormente manejable con las herramientas correctas y expectativas realistas.
Preflight: verifica modo de firmware, discos y qué GPU tienes realmente
Antes de escribir nada en disco, recopila hechos. No estás siendo paranoico; estás siendo rápido.
La mayoría de las fallas “misteriosas” son simplemente hardware no documentado y modo de arranque confuso.
Conoce tu modo de arranque: UEFI o legacy
Quieres UEFI. No porque esté de moda, sino porque Secure Boot y las entradas de arranque limpias son más fáciles de razonar.
Si estás accidentalmente en modo legacy, puedes perder una tarde persiguiendo fantasmas.
Conoce tu topología de GPU
“Tengo una GPU NVIDIA” no es suficiente. ¿Es la única GPU, o estás en un portátil híbrido con una iGPU?
La estrategia de controladores es diferente. El comportamiento de energía es diferente. El comportamiento del monitor es diferente.
Conoce el layout de discos y qué estás dispuesto a borrar
La instalación de Pop!_OS es indolora cuando la respuesta es “borrar todo el disco”. No lo es cuando preservas
una partición Windows, un volumen home de Linux antiguo o un entorno de recuperación corporativo.
Medio de instalación hecho como se debe
Descarga el ISO correcto. Pop!_OS normalmente ofrece una variante NVIDIA y otra Intel/AMD. Si tienes una GPU NVIDIA,
el ISO NVIDIA suele ser la elección correcta porque reduce fallos de pantalla en el arranque temprano y te evita la danza de la primera instalación del controlador.
Ahora haz la parte poco glamorosa: valida lo que descargaste, grábalo limpiamente y arráncalo en el modo que esperas.
La cantidad de reportes de “el instalador de Linux está roto” que en realidad son “USB creado mal” no es pequeña.
Broma #1: Las unidades USB tienen un trabajo, y aún así lo tratan como una sugerencia.
Secure Boot + NVIDIA: tres estrategias viables
Aquí están las tres vías que no terminan en lágrimas. Elige una y cúmplela. Mezclarlas en vuelo es cómo consigues una máquina que arranca
solo cuando la luna está en la fase correcta.
Estratagema A: Desactivar Secure Boot (más rápido, menos frágil)
Si posees el hardware y no tienes un requisito de política, desactiva Secure Boot en el firmware.
La ventaja: las reconstrucciones DKMS de NVIDIA no serán bloqueadas. Las actualizaciones del kernel te sorprenderán menos.
La desventaja: pierdes esa capa de verificación de integridad previa al SO.
Estratagema B: Mantener Secure Boot, usar módulos firmados vía integración proveedor/distro (mejor cuando existe)
En un mundo perfecto, los módulos del kernel de NVIDIA instalados en tu sistema están firmados con una clave de confianza en tu firmware.
Cuando eso ocurre, Secure Boot sigue activado y la vida es buena. Cuando no, tu sistema arranca con un controlador básico de pantalla o falla al cargar el módulo NVIDIA.
Si lo obtienes “gratis” depende del empaquetado, la variante del kernel y cómo Pop!_OS integra NVIDIA en 24.04 LTS.
Planea verificar en lugar de asumir.
Estratagema C: Mantener Secure Boot, inscribir tu propio MOK y firmar módulos NVIDIA (más control, más trabajo)
Esta es la respuesta amigable para empresas cuando no puedes desactivar Secure Boot pero necesitas el módulo propietario de NVIDIA.
Generas un par de claves, inscribes la clave pública vía MOK y firmas los módulos del kernel después de que se construyen.
Aquí también es donde la gente recorta pasos y luego descubre que “actualización del kernel” es un evento recurrente, no una molestia de una sola vez.
Automatiza el paso de firmado o acepta que alguien lo olvidará a las 2 a.m.
Listas de verificación / plan paso a paso: instalación limpia hasta el primer arranque
Lista de verificación: antes de iniciar el instalador
- Confirma que la máquina arranca en modo UEFI.
- Decide la estrategia Secure Boot (A/B/C arriba).
- Si haces arranque dual, identifica qué disco/partición es seguro borrar.
- Tén a mano un segundo dispositivo para cambiar firmware y pasos de recuperación.
Lista de verificación: opciones del instalador que importan
- Encriptación de disco: actívala si es un portátil o cualquier máquina que salga de tu mesa.
- /home separado: opcional; para la mayoría de escritorios, una raíz cifrada única está bien. /home separado ayuda si reinstalas con frecuencia.
- Swap: asegúrate de tener swap suficiente para hibernación si planeas usarla; de lo contrario no te obsesiones.
Lista de verificación: primer arranque tras la instalación
- Actualiza el sistema completamente antes de empezar a afinarlo.
- Verifica qué controlador GPU está activo y si la aceleración funciona.
- Sólo entonces ajusta Wayland/Xorg, el modo de gráficos híbridos y la limpieza del escritorio.
Endurecimiento post-instalación: controladores, actualizaciones y comprobaciones de cordura
Pop!_OS facilita llegar a un escritorio funcional. Tu trabajo es mantenerlo funcional tras las actualizaciones.
Eso significa verificar la pila de controladores, mantener el firmware en buen estado y asegurarte de que existen registros cuando algo vaya mal.
Wayland vs Xorg: elige según tu carga de trabajo
Si haces captura de pantalla intensiva, gestores de ventanas nicho o flujos de trabajo de escritorio remoto, Xorg puede seguir siendo la ruta con menos sorpresas.
Si quieres mejor manejo multi-monitor y propiedades de seguridad modernas, Wayland es la dirección a seguir.
En NVIDIA, ambos pueden funcionar—hasta que no—así que valida con tu carga real, no con una demo.
Actualizaciones del kernel: la trampa predecible
El módulo de NVIDIA debe coincidir con tu kernel. Si actualizas el kernel y el módulo NVIDIA no se construye o carga,
obtienes una estación de trabajo “funcionaba el martes, rota el miércoles”. Por eso hacemos tareas de verificación con comandos.
Un escritorio limpio: qué eliminar, qué conservar y por qué
Limpio no significa mínimo. Limpio significa que puedes decir qué cambió, puedes deshacerlo y puedes diagnosticarlo.
El patrón antiestético número uno en escritorios es la “acumulación de ajustes aleatorios” hasta que no sabes qué perilla causó la regresión.
Lo que conservo
- Una terminal: y la fijo. Si tu terminal se mueve, pierdes tiempo.
- Un flujo de actualizaciones: GUI o CLI, elige uno como fuente de la verdad.
- Una política de modo gráfico: integrado para batería, NVIDIA para rendimiento, híbrido cuando realmente lo necesites.
- Registros y herramientas: acceso al journal, paquetes de diagnóstico básicos y el hábito de revisarlos.
Lo que elimino o desactivo
- Autoarranques innecesarios que generan ruido de fondo y notificaciones confusas.
- Tiendas de apps redundantes o mecanismos de actualización que se pelean entre sí.
- Extensiones de shell experimentales a menos que estés dispuesto a depurar roturas de GNOME tras las actualizaciones.
Broma #2: Las extensiones de escritorio son como mascotas—ámalas, aliméntalas y espera que rompan algo caro cuando no miras.
Gráficos híbridos y portátiles: deja de pelear con tu GPU
En portátiles híbridos, tu iGPU suele estar cableada a las pantallas internas y tu dGPU está para ráfagas de rendimiento.
Forzar NVIDIA todo el tiempo puede:
- aumentar el consumo en reposo,
- hacer la suspensión/reanudación menos fiable,
- introducir comportamientos extraños con pantallas externas según el diseño del mux del portátil.
El enfoque correcto es basado en políticas:
- Por defecto: gráficos integrados para trabajo normal.
- Bajo demanda: ejecutar aplicaciones específicas en NVIDIA.
- Modo NVIDIA completo: solo si estás en un dock, enchufado y realmente empujando píxeles.
Guía de diagnóstico rápido
Cuando algo falla—pantalla negra, FPS bajos, monitor externo muerto, suspensión rota—no empieces reinstalando.
Empieza por acotar el cuello de botella. Es la misma mentalidad que en respuesta a incidentes de producción: aislar la capa.
Primero: ¿el módulo del kernel está cargado y saludable?
- Comprueba si el controlador NVIDIA está presente y cargado.
- Comprueba si Secure Boot lo está bloqueando.
- Comprueba si nouveau se apoderó del dispositivo.
Segundo: ¿la ruta del servidor de pantalla es coherente (Wayland/Xorg) y coincide con tu controlador?
- Identifica el tipo de sesión (Wayland vs X11).
- Confirma que el compositor usa aceleración GPU.
Tercero: ¿es un problema de firmware/cadena de arranque?
- Verifica las entradas UEFI y que estás arrancando lo que piensas que arrancas.
- Revisa actualizaciones recientes del kernel y fallos de compilación DKMS.
Cuarto: ¿es un problema de topología hardware (híbrido/mux/puertos externos)?
- Mapea qué GPU controla qué salidas de pantalla.
- Decide si necesitas modo integrado, híbrido o NVIDIA.
Idea parafraseada de Werner Vogels (CTO de Amazon): construyes sistemas asumiendo que fallan, y diseñas para que los fallos sean sobrevivibles.
Errores comunes: síntomas → causa raíz → solución
1) Arranca a pantalla negra después de una actualización
Síntomas: el sistema arranca, retroiluminación encendida, quizá un cursor, sin escritorio.
Causa raíz: el módulo NVIDIA no se cargó (DKMS falló) o Secure Boot lo bloqueó; el servidor de pantalla cae en un controlador pobre.
Solución: arranca con un kernel anterior si está disponible, inspecciona el estado de DKMS y Secure Boot, reinstala el controlador NVIDIA y asegúrate de firmar módulos si Secure Boot permanece activado.
2) “Usando llvmpipe” o rendimiento terrible
Síntomas: animaciones entrecortadas, aplicaciones GPU-intensivas lentas, glxinfo muestra renderizado por software.
Causa raíz: controlador no cargado; Xorg/Wayland funcionando sin aceleración GPU; GPU equivocada seleccionada en sistema híbrido.
Solución: verifica el módulo del kernel nvidia, asegúrate del tipo de sesión correcto, selecciona el modo gráfico apropiado y confirma con nvidia-smi.
3) Monitor externo no detectado en dock de portátil
Síntomas: el monitor funciona en Windows, no en Pop!_OS; o solo funciona en modo NVIDIA.
Causa raíz: el puerto está cableado a una GPU específica; el dock usa DisplayLink; o la ruta del compositor difiere en Wayland.
Solución: identifica el cableado con lspci/inxi y prueba modos; si es DisplayLink, instala la pila de controladores adecuada; de lo contrario usa el modo GPU que controle el puerto.
4) Secure Boot activado, controlador NVIDIA “instala” pero nunca carga
Síntomas: paquetes instalados, pero modprobe nvidia falla; los logs mencionan “Required key not available.”
Causa raíz: módulo del kernel sin firmar bloqueado por Secure Boot.
Solución: desactiva Secure Boot, o inscribe MOK y firma módulos, o usa paquetes firmados si están disponibles en tu entorno.
5) Suspensión/reanudación falla o los ventiladores no paran
Síntomas: el portátil despierta con pantalla negra; la batería se drena durante el sueño; los ventiladores giran.
Causa raíz: la dGPU no se apaga correctamente, configuración de energía/driver desajustada, modo híbrido mal configurado.
Solución: prueba integrado vs híbrido vs modo NVIDIA; asegúrate de la versión correcta del controlador NVIDIA; revisa los logs alrededor de suspensión/reanudación y considera desactivar la hibernación si no es necesaria.
Tres mini-historias corporativas desde el frente
Incidente causado por una suposición errónea: “Secure Boot está activado, así que los controladores deben estar bien”
Una compañía desplegó un lote de portátiles Linux para un equipo que hacía analítica acelerada por GPU y desarrollo ligero en CUDA.
La imagen base era en espíritu similar a Pop!_OS: escritorio moderno, controladores NVIDIA preinstalados, encriptación activada.
En pruebas parecía bien. Todo el mundo podía iniciar sesión, abrir un terminal y correr un par de cargas de muestra.
La suposición errónea fue sutil: asumieron que porque Secure Boot estaba activado y el sistema arrancó limpio,
el módulo del kernel NVIDIA también estaba confiable y cargándose. En las máquinas de prueba, una configuración de firmware particular
era menos estricta; en el lote de producción, la aplicación de Secure Boot fue más rigurosa.
Llegó la primera actualización del kernel. La mitad de la flota volvió con renderizado por software y monitores externos rotos.
Los usuarios abrieron tickets tipo “Linux está lento ahora” y “el dock dejó de funcionar”, que es cómo se ven las interrupciones reales: síntomas vagos,
opiniones contundentes y sin pasos reproducibles.
La solución no fue difícil, pero la respuesta fue desordenada porque el equipo no tenía una estrategia acordada de Secure Boot.
Algunos dispositivos tenían Secure Boot desactivado a la ligera. Otros tenían una MOK inscrita manualmente. Unos pocos quedaron medio configurados,
lo que significó que la siguiente actualización los rompió otra vez.
La lección: no puedes omitir la cadena de arranque. O diseñas para Secure Boot con firmado de módulos como flujo de trabajo de primera clase,
o lo desactivas intencionalmente y documentas por qué. “No lo tocamos” no es una estrategia.
Optimización que salió mal: “Forzar modo NVIDIA en todas partes por rendimiento”
Otra organización estandarizó portátiles con gráficos híbridos. Un ingeniero con buenas intenciones puso el valor por defecto en modo solo NVIDIA,
argumentando que reduciría la “rareza gráfica” y haría el rendimiento consistente para videollamadas y aceleración del navegador.
En la pizarra sonaba ordenado.
En la práctica, la batería se hundió. Los usuarios empezaron a llevar cargadores como talismanes. Las fallas de suspensión/reanudación aumentaron,
pero las fallas fueron lo bastante intermitentes como para descartarlas como “Linux siendo Linux” hasta que suficientes personas se quejaron.
Lo peor: el cambio hizo más difícil la depuración. Cuando todo corre en la dGPU, no puedes distinguir fácilmente
“problema del compositor” de “problema de gestión de energía”. Todo parece un “problema de GPU”.
Revirtieron a integrado por defecto con offload bajo demanda para apps específicas pesadas.
El rendimiento siguió siendo aceptable para uso normal, y el sistema volvió a comportarse como un portátil.
La lección: optimizar una estación de trabajo para una sola métrica (“GPU máxima siempre”) a menudo solo traslada el dolor a otro sitio.
Batería, térmicas y suspensión son características de fiabilidad, no adornos.
Práctica aburrida pero correcta que salvó el día: “Una baseline conocida y un script de validación”
Un tercer equipo gestionaba una flota mixta: algunos escritorios con NVIDIA único, algunos portátiles híbridos,
y unas pocas máquinas con Secure Boot obligado por política.
Hicieron una cosa consistentemente: mantuvieron una lista de instalación baseline y un pequeño script de validación.
La validación no era sofisticada. Comprobaba estado de Secure Boot, versión del kernel, carga del módulo NVIDIA, tipo de sesión (Wayland/Xorg),
y si la aceleración hardware realmente estaba activa. También recogía logs relevantes en un tarball
que los usuarios podían adjuntar a tickets sin un ida y vuelta de dos horas.
Cuando una actualización causó un desajuste de controladores en un subconjunto de máquinas, no discutieron sensaciones.
Compararon salidas de validación y vieron inmediatamente que las compilaciones DKMS habían fallado en sistemas sin headers del kernel.
Eso no es glamoroso. Es simplemente correcto.
Arreglaron la imagen, actualizaron la checklist para asegurar que los headers estuvieran presentes, y el problema dejó de repetirse.
Nadie celebró, y así sabes que fue una buena práctica operativa.
La lección: la repetibilidad aburrida vence a la resolución heroica. Siempre.
Tareas prácticas: comandos, salidas y la decisión que tomas
Estas son las tareas que realmente ejecuto cuando quiero tener confianza. Cada una incluye: el comando, qué significa la salida y qué decides después.
Ejecútalas en orden cuando estés construyendo un sistema nuevo, o salta durante un incidente.
Task 1: Confirmar que arrancaste en modo UEFI
cr0x@server:~$ test -d /sys/firmware/efi && echo "UEFI boot" || echo "Legacy boot"
UEFI boot
Significado: “UEFI boot” indica que estás en modo UEFI y las variables UEFI son accesibles.
Decisión: Si ves “Legacy boot”, detente y arregla la configuración del firmware antes de depurar Secure Boot o entradas de arranque.
Task 2: Comprobar estado de Secure Boot
cr0x@server:~$ mokutil --sb-state
SecureBoot enabled
Significado: Secure Boot está aplicado.
Decisión: Si está activado, elige la Estrategia B o C. Si tu módulo NVIDIA no está firmado, será bloqueado.
Task 3: Identificar GPUs presentes
cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|display'
00:02.0 VGA compatible controller [0300]: Intel Corporation Raptor Lake-P [8086:a7a0]
01:00.0 3D controller [0302]: NVIDIA Corporation GA107M [GeForce RTX 3050 Mobile] [10de:25a2]
Significado: Esto es un sistema híbrido (iGPU Intel + dGPU NVIDIA).
Decisión: Planifica tu modo gráfico (integrado/híbrido/NVIDIA). No asumas que “NVIDIA todo el tiempo” es lo mejor.
Task 4: Ver qué controlador está vinculado al dispositivo NVIDIA
cr0x@server:~$ sudo lshw -c display -short
H/W path Device Class Description
=========================================================
/0/100/2 /dev/fb0 display Intel Corporation Raptor Lake-P
/0/100/1/0 display NVIDIA Corporation GA107M [GeForce RTX 3050 Mobile]
Significado: El hardware está detectado. Esto no prueba que el módulo del kernel NVIDIA esté activo para renderizado.
Decisión: Continúa con comprobaciones de módulos y validación de aceleración.
Task 5: Confirmar que el módulo del kernel NVIDIA está cargado
cr0x@server:~$ lsmod | grep -E '^nvidia'
nvidia 9994240 120
nvidia_drm 86016 12
nvidia_modeset 1605632 18 nvidia_drm
Significado: Los módulos NVIDIA están cargados en el kernel en ejecución.
Decisión: Si no hay coincidencias, o no estás usando NVIDIA, el módulo falló en cargar o Secure Boot lo bloqueó. Revisa los logs a continuación.
Task 6: Si el módulo no está cargado, ver por qué (log del kernel)
cr0x@server:~$ sudo dmesg -T | egrep -i 'nvidia|nouveau|secure|signature|key' | tail -n 20
[Mon Feb 5 10:12:03 2026] nvidia: loading out-of-tree module taints kernel.
[Mon Feb 5 10:12:03 2026] nvidia: module verification failed: signature and/or required key missing - tainting kernel
Significado: La verificación de firma del módulo falló. En sistemas con Secure Boot puedes ver en su lugar “Required key not available” y el módulo no cargará.
Decisión: Si Secure Boot está activado, procede con inscripción MOK y firmado o desactiva Secure Boot.
Task 7: Confirmar si nouveau está activo (a menudo no debería)
cr0x@server:~$ lsmod | grep nouveau
nouveau 2387968 0
drm_ttm_helper 16384 1 nouveau
ttm 102400 2 drm_ttm_helper,nouveau
Significado: nouveau está cargado.
Decisión: Si piensas usar el controlador propietario NVIDIA, normalmente quieres deshabilitar/poner en blacklist nouveau y que se cargue el módulo NVIDIA en su lugar.
Task 8: Comprobar qué tipo de sesión estás ejecutando (Wayland vs X11)
cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland
Significado: Estás en Wayland.
Decisión: Si tienes problemas de pantalla con NVIDIA, prueba una sesión X11 para aislar problemas de compositor vs driver.
Task 9: Validar la ruta de aceleración con el renderer OpenGL
cr0x@server:~$ glxinfo -B | egrep 'OpenGL renderer|OpenGL vendor|direct rendering'
direct rendering: Yes
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: NVIDIA GeForce RTX 3050 Laptop GPU/PCIe/SSE2
Significado: La aceleración hardware vía NVIDIA está activa (al menos para este camino GL).
Decisión: Si ves “llvmpipe” o vendor “Mesa”, estás en renderizado por software o iGPU; revisa carga de módulos y modo gráfico.
Task 10: Confirmar que la pila del controlador NVIDIA ve la GPU
cr0x@server:~$ nvidia-smi
Tue Feb 5 10:14:44 2026
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14 Driver Version: 550.54.14 CUDA Version: 12.4 |
|-----------------------------------------+------------------------+--------------------|
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| 0 GeForce RTX 3050 ... Off | 00000000:01:00.0 Off | N/A |
+-----------------------------------------+------------------------+--------------------+
Significado: El controlador está instalado y comunicándose con la GPU.
Decisión: Si esto falla, enfócate en el estado de instalación del controlador, errores de carga del módulo y bloqueo por Secure Boot.
Task 11: Inspeccionar estado DKMS (¿una actualización del kernel rompió la compilación del módulo?)
cr0x@server:~$ dkms status
nvidia/550.54.14, 6.8.0-49-generic, x86_64: installed
Significado: DKMS construyó e instaló el módulo para el kernel en ejecución.
Decisión: Si ves “added” o “build error”, arregla headers/toolchain y reconstruye antes de reiniciar en un kernel más nuevo.
Task 12: Asegurar que existen headers del kernel para el kernel en ejecución
cr0x@server:~$ uname -r
6.8.0-49-generic
cr0x@server:~$ dpkg -l | grep -E "linux-headers-$(uname -r)" | awk '{print $2, $3}'
linux-headers-6.8.0-49-generic 6.8.0-49.49
Significado: Los headers están instalados para el kernel activo.
Decisión: Si faltan, instala headers antes de intentar reconstruir módulos NVIDIA (especialmente tras actualizaciones).
Task 13: Comprobar entradas de arranque (sanidad para multi-boot y “¿por qué arrancó lo equivocado?”)
cr0x@server:~$ sudo efibootmgr -v | head -n 8
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0000
Boot0003* Pop!_OS HD(1,GPT,3b7c3d5a-7ed5-4f5b-a2e0-9f2e1b0e1e4a,0x800,0x100000)/File(\EFI\systemd\systemd-bootx64.efi)
Boot0001* Windows Boot Manager HD(1,GPT,3b7c3d5a-7ed5-4f5b-a2e0-9f2e1b0e1e4a,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)
Significado: Puedes ver qué gestor de arranque estás usando realmente y el orden de arranque.
Decisión: Si el firmware sigue arrancando Windows o una entrada antigua, corrige BootOrder. No sigas reinstalando el SO esperando que aprenda modales.
Task 14: Revisar el journal por errores de NVIDIA y del gestor de pantalla (último arranque)
cr0x@server:~$ sudo journalctl -b -p err --no-pager | egrep -i 'nvidia|gdm|sddm|wayland|xorg|drm' | head -n 30
Feb 05 10:11:58 cr0x kernel: nvidia_drm: loading out-of-tree module taints kernel.
Feb 05 10:11:59 cr0x gdm[1189]: GdmDisplay: Session never registered, failing
Significado: Existen errores alrededor de NVIDIA y/o el inicio del display.
Decisión: Si el gestor de pantalla falla, prueba cambiar el tipo de sesión o reinstalar la pila de controladores; evita ajustes aleatorios del escritorio hasta que esto esté limpio.
Task 15: Confirmar paquetes NVIDIA instalados (qué hay realmente en disco)
cr0x@server:~$ dpkg -l | grep -E 'nvidia-driver|nvidia-dkms|libnvidia|cuda' | head -n 20
ii nvidia-driver-550 550.54.14-0pop0~1700000000~24.04~abcd123 amd64 NVIDIA driver metapackage
ii nvidia-dkms-550 550.54.14-0pop0~1700000000~24.04~abcd123 amd64 NVIDIA DKMS package
ii libnvidia-gl-550 550.54.14-0pop0~1700000000~24.04~abcd123 amd64 NVIDIA OpenGL/GLX/EGL/GLES GLVND libraries
Significado: Tienes los paquetes esperados instalados.
Decisión: Si faltan paquetes o hay versiones mezcladas, limpia e instala de nuevo a una versión de controlador consistente.
Task 16: Si necesitas MOK: verificar que existen claves inscritas
cr0x@server:~$ mokutil --list-enrolled | head -n 20
MokListRT:
SHA1 Fingerprint: 3a:9f:19:2e:7c:2a:0f:9b:51:4b:4c:9e:2d:14:0a:aa:ef:01:22:de
Subject: CN=Local NVIDIA Module Signing
Significado: Hay una MOK inscrita.
Decisión: Si no hay una clave relevante inscrita y Secure Boot está activado, necesitas inscribir una antes de que los módulos firmados puedan cargarse.
FAQ
1) ¿Debería usar el ISO NVIDIA o el ISO estándar?
Si tu máquina tiene una GPU NVIDIA y quieres el controlador propietario, usa el ISO NVIDIA.
Reduce dolores de cabeza de pantalla en el arranque temprano y te lleva a un escritorio usable más rápido.
2) ¿Puedo mantener Secure Boot activado y seguir usando NVIDIA?
Sí, pero debes asegurar que el módulo del kernel NVIDIA sea de confianza para Secure Boot.
Eso significa módulos firmados vía integración de empaquetado o usar inscripción MOK y firmarlos tú mismo.
3) Habilité Secure Boot y ahora el controlador NVIDIA “se instala” pero no funciona. ¿Por qué?
Porque instalación no es activación. Secure Boot puede bloquear el módulo de cargarse en tiempo de ejecución.
Revisa mokutil --sb-state, dmesg y si lsmod muestra nvidia.
4) ¿Wayland o Xorg con NVIDIA?
Usa Wayland si tu flujo de trabajo es mainstream y quieres comportamiento moderno del compositor.
Usa Xorg si dependes de herramientas específicas de escritorio remoto, aplicaciones gráficas nicho, o estás depurando un problema obstinado de pantalla NVIDIA.
La respuesta correcta es: prueba ambos y conserva el que falle menos para tu carga de trabajo.
5) Mi monitor externo solo funciona en modo NVIDIA. ¿Es normal?
En algunos portátiles, sí. Algunos puertos están cableados a la dGPU. Si el puerto está en el lado NVIDIA del mux hardware,
el modo solo integrado no lo alimentará. Valida tu topología y luego elige el modo que coincida con el cableado físico.
6) ¿Debería poner en blacklist a nouveau?
Si usas el controlador propietario NVIDIA, normalmente sí—nouveau puede reclamar el dispositivo o interferir con la inicialización.
Si intencionalmente usas nouveau (escritorio básico, sin CUDA), entonces no instales la pila propietaria en absoluto.
7) ¿Por qué una actualización del kernel rompió mis gráficos?
Porque el módulo NVIDIA está fuertemente acoplado al ABI del kernel.
Si DKMS falla al construir (falta headers, incompatibilidad de compilador, problema de empaquetado) reinicias en un kernel sin módulo NVIDIA funcional.
Siempre revisa dkms status después de actualizaciones antes de reiniciar.
8) ¿Debería habilitar cifrado de disco completo?
Sí para portátiles y cualquier cosa que salga de tu control. Es madura y la sobrecarga de rendimiento normalmente no es notable en hardware moderno.
Para escritorios en salas cerradas sigue siendo razonable, pero prioriza tus requisitos operativos.
9) ¿Es Pop!_OS “bueno para NVIDIA” comparado con otras distros?
A menudo es más amable desde el primer arranque, especialmente con el ISO NVIDIA y un enfoque cohesivo de controladores.
Dicho eso, NVIDIA en Linux nunca es “configúralo y olvídate” si actualizas kernels con frecuencia. La verificación es la verdadera característica.
10) ¿Cuál es la recuperación más simple cuando el escritorio no arranca?
Arranca en un TTY, comprueba si el módulo NVIDIA se cargó, inspecciona journalctl por errores del gestor de pantalla,
y revierte a un kernel anterior si está disponible. Reinstala la pila de controladores solo después de saber qué falló.
Próximos pasos que realmente debes hacer
Si quieres que esta instalación se mantenga limpia, haz estos pasos siguientes en orden:
- Fija tu decisión de Secure Boot (desactívalo o implementa firmado MOK). No lo dejes ambiguo.
- Ejecuta las tareas de validación después de cada actualización del kernel/controlador: módulo cargado, estado DKMS, tipo de sesión y
nvidia-smi. - Elige una política de modo gráfico para portátiles híbridos y cúmplela. Integrado por defecto suele ser la base sensata.
- Mantén el escritorio aburrido: menos extensiones, menos agentes en segundo plano, menos sorpresas.
- Captura logs cuando falle antes de reiniciar tres veces y borrar la evidencia.
La meta no es un sistema perfecto. La meta es un sistema que puedas entender bajo presión—porque eventualmente, estarás bajo presión.