Saltar a contenido

Controladores de NVIDIA

Fedora no distribuye el controlador de NVIDIA, así que en una instalación recién hecha tu tarjeta funciona sobre la pila abierta. Para mucha gente eso basta. Para juegos, CUDA, NVENC o cualquier tarjeta más nueva de lo que el controlador abierto ha alcanzado, no.

Esta página cubre el empaquetado de RPM Fusion, la ruta que dan por supuesta la mayoría de la documentación de Fedora y la mayoría de la resolución de problemas de la comunidad.

Todo lo de abajo se comprobó contra fuentes de RPM Fusion, NVIDIA y Fedora en septiembre de 2026, con Fedora 43 y 44 como objetivo. Los números de rama del controlador y los cortes de las ramas heredadas cambian. Cuando un número importa, esta página también te dice cómo comprobarlo tú mismo en lugar de fiarte del número.

Lo que tienes sin él

El kernel de Fedora incluye nouveau, el controlador de kernel de NVIDIA hecho por ingeniería inversa, y —desde el kernel de Fedora 44— nova_core, el sucesor basado en Rust que se está construyendo para reemplazarlo en las GPU basadas en GSP. El espacio de usuario viene de Mesa: OpenGL, más NVK, el controlador Vulkan de Mesa para hardware de NVIDIA. NVK es una implementación conforme de Vulkan 1.4 que cubre desde Kepler (GeForce 600/700) hasta Ada (RTX 40) y Blackwell de consumo (RTX 50), y desde Mesa 25.1 las tarjetas Turing y posteriores usan NVK más Zink para OpenGL por omisión.

Esa pila muestra un escritorio, reproduce vídeo y ejecuta un navegador en prácticamente cualquier tarjeta NVIDIA. Lo que no hace:

  • Subir las frecuencias de la GPU. Este es el grande. Nouveau no puede reajustar las frecuencias de las GPU Maxwell ni Pascal en absoluto — una GTX 1080 funciona a sus frecuencias de arranque, que son una fracción de su rendimiento real. Turing y posteriores salen mejor paradas porque el firmware GSP se encarga de la gestión de energía. El reajuste de frecuencias en Kepler es parcial.
  • CUDA, NVENC o NVDEC. No hay implementación abierta. Si necesitas codificación por hardware, transcodificación de vídeo o cualquier cosa que enlace con libcuda, necesitas el controlador privativo.
  • Parte del hardware de última generación. El soporte abierto llega después del lanzamiento, no con él.

El controlador está ausente porque NVIDIA lo distribuye bajo una licencia que prohíbe la redistribución que Fedora exige — la misma razón por la que faltan los códecs. Consulta la página principal para la forma general de todo eso.

¿Lo necesitas?

Instálalo si quieres rendimiento 3D serio, cómputo con CUDA u OpenCL, codificación NVENC, o si tu tarjeta es demasiado nueva para Mesa. No lo instales si la máquina es un portátil donde lo que más importa es la autonomía, si la tarjeta es lo bastante antigua como para que ninguna rama soportada la cubra, o si el escritorio ya funciona y no hay ninguna queja — el controlador privativo añade un módulo del kernel fuera del árbol que hay que reconstruir en cada actualización del kernel, y eso es un coste de mantenimiento permanente.

Los costes, dichos una sola vez: el controlador no es libre, no es auditable, lo construye y distribuye un tercero fuera del límite de confianza de Fedora, y se carga como un módulo del kernel sin firmar salvo que lo firmes tú mismo.

Identifica tu GPU y elige una rama

NVIDIA divide su controlador en una rama actual y varias ramas heredadas congeladas. Instalar la equivocada da un controlador que carga y luego se niega a manejar tu tarjeta.

Localiza la tarjeta:

# Every display-class device, with numeric PCI IDs
lspci -nn | grep -E 'VGA|3D|Display'

El [10de:xxxx] del final es el ID PCI de fabricante:dispositivo. 10de es NVIDIA. Si tu tarjeta NVIDIA aparece como 3D controller en vez de como VGA compatible controller, es un portátil de gráficos híbridos — consulta Gráficos híbridos.

