La retirada de soporte “real” para GPUs veteranas suele ser una noticia rutinaria… hasta que deja a miles de usuarios mirando una consola en negro después de un pacman -Syu. Eso es exactamente lo que ha ocurrido con la última transición de drivers de NVIDIA en Arch Linux: una combinación de cambio de rama, packaging y falta de “colchón” para el usuario ha provocado que equipos con GPU Pascal (GTX 10xx) o Maxwell (GTX 9xx) pasen de un escritorio funcional a un sistema que no carga el módulo propietario y termina arrancando en CLI.
El detonante ha sido el salto de Arch a la rama 590 del driver (por ejemplo, 590.48.01-1), junto con la sustitución de paquetes hacia el stack nvidia-open para hardware moderno. A nivel práctico, el resultado es sencillo: Turing (GTX 16/RTX 20) y posteriores siguen, pero Maxwell y Pascal quedan fuera del camino principal y requieren una ruta “legacy” para mantener el driver propietario.
Por qué este cambio “rompe” más en una rolling release
En distribuciones con ciclos de lanzamiento más conservadores, estos cambios suelen aterrizar con más margen, documentación integrada y/o mecanismos para mantener ramas antiguas en repositorios oficiales durante un tiempo.
En Arch Linux, por diseño, la prioridad es la actualización rápida. Eso funciona muy bien cuando tu hardware está dentro del soporte corriente, pero se vuelve delicado cuando el soporte se corta en una versión concreta: al actualizar, el sistema instala un driver que ya no reconoce tu GPU y, como consecuencia, Xorg/Wayland no arranca o el módulo no se carga.
Además, Arch ha empujado el cambio a nvidia-open (módulos de kernel “open” de NVIDIA, no confundir con Nouveau) como vía preferente para GPUs soportadas, lo que añade otro punto de fricción: no es solo “un driver nuevo”, es también un nuevo conjunto de paquetes.
Qué GPUs están afectadas
La manera más rápida de saber si estás en la zona de riesgo:
- Si tienes una GTX 1050/1060/1070/1080 (Pascal) → estás afectado.
- Si tienes una GTX 960/970/980 (Maxwell) → también.
- Si tienes GTX 16xx o RTX 20xx en adelante (Turing+) → en principio, estás en el carril soportado del cambio.
Si quieres confirmarlo en el sistema, un clásico:
lspci | grep -E "VGA|3D"para identificar el modelo.nvidia-smi(si aún arrancas con driver) para ver versión del controlador.
La tabla que resume el problema (y las salidas)
| Arquitectura | Series típicas | Ejemplos | Situación tras el cambio | Qué hacer |
|---|---|---|---|---|
| Maxwell | GTX 9xx | 960, 970, 980 | Fuera del soporte principal | Driver legacy / alternativa abierta / renovar GPU |
| Pascal | GTX 10xx | 1050 Ti, 1060, 1070, 1080 | Fuera del soporte principal | Driver legacy (580xx) o migración |
| Turing+ | GTX 16xx / RTX 20xx+ | 1660, 2060, 3060, 4070… | En soporte principal | Migrar al set de paquetes nvidia-open según indique Arch |
Arch, en su comunicación oficial, deja claro el cambio de paquetes para GPUs actuales y la necesidad de recurrir a una rama legacy para las antiguas.
Qué lo vuelve especialmente incómodo para usuarios “de escritorio” (Steam incluido)
El drama no termina en “arranca en consola”. Muchos usuarios que mantienen Pascal/Maxwell lo hacen precisamente por un motivo: todavía rinden bien para juegos ligeros, esports y catálogos enormes en Steam.
Cuando te ves obligado a ir a una rama legacy, aparecen dependencias de 32 bits (Vulkan/OpenGL para Steam y Proton) que pueden obligarte a ajustes extra. En la práctica, lo que era un update normal puede convertirse en una tarde de “cirugía” de paquetes, DKMS, headers del kernel, reinicios y pruebas. Este punto lo subraya la cobertura del incidente: el “camino legacy” no siempre encaja limpio con dependencias modernas, especialmente en entornos rolling.
Cómo evitar quedarte tirado: checklist sysadmin antes de actualizar
Esta es la parte que separa un susto de un desastre:
- Antes de actualizar, identifica la GPU
Si es Pascal/Maxwell, asume que un salto de driver puede dejarte sin entorno gráfico. - Asegura un plan de entrada
- Ten a mano acceso físico, IPMI/iLO/iDRAC, KVM o al menos TTYs.
- Mantén un kernel anterior arrancable en el bootloader.
- No actualices a ciegas en remoto si esa GPU es tu consola de trabajo
Especialmente si el servidor/estación depende del entorno gráfico para tu operativa. - Ten preparado el camino de reversión
- Caché de paquetes (
/var/cache/pacman/pkg/) - Un snapshot (Btrfs/ZFS) si puedes
¿Y NVIDIA qué dice? El matiz importante
Conviene separar dos cosas:
- “No hay soporte en la rama principal” (lo que te afecta en Arch ahora).
- “No hay actualizaciones nunca más” (que no es exactamente lo mismo).
NVIDIA ha comunicado que las GPUs Maxwell/Pascal/Volta pasan a un esquema de actualizaciones de seguridad y que ciertas líneas de soporte se limitan en el tiempo. Eso no equivale a “todo funcionará perfecto para siempre” en una rolling release: significa que, incluso existiendo parches de seguridad, la integración con kernels nuevos, stacks gráficos nuevos y empaquetado distro puede volverse cada vez más frágil.
Alternativas realistas (sin vender humo)
Para un usuario técnico/syadmin, las opciones suelen ser estas:
- Seguir con propietario legacy: viable si aceptas trabajo extra y posibles roces con dependencias actuales.
- Nouveau: alternativa abierta, útil para escritorio básico y hardware veterano, pero con limitaciones conocidas (rendimiento/funciones, especialmente 3D y gaming moderno).
- Actualizar hardware: la opción menos romántica, pero la más limpia si tu flujo depende de estabilidad en drivers, Wayland, Steam/Proton o kernels recientes.
La lectura “de fondo”: el coste oculto de alargar la vida del hardware
Este episodio vuelve a recordar una verdad incómoda: el hardware no se jubila solo por potencia, sino por la cadena de soporte (drivers, kernel, stack gráfico, empaquetado, tooling y dependencias). Y en Linux, cuando el proveedor controla partes críticas del driver, el margen de maniobra de la distribución —y del usuario— se estrecha.
En Arch Linux, el impacto se nota más porque el modelo rolling convierte la decisión de un upstream (NVIDIA) en un cambio inmediato para el usuario final. En otras distros llegará… pero con distinto ritmo y, probablemente, con otro tipo de aterrizaje.
Preguntas frecuentes
¿Cómo saber si mi GPU NVIDIA es Pascal y está afectada en Arch Linux?
Si tu tarjeta es una GTX 10xx (1050 Ti, 1060, 1070, 1080), es Pascal. Puedes confirmarlo con lspci y viendo el modelo exacto.
¿Por qué tras actualizar Arch Linux me devuelve a la consola y no arranca el escritorio?
Porque el driver instalado puede haber pasado a una rama que ya no soporta tu GPU, el módulo no carga y el sistema cae a TTY/CLI.
¿Qué diferencia hay entre nvidia-open y Nouveau?nvidia-open se refiere a los módulos de kernel “open” publicados por NVIDIA para hardware soportado; Nouveau es un driver comunitario por ingeniería inversa.
¿Merece la pena mantener una GTX 1080/1060 en 2026 con Linux rolling?
Depende del uso: para escritorio o cargas moderadas puede seguir siendo útil, pero en rolling release la fricción con drivers, kernels y dependencias (Steam/Vulkan/32-bit) tiende a crecer con el tiempo.
Fuentes:
- NVIDIA (comunicación oficial sobre soporte y actualizaciones de seguridad): (NVIDIA)
- Arch Linux (comunicado del cambio de paquetes/driver y GPUs afectadas): (archlinux.org)
