GPU Blackwell en Proxmox 9.1: cuando los drivers open de Nvidia no cargan
Ciertas frustraciones solo aparecen cuando todo debería funcionar a la perfección. Tienes el hardware bien encajado en su ranura y la BIOS configurada en orden. Secure Boot está desactivado, Nouveau en la lista negra y el instalador completa la barra de progreso al 100 por ciento. Durante un instante crees que el trabajo está hecho. Entonces Proxmox te asesta el golpe: incapaz de cargar el módulo del kernel.
Muchos usuarios han vivido esa misma escena hace poco tras instalar las nuevas tarjetas de arquitectura Blackwell de Nvidia, como la 5060 y la 5060 Ti, en servidores con Proxmox 9.1. Sobre el papel, esta debía ser una etapa tranquila. Nvidia ofrece ahora módulos abiertos para el kernel, Proxmox documenta qué versiones del controlador conviene usar y las posibles regresiones del kernel se dan por conocidas. Sin embargo, nos encontramos con un archivo nvidia.ko que se niega a existir. Hay demasiados testimonios para que se trate de un simple descuido individual.
La promesa de los drivers "open" de Nvidia
Las tarjetas Blackwell llegaron con un cambio pequeño pero de gran peso. Las GPUs más recientes de Nvidia apuestan de lleno por la vía del controlador abierto con licencia MIT/GPL, dejando atrás el clásico módulo propietario con el que los administradores de Linux lidiaron durante años.
En teoría, esto debería ser una ventaja clara: mejor compatibilidad con el kernel, menos quebraderos de cabeza con DKMS y menos roces cuando los núcleos avanzan con rapidez, algo que en Proxmox ocurre con frecuencia.
Para ser justos, mucha gente utiliza tarjetas de la serie 50 sin ningún problema. Algunos incluso lo logran en versiones de kernel más modernas que las avaladas oficialmente por Proxmox, usando los mismos controladores, el mismo instalador y marcando la misma opción MIT/GPL. Eso es justo lo que vuelve estos fallos tan desconcertantes.
Cuando "compatible" no significa "funcional"
En los incidentes que no paran de repetirse, la historia casi siempre sigue el mismo guion. Una instalación limpia de Proxmox 9.1, una gráfica Blackwell y el archivo ejecutable del controlador de la serie 580 recomendado por Nvidia. El instalador termina sin errores visibles, y justo después el módulo no se deja cargar.
El comando modprobe nvidia responde sin aportar pistas útiles. Por su parte, lsmod no muestra rastro de nouveau, ni de nvidia, ni de ningún proceso compitiendo por el dispositivo. Sin embargo, los registros del sistema revelan un detalle más inquietante:
request_mem_region failed for 64M @ 0xd0000000
Esa línea es el verdadero nudo del problema. Suele indicar que otro controlador ya se ha adueñado del espacio de memoria de la GPU. Nouveau acostumbra a ser el principal sospechoso, pero en estos servidores ya está bloqueado y fuera del initramfs. Secure Boot permanece desactivado y no queda ningún residuo de rivatv en segundo plano. Aun así, el driver de Nvidia sondea el hardware y rebota.
Llegados a ese punto, el instalador sugiere de forma automática las causas de costumbre (cabeceras del kernel incorrectas, versión dispar de GCC o una GPU incompatible), ninguna de las cuales explica la situación real.
La ruleta de kernels no siempre te salva
El primer reflejo casi siempre consiste en culpar al kernel. El propio equipo de Proxmox advierte de asperezas con ciertas ramas recientes, y muchos administradores bajan de inmediato de la versión 6.17 a la 6.14. A algunos les funciona; a otros no les cambia nada.
El controlador compila bien contra el kernel correcto y las cabeceras coinciden. El sistema arranca con absoluta certeza en la misma versión del núcleo contra la que se compiló el código. A pesar de todo, la ruta /lib/modules/$(uname -r) jamás llega a albergar un archivo nvidia.ko operativo.
Es ahí donde la tarea deja de ser un diagnóstico técnico habitual de Linux para volverse algo casi desconcertante. Has cumplido cada requisito, has seguido la documentación oficial al milímetro y el sistema te da la razón en todos los datos objetivos, pero sigue negándose a colaborar.
VFIO complica las cosas más de la cuenta
Si escarbas un poco más en los registros, aparece otra pista recurrente: mensajes de VFIO intercalados con los fallos de Nvidia, y ese detalle importa.
Gran parte de quienes usan Proxmox no instalan controladores de Nvidia solo para tener salida de vídeo. Buscan compartir la GPU con contenedores, atender cargas de trabajo con CUDA o realizar pruebas de passthrough. VFIO entra en juego muy pronto en el arranque y, en ciertas configuraciones, parece reclamar partes del dispositivo antes de que el controlador de Nvidia tenga ocasión de inicializarse.
Incluso cuando no estás asignando la tarjeta de forma explícita a una máquina virtual, los ajustes y el orden de inicio de Proxmox pueden colocar a VFIO por delante en la asignación del hardware. El resultado es un bloqueo absurdo: aparentemente nada tiene el control de la GPU, pero el controlador de Nvidia es incapaz de reservar sus rangos de memoria.
La opción MIT/GPL ya no es opcional
Hay algo que no deja lugar a dudas: las tarjetas Blackwell sencillamente no funcionarán con el módulo antiguo y privativo. Si no seleccionas la opción MIT/GPL durante el proceso de instalación, no hay manera de avanzar.
Casi todos los usuarios atrapados en este escollo la eligen bien. El instalador les pregunta, optan por el controlador abierto y aun así falla. Es un dato relevante, porque descarta el error más evidente y demuestra lo estrecho que es en realidad el margen del problema.
Por qué algunos equipos funcionan y otros no
Aquí es donde la conversación se vuelve incómoda. Varios administradores con configuraciones casi idénticas, desde la GPU hasta la versión de Proxmox y la compilación del controlador, obtienen resultados totalmente opuestos. Un equipo arranca limpio con soporte para CUDA listo, mientras otro tropieza una y otra vez con el mismo error en el kernel.
La disparidad suele esconderse en el historial del propio servidor. Los hosts de Proxmox veteranos, con años de actualizaciones de kernel, sustituciones de hardware y archivos de configuración acumulados, parecen mucho más propensos a tropezar con estos fallos; las instalaciones nuevas responden mejor. La regla no se cumple al cien por cien, pero se repite con suficiente frecuencia como para marcar una pauta.
No es una respuesta agradable, pero sí conocida. Los sistemas Linux acumulan estado residual con el tiempo. Disparadores de initramfs, configuraciones olvidadas en modprobe y restos de gestores de arranque sobreviven mucho después de perder su utilidad original, hasta que un día pinchas una GPU nueva y tropieza con algo invisible.
La reinstalación que nadie quiere hacer
Muchos de los que chocaron contra este muro terminan admitiendo lo inevitable: el servidor probablemente pide una reinstalación limpia desde cero. Proxmox no está roto y los controladores de Nvidia no son defectuosos. Lo que ocurre es que la fricción entre núcleos que evolucionan muy rápido, el subsistema VFIO y la transición hacia módulos abiertos deja un margen mínimo para tolerar basura acumulada del pasado.
Es una conclusión difícil de tragar en un hipervisor. Un servidor de Proxmox no es un portátil personal que formateas un domingo por la tarde sin pensarlo dos veces. Gestiona almacenamiento, máquinas virtuales, redes y cargas de trabajo que costó años afinar. Sin embargo, para algunos propietarios de tarjetas Blackwell, una instalación desde cero ha sido el único remedio para que modprobe nvidia deje de protestar.
El coste de vivir a la vanguardia
Nada de esto significa que montar una tarjeta Blackwell sea un error en Proxmox. Una vez que se ponen en marcha, su rendimiento parece sólido. Hay entornos con múltiples GPUs combinando tarjetas de las series 30, 40 y 50 funcionando sin problemas en tareas de inferencia y contenedores.
Lo que sí demuestra es que la etapa del "driver open" no ha borrado por arte de magia la complejidad histórica de Nvidia en Linux. Las asperezas simplemente han cambiado de sitio y siguen bien presentes. Proxmox avanza con celeridad y los kernels lo hacen aún más rápido. Nvidia se halla a mitad de camino entre dos arquitecturas de controladores, mientras que VFIO es potente pero implacable. Si juntas todas esas piezas obtienes justo esta clase de avería: discreta, desconcertante y muy molesta.
Dónde deja esto a los usuarios de Proxmox
Si tienes pensado instalar una GPU Blackwell en un servidor con Proxmox 9.1, puedes dar el paso, pero conviene hacerlo conociendo el terreno. Comienza con una base limpia si te resulta posible, actúa con cuidado al configurar VFIO y revisa dos veces con qué versión exacta del kernel estás arrancando. Ten presente que el éxito del instalador no garantiza que el módulo vaya a cargar.
Si te topas con el temido fallo del módulo del kernel habiendo hecho todo bien, no pienses de inmediato que has pasado algo por alto. A veces el sistema simplemente arrastra demasiados cabos sueltos. Es el precio de combinar hardware recién estrenado con un hipervisor que avanza a su mismo ritmo: el futuro llega pronto, pero no siempre pide permiso al entrar.