Asocia la tarjeta a una rama con el listado de controladores Unix de NVIDIA. A fecha de septiembre de 2026:

Arquitectura Tarjetas Rama
Turing y posteriores GTX 16, RTX 20/30/40/50 actual (610 en F44, 580 en F43)
Maxwell, Pascal, Volta GTX 745/750/750 Ti, GTX 900, GTX 10, TITAN V 580
Kepler GeForce 600/700, incluida la GTX 780 Ti 470
Fermi GeForce 400/500 390
Tesla y anteriores GeForce 8/9/200/300 y por debajo ninguna — solo nouveau

Dos trampas en esa tabla:

Los números de modelo de portátil cruzan arquitecturas. La GTX 860M, la 920 y buena parte de las líneas 800M/900M existen como silicio Kepler y como silicio Maxwell bajo el mismo nombre comercial. El ID PCI es el único discriminador fiable. Pega el tuyo en la lista de chips soportados de NVIDIA para el controlador actual: si está en la tabla «Current NVIDIA GPUs» quieres la rama actual, y si aparece más abajo bajo «The 580.xx driver supports the following set of GPUs» lo que quieres es esa rama heredada.

Lo «actual» depende de tu versión de Fedora. En Fedora 43 la rama actual es la 580, así que las tarjetas Maxwell y Pascal usan el paquete normal. En Fedora 44 la rama actual pasó a ser la 610 y la 580 se convirtió en un paquete heredado aparte. La rama 580 es la última que soporta Maxwell, Pascal y Volta en absoluto; NVIDIA ha dicho que recibirá arreglos de compatibilidad con el kernel pero ninguna característica nueva.

Por debajo de Fermi no hay nada. La rama 340, que cubría las GeForce 8/9/200/300, no está empaquetada para Fedora 43 ni 44 por RPM Fusion. Esas tarjetas funcionan con nouveau o no funcionan.

En vez de fiarte de la tabla, pregúntale a tu propio sistema qué existe:

dnf5 list --available 'akmod-nvidia*'

Empaquetado

Esta página documenta el empaquetado de RPM Fusion, que es lo que dan por supuesto la mayoría de la documentación de Fedora y la mayoría de la resolución de problemas de la comunidad.

Un segundo repositorio, negativo17, empaqueta el mismo controlador con nombres distintos y con propiedad de archivos solapada. Los dos no se pueden mezclar. Si quieres ramas del controlador más nuevas antes, DKMS en lugar de akmods, o bibliotecas de CUDA sin el controlador de pantalla, consulta La ruta de negativo17 — compara ambos y contiene el procedimiento para cambiar de uno a otro.

Arranque Seguro: haz esto antes de instalar nada

Esta es la forma más común de que esta instalación salga mal. Con el Arranque Seguro activado y el módulo sin firmar, el kernel se niega a cargarlo y nada en la salida de la instalación lo dice.

mokutil --sb-state

Si eso dice SecureBoot enabled, recorre Arranque Seguro antes de instalar el controlador.

Instalar el controlador

Habilita el repositorio nonfree

El controlador está en el repositorio nonfree de RPM Fusion. Habilita free y nonfree, después actualiza y reinicia, como se describe en Repositorios de terceros.

El reinicio importa aquí. Instala el controlador contra un kernel que no estás ejecutando y el sistema de akmods se las apañará, pero te habrás complicado tu propia depuración.

Instalación

Rama actual — Turing y posteriores:

sudo dnf5 install akmod-nvidia

Ramas heredadas, si tu tarjeta necesita una:

# Maxwell / Pascal / Volta, on Fedora 44
sudo dnf5 install akmod-nvidia-580xx xorg-x11-drv-nvidia-580xx

# Kepler
sudo dnf5 install akmod-nvidia-470xx xorg-x11-drv-nvidia-470xx

# Fermi
sudo dnf5 install akmod-nvidia-390xx xorg-x11-drv-nvidia-390xx

Para CUDA, OpenCL, NVENC y NVDEC, añade el subpaquete de CUDA — esto es lo que necesitan nvidia-smi, la codificación por hardware de ffmpeg y cualquier cosa que enlace con libcuda:

sudo dnf5 install xorg-x11-drv-nvidia-cuda

Las ramas heredadas tienen el suyo propio, limitado a la última versión de CUDA que esa rama soportaba: xorg-x11-drv-nvidia-580xx-cuda, -470xx-cuda, -390xx-cuda.

Para la decodificación de vídeo por VA-API a través del decodificador de NVIDIA, consulta Multimedia y códecs — el paquete puente necesita variables de entorno que esa página documenta.

Lo que akmods hace en realidad, y por qué tienes que esperar

akmod-nvidia no contiene un módulo del kernel. Contiene el código fuente de uno, y depende de un conjunto de herramientas de compilación. El servicio akmods construye un RPM kmod de verdad contra tu kernel en ejecución y lo instala localmente. Dos unidades de systemd lo gobiernan:

  • akmods.service se ejecuta en el arranque y construye lo que falte.
  • akmods@<kernel>.service se ejecuta inmediatamente después de una transacción RPM del kernel, de modo que el módulo para un kernel recién instalado normalmente se construye antes de que reinicies.

Esto significa que el fin de la transacción de dnf no es el fin de la instalación. La compilación se ejecuta después y tarda hasta cinco minutos en una máquina lenta.

Reiniciar antes de que la compilación termine es la segunda forma más común de acabar en una pantalla en negro. Espera, y comprueba.

Comprueba:

modinfo -F version nvidia

Un número de versión —610.57.04 o similar— significa que el módulo existe y que el kernel lo encuentra. modinfo: ERROR: Module nvidia not found significa que no, y reiniciar ahora te dejará caer en nouveau o en nada.

Para comprobar un kernel que no estás ejecutando ahora mismo:

modinfo -F version nvidia -k 6.19.14-300.fc44.x86_64

Si no ha aparecido, mira la compilación:

systemctl status akmods.service
ls -l /var/cache/akmods/nvidia/

Las compilaciones correctas dejan <version>-for-<kernel>.log. Los fallos dejan <version>-for-<kernel>.failed.log, y el final de ese archivo es el error del compilador. Fuerza un reintento con:

sudo akmods --force --kernels $(uname -r)

Lo que el paquete cambió en tu máquina

Instalar xorg-x11-drv-nvidia ejecuta grubby sobre todas tus entradas de arranque para añadir rd.driver.blacklist=nouveau,nova_core modprobe.blacklist=nouveau,nova_core y para quitar cualquier nomodeset. Inspecciona con qué has acabado:

cat /proc/cmdline

El paquete también instala nvidia-fallback.service, que se dispara cuando nouveau está en la lista negra pero /sys/module/nvidia no existe — carga nouveau de todos modos e imprime "NVIDIA kernel module missing. Falling back to nouveau" en la pantalla de bienvenida de Plymouth. Si ves ese mensaje, tienes un escritorio que funciona y un controlador roto: vuelve a modinfo de más arriba.

Desinstalar quita de nuevo esos argumentos del kernel, así que una eliminación limpia no te deja con nouveau en la lista negra y nada que lo sustituya.

Por último, los módulos de NVIDIA se mantienen deliberadamente fuera del initramfs. Del arranque temprano se encarga simpledrm usando el modo del firmware. Por eso no necesitas reconstruir el initramfs después de actualizar el controlador.

Módulo del kernel abierto frente a privativo

NVIDIA distribuye dos implementaciones en espacio de kernel: la privativa y una de código abierto (MIT/GPL). El espacio de usuario sigue siendo privativo en cualquiera de los dos casos. Los paquetes recientes de RPM Fusion incluyen ambos códigos fuente y eligen entre ellos en tiempo de compilación según el ID PCI de tu GPU, así que el valor por omisión normalmente es el correcto y no hay nada que hacer.

Existe un paquete akmod-nvidia-open en el repositorio tainted de RPM Fusion para quien necesite parchear el módulo del kernel abierto por su cuenta. Se mantiene deliberadamente fuera de los repositorios por omisión; si no vas a modificar el código fuente del módulo, no lo quieres.

Evita que dnf lo elimine

El empaquetado de akmods permite que dnf autoremove decida que akmod-nvidia es una hoja innecesaria y se lo lleve, junto con las herramientas de compilación de las que depende. Márcalo como instalado por el usuario:

sudo dnf5 mark user akmod-nvidia

Gráficos híbridos (portátiles Optimus)

En un portátil con gráficos integrados Intel o AMD más un chip NVIDIA, la GPU de NVIDIA normalmente no tiene ninguna pantalla conectada directamente a ella — el panel interno cuelga de la iGPU. La tarjeta NVIDIA renderiza, la iGPU muestra. Eso es el descargue de renderizado de PRIME, y en Fedora lo configuran automáticamente los paquetes del controlador. No hay nada que preparar.

Para enviar una aplicación concreta a la GPU de NVIDIA:

# Vulkan applications
__NV_PRIME_RENDER_OFFLOAD=1 vkcube

# GLX applications on Xwayland also need GLVND pointed at the NVIDIA driver
__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia glxinfo | grep vendor

__NV_PRIME_RENDER_OFFLOAD es la que hace el trabajo: carga la capa Vulkan de NVIDIA y se aplica también a los clientes GLX y EGL. __GLX_VENDOR_LIBRARY_NAME gobierna únicamente la selección de fabricante de GLX, así que importa para las aplicaciones que se ejecutan a través de Xwayland y la ignora una aplicación Wayland nativa que dibuje mediante EGL. Poner ambas es inofensivo.

Ese par de variables es todo lo que hay en los scripts envoltorio nvidia-offload que verás en otras distribuciones. Si quieres uno, son dos líneas:

printf '#!/bin/sh\nexport __NV_PRIME_RENDER_OFFLOAD=1\nexport __GLX_VENDOR_LIBRARY_NAME=nvidia\nexec "$@"\n' \
  | sudo tee /usr/local/bin/nvidia-offload >/dev/null
sudo chmod +x /usr/local/bin/nvidia-offload

Después, nvidia-offload steam, y así sucesivamente. El menú de aplicaciones de GNOME también ofrece «Launch using Discrete Graphics Card» (lanzar usando la tarjeta gráfica dedicada) para los lanzamientos desde archivos desktop.

Dos controles más finos, ambos de la documentación de PRIME de NVIDIA tal como la resumen las notas sobre Optimus de RPM Fusion: __VK_LAYER_NV_optimus=NVIDIA_only restringe la lista de GPU que ve una aplicación Vulkan, y __NV_PRIME_RENDER_OFFLOAD_PROVIDER=NVIDIA-G0 elige una GPU concreta en una máquina con varias. El nombre que toma es un nombre de proveedor de X RandR, y xrandr --listproviders es lo que imprime esos nombres — un cliente X11, así que informa de lo que expone el servidor X con el que habla y no de lo que contiene la máquina. Para el inventario propio de la máquina de GPU y controladores asociados, usa sudo lspci -nnk.

Gestión de energía

La posición honesta: con el controlador privativo cargado, un portátil Optimus consume más energía que ese mismo portátil sobre la pila abierta, porque la pila abierta puede apagar por completo la GPU dedicada y la gestión dinámica de energía del controlador privativo es menos completa. Donde el firmware lo permite, desactivar Optimus es la salida fiable de ese compromiso.

Se puede optar por la gestión dinámica de energía:

sudo tee /etc/modprobe.d/nvidia-dpm.conf >/dev/null <<'EOF'
options nvidia NVreg_DynamicPowerManagement=0x02
EOF

0x02 es el ajuste más agresivo — la GPU se apaga cuando está inactiva. Reinicia para que surta efecto. Si ves bloqueos al despertar, borra el archivo.

Monitores externos

En algunos portátiles las salidas HDMI o DisplayPort están cableadas a la GPU de NVIDIA y no a la iGPU. Un monitor externo muerto ahí es una cuestión de qué GPU es dueña del puerto. Confirma primero qué hay presente y qué está asociado a ello:

sudo lspci -nnk

El enrutado de la salida entre dos GPU es entonces decisión del compositor, y el comportamiento varía entre GNOME, KDE y versiones del controlador. El arreglo que RPM Fusion documenta para esto —un archivo de configuración que marca la GPU dedicada como primaria— se aplica a las sesiones de Xorg y no tiene equivalente en Wayland, así que no hay un único cambio de configuración que merezca la pena reproducir aquí. Consulta las notas de publicación actuales de tu compositor y del controlador para la versión que tengas.

Donde el firmware ofrezca ese ajuste, desactivar Optimus enruta las salidas a través de la GPU de NVIDIA de forma permanente. Eso mantiene la GPU dedicada encendida en todo momento, así que la autonomía baja.

Convivir con las actualizaciones del kernel

Cada actualización del kernel de Fedora invalida tu módulo de NVIDIA. Un módulo construido para 6.19.14 no cargará en 6.20.1. La maquinaria de akmod o de DKMS existe para reconstruirlo, y casi siempre lo hace durante la propia transacción de dnf del kernel.

Falla cuando falla la compilación: un kernel demasiado nuevo para la rama del controlador, un kernel-devel que falta, un cambio en el compilador, quedarse sin disco. Te enteras en el siguiente reinicio.

Antes de reiniciar tras cualquier actualización del kernel, cuando la máquina te importe:

sudo dnf5 upgrade
modinfo -F version nvidia -k $(rpm -q --last kernel | head -1 | sed 's/^kernel-//;s/ .*//')

Si eso imprime una versión, puedes reiniciar sin riesgo.

Recuperarse de una pantalla en negro

No has perdido nada. Recorre estos pasos en orden.

1. Consigue una consola de texto. Desde la pantalla en negro, prueba Ctrl+Alt+F3. Si obtienes un indicador de inicio de sesión, el kernel está bien y solo los gráficos están rotos — salta al paso 4.

2. Arranca el kernel anterior. Mantén pulsada Esc (o Mayús en algunos sistemas) durante el arranque para llegar al menú de GRUB, y elige la entrada del kernel más antiguo. Fedora mantiene tres instalados por omisión. El kernel viejo todavía tiene su módulo funcional, así que esto normalmente te devuelve directamente a un escritorio.

3. Arranca con nouveau en su lugar. En el menú de GRUB, pulsa e para editar la entrada, busca la línea linux y borra rd.driver.blacklist=nouveau,nova_core modprobe.blacklist=nouveau,nova_core. Ctrl+X lo arranca. Obtienes un escritorio lento pero funcional con los paquetes de NVIDIA todavía instalados. Esto es temporal — el cambio no se escribe en disco.

nomodeset en esa misma línea es la versión más drástica: desactiva por completo el modesetting del kernel y te da un framebuffer sin aceleración. Úsalo solo si quitar la lista negra no basta.

4. Reconstruye el módulo. Desde un TTY o desde una sesión con nouveau:

sudo akmods --force --kernels $(uname -r)
modinfo -F version nvidia

Si la compilación falla, lee el motivo:

sudo tail -50 /var/cache/akmods/nvidia/*.failed.log

Un fallo contra un kernel recién salido normalmente significa que la rama del controlador no se ha puesto al día. Quedarse en el kernel anterior hasta que se actualice el controlador es una respuesta legítima.

Suspensión y reanudación

Ventanas corrompidas, un escritorio colgado o una pantalla en negro tras la reanudación suele ser memoria de vídeo que no se preserva durante la suspensión. El arreglo es el subpaquete de gestión de energía:

sudo dnf5 install xorg-x11-drv-nvidia-power
sudo systemctl enable nvidia-suspend.service nvidia-resume.service nvidia-hibernate.service

Ese paquete instala /usr/lib/modprobe.d/nvidia-power-management.conf con las opciones pertinentes presentes pero comentadas. Para activarlas, anúlalo — nunca edites archivos bajo /usr/lib:

sudo tee /etc/modprobe.d/nvidia-power-management.conf >/dev/null <<'EOF'
options nvidia NVreg_PreserveVideoMemoryAllocations=1
options nvidia NVreg_TemporaryFilePath=/var/tmp
EOF

La primera preserva el contenido completo de la memoria de vídeo durante la suspensión. La segunda envía ese volcado a /var/tmp y no a /tmp, que en Fedora es tmpfs — escribir en RAM toda la memoria de vídeo de una GPU frustra el propósito y puede fallar directamente. Reinicia para aplicarlo.

Variantes atómicas (Silverblue, Kinoite)

El esquema coincide con el de la instalación clásica. Todos los pasos mecánicos difieren.

Añade RPM Fusion y reinicia para que los repositorios existan — consulta Repositorios de terceros.

Superpón el controlador:

rpm-ostree install akmod-nvidia xorg-x11-drv-nvidia
# add xorg-x11-drv-nvidia-cuda too if you need nvidia-smi or CUDA

Establece los argumentos del kernel a mano. En la Fedora clásica el RPM lo hace por ti con grubby; en ostree el paquete no puede modificar la configuración de arranque, así que este paso es cosa tuya:

rpm-ostree kargs \
  --append=rd.driver.blacklist=nouveau,nova_core \
  --append=modprobe.blacklist=nouveau,nova_core

Después reinicia en el nuevo despliegue.

Lo que difiere del flujo de trabajo clásico:

  • El módulo se construye durante la transacción de superposición, no en el arranque. akmods.service se niega a ejecutarse en un sistema ostree (su unidad lleva ConditionPathExists=!/run/ostree-booted). Por eso rpm-ostree install akmod-nvidia tarda varios minutos.
  • Cada actualización del kernel significa un nuevo despliegue, con el módulo reconstruido como parte de su composición. La ventaja es que una compilación fallida te da un despliegue fallido en lugar de un arranque roto, y el despliegue anterior sigue en el menú de GRUB.
  • Las actualizaciones de versión mayor requieren volver a superponer los paquetes release en la misma transacción que el rebase — consulta Repositorios de terceros.
  • El Arranque Seguro es realmente incómodo. La clave de firma tiene que estar disponible durante la composición, lo que significa empaquetarla en vez de dejarla en /etc — consulta Arranque Seguro.

La ruta preconstruida

Universal Blue publica imágenes de Fedora Atomic —Bazzite, Bluefin, Aurora— con variantes NVIDIA en las que el controlador ya viene construido dentro de la imagen y firmado con la clave del proyecto. No se superpone nada y no se compila nada en tu máquina; las actualizaciones del kernel llegan como una imagen nueva con un módulo a juego ya dentro.

Aun así tienes que inscribir su clave de firma una vez, algo que esas imágenes envuelven en ujust enroll-secure-boot-key. La contraseña la fija la imagen y no tú — Bluefin documenta universalblue, y los hilos de la comunidad mencionan ublue-os para otras imágenes. Consulta Arranque Seguro para la mecánica de la inscripción.

El compromiso es el habitual de las imágenes preconstruidas: obtienes las pruebas de integración de otra gente y ningún paso de compilación local, y cedes el control sobre qué rama del controlador y qué paquetes ejecutas.

Quitarlo y volver a nouveau

sudo dnf5 remove 'xorg-x11-drv-nvidia*'
sudo systemctl reboot

El scriptlet de desinstalación de RPM Fusion quita la lista negra de nouveau de tus argumentos del kernel, así que la máquina vuelve con nouveau. Confírmalo antes de reiniciar:

cat /proc/cmdline    # should no longer mention rd.driver.blacklist=nouveau

Si en su lugar instalaste desde negativo17, su secuencia de eliminación está en La ruta de negativo17.

Otra vez: nada de dnf remove '*nvidia*'. Eso se lleva por delante nvidia-gpu-firmware, que nouveau y nova_core necesitan.

Tras el reinicio no debería haber nada de NVIDIA cargado:

lsmod | grep -E 'nvidia|nouveau'

Si alguna vez ejecutaste en esta máquina el instalador .run propio de NVIDIA, sobrescribió bibliotecas de la distribución sin que RPM lo supiera y quitar el paquete no deshará eso. RPM Fusion documenta un procedimiento de recuperación para ese caso. No lo ejecutes en ningún otro caso — borra bibliotecas del sistema.

Resolución de problemas

¿Por qué hay una pantalla en negro tras el primer reinicio?

Recórrelo en orden. ¿Se construyó el módulo (modinfo -F version nvidia desde un TTY o desde un arranque de rescate)?, ¿está activado el Arranque Seguro (mokutil --sb-state)? y ¿se inscribió la clave (sudo mokutil --test-key /etc/pki/akmods/certs/public_key.der)?

Un módulo que se compiló bien pero que es rechazado al cargarse es casi siempre un problema de firma:

sudo dmesg | grep -iE 'nvidia|lockdown|module verification'

Recuperarse de una pantalla en negro tiene la secuencia completa.

¿Qué significa «NVIDIA kernel module missing. Falling back to nouveau»?

Que nvidia-fallback.service está haciendo su trabajo. Tu escritorio funciona, el controlador no. Consulta Recuperarse de una pantalla en negro para la reconstrucción.

¿Por qué la pantalla se queda en 1024x768?

El controlador de NVIDIA no está en uso. O bien recurrió a nouveau, en cuyo caso consulta la entrada anterior, o bien nomodeset está en la línea de comandos del kernel:

cat /proc/cmdline
sudo grubby --update-kernel=ALL --remove-args='nomodeset'

¿Por qué dejó de cargarse el módulo tras una actualización del kernel?

La compilación falló o no se ha ejecutado. Consulta Convivir con las actualizaciones del kernel. Si la rama del controlador todavía no soporta el kernel nuevo, espera a que el controlador se actualice en lugar de forzar nada.

¿Debería añadir nvidia-drm.modeset=1 a la línea de comandos del kernel?

No. El módulo de RPM Fusion habilita el modesetting del kernel por omisión, y RPM Fusion advierte de que no se ponga el parámetro a mano — interactúa mal con el manejo del arranque temprano por simpledrm del kernel de Fedora. Mensajes de foro y artículos de blog antiguos todavía te dicen que lo pongas; están describiendo una configuración de hace varios años.

Desactivar el modesetting es un paso de depuración, y es reversible:

sudo grubby --update-kernel=ALL --args='nvidia-drm.modeset=0'
sudo grubby --update-kernel=ALL --remove-args='nvidia-drm.modeset=0'

¿Por qué no aparece la petición de la frase de paso de LUKS?

Con cifrado de disco completo y la tarjeta NVIDIA como única GPU, la petición se dibuja antes de que el controlador se inicialice:

sudo grubby --update-kernel=ALL --args='plymouth.use-simpledrm=1'

¿Por qué está muerto el monitor externo en mi portátil?

Comprueba primero si el puerto está siquiera cableado a la GPU de NVIDIA — sudo lspci -nnk muestra qué GPU tiene qué controlador asociado. Después consulta Monitores externos.

¿Por qué la suspensión y reanudación rompe la pantalla?

Consulta Suspensión y reanudación. Si sigue fallando con la preservación de la memoria de vídeo habilitada, comprueba que /var/tmp tenga sitio para el volcado.

¿Por qué dnf autoremove eliminó el controlador?

Considera que akmod-nvidia es un paquete hoja:

sudo dnf5 mark user akmod-nvidia

Después reinstálalo.

¿Cómo informo de un fallo?

NVIDIA y RPM Fusion quieren los dos el mismo paquete de registros:

sudo nvidia-bug-report.sh