El kernel 6.14 de Proxmox se queda sin soporte y los admins de homelab lo notan

Las noticias sobre el kernel suelen caer como una tostada seca: necesarias, técnicas y fáciles de ignorar hasta que algo se rompe. Esta no. La serie de kernels de Proxmox basada en 6.14 se ha quedado sin soporte, y el anuncio tocó un nervio muy concreto de la comunidad. El mensaje oficial fue bastante claro: 6.14 ya había vivido más de lo previsto, el goteo de problemas se estaba volviendo excesivo y las rutas con soporte son ahora 6.8 para Proxmox VE 8, 6.17 para Proxmox VE 9 y 7.0 como próximo kernel por defecto de VE 9. Para los usuarios que tenían fijado 6.14 porque su hardware se porta bien con él, pareció menos una tarea de mantenimiento que un empujón.

Actualizar es solo parte del problema

Sobre el papel, "pasa a un kernel con soporte" suena razonable. En la práctica, los sistemas de un homelab están muy lejos de ser diagramitas limpios. Están llenos de controladoras en passthrough, GPU que van envejeciendo, drivers DKMS, pools ZFS y combinaciones de hardware aleatorias que solo funcionaron después de tres fines de semana de maldiciones. Un usuario contó que había vuelto a fijar 6.8 tras sufrir fallos DMAR en 6.17.9. Otro llevaba siglos atascado en 6.14 por los drivers de NVIDIA y el passthrough a contenedores. Detalles así hacen que la retirada de un kernel parezca menos una actualización rutinaria y más alguien cortando el puente colgante mientras todavía hay gente cruzándolo.

El anuncio también puso en marcha un segundo reloj: está previsto que 6.17 empiece a retirarse a principios de julio y pase a recibir actualizaciones en la medida de lo posible, así que el "punto intermedio seguro" tampoco parece muy permanente. El kernel 7.0 es el camino hacia el futuro, pero los caminos hacia el futuro son justo donde les encanta esconderse a los problemas raros de E/S, a los fallos al compilar drivers y a los casos límite del passthrough. La gente no se resiste al cambio por pereza. Muchos están sopesando qué es peor: ejecutar código sin soporte o hacer saltar por los aires una máquina que funciona.

DMAR, passthrough y el horror de los sistemas casi estables

La ansiedad más aguda del hilo vino de los usuarios de passthrough. Una persona enlazó una regresión de DMAR que afecta a hardware Alder Lake y preguntó si los bugs se habían resuelto. Había pasado dispositivos SATA y NVMe con passthrough PCI completo, y después sufrió corrupción de ZFS tras un scrub y tuvo que reconstruir el array. Un incidente así no se despacha encogiéndose de hombros. En cuanto hay almacenamiento de por medio, cada actualización del kernel empieza a parecer una negociación con rehenes. Claro que tienes copias de seguridad, pero también recuerdas el ruido exacto que hizo tu estómago la última vez que el pool se torció.

Hubo contrapuntos. Otro usuario con una placa Supermicro y un Intel i9-14900K dijo que pasaba una controladora SATA integrada a TrueNAS en una VM y que no había visto esos mensajes DMAR manteniéndose al día con los kernels. Alguien más sugirió probar intel_iommu=sp_off, y otro dijo que esa opción le había ayudado con problemas parecidos de passthrough de una NIC de 10G. Ese es el extraño consuelo de estos hilos: nadie tiene una respuesta limpia, pero el montón de historias de hardware acaba siendo un mapa de diagnóstico por sí mismo. "A mí me funciona" no es una prueba, aunque sigue siendo una linterna útil.

Los usuarios de NVIDIA siguen en el sótano

Y luego está NVIDIA, porque siempre está NVIDIA. Un usuario con una GPU de la serie 1000 dijo que seguía sin poder compilar el módulo de NVIDIA con el kernel 6.17. Otro tenía una GTX 1070 que usaba para codificar vídeo y quería saber si la situación de los drivers era segura antes de tocar kernels más nuevos. Alguien sí ofreció un salvavidas: había conseguido compilar y hacer funcionar los drivers NVIDIA 550 con el kernel 7.0 mediante un repo de GitHub. La respuesta fue agradecida, pero prudente. Un script personalizado puede cumplir su función, pero muchos admins prefieren no sostener su stack multimedia con algo que parece estar a un repo del abandono.

Esa tensión es conocida. El mundo del código abierto está lleno de soluciones valientes, y muchas son útiles de verdad, pero los homelabs casi de producción están en un terreno intermedio raro. No son infraestructura corporativa, y sin embargo alojan fotos familiares, servidores Plex, domótica, copias de seguridad, herramientas de teletrabajo y, a veces, servicios de negocio reales. "Prueba el driver parcheado" suena distinto cuando esa máquina es tu único servidor. Que el kernel 6.14 se quede sin soporte no facilita nada con NVIDIA; solo hace que quedarse donde estás parezca peor.

Sin soporte no significa borrado, pero sí quedarse solo

Una pregunta práctica atravesó el pánico: ¿desinstala Proxmox automáticamente los kernels sin soporte que no están en uso? La respuesta del hilo fue que no, al menos no directamente. Proxmox no se mete en tu sistema a arrancar el kernel solo porque ya no tenga soporte. Eso sí, Debian puede ofrecerse a eliminar automáticamente los kernels que considera que ya no hacen falta, así que los usuarios tienen que leer de verdad la salida de apt en lugar de aporrear el sí como si fuera un banner de cookies. También hubo una advertencia: si quitas 6.14 ahora, puede que no puedas reinstalarlo más adelante, cuando desaparezca de los repositorios.

Ese es el peligro oculto de fijar el kernel: parece estabilidad hasta que se convierte en un callejón sin salida. Conservar el kernel antiguo puede dar tiempo, sobre todo si uno más nuevo rompe los drivers de la GPU o el passthrough. Pero en cuanto se acaban las actualizaciones de seguridad y los paquetes siguen adelante, ese montaje fijado empieza a convertirse en una isla. Un comentarista dijo que sus nodos no estaban expuestos fuera de la red y que las reglas del firewall limitaban el acceso, así que de momento había aceptado el riesgo. Es honesto, y también es el tipo de frase que todo admin dice justo antes de añadir un elemento más a su montón de deuda mental.

El camino de actualización es un ejercicio de confianza

La opinión más sólida aquí está entre "todo el mundo debería saltar hoy a 7.0" y "nunca actualices un sistema que funciona": las transiciones de kernel son ejercicios de confianza, y los usuarios de Proxmox tienen muy buena memoria. Si un kernel rompe el passthrough, corrompe el almacenamiento o destroza una compilación DKMS, la gente no lo olvida solo porque el siguiente anuncio diga que la rama anterior se ha acabado. Quieren notas claras, informes de hardware que se sabe que funciona, opciones de vuelta atrás y suficiente conversación en la comunidad para saber si se están metiendo en un campo de minas. Eso es mantenimiento corriente.

Quedarse congelado para siempre tampoco es un plan. El camino razonable es aburrido pero real: mantén las copias de seguridad al día, confirma que todavía tienes un kernel antiguo arrancable, prueba el kernel nuevo antes de quitar nada, vigila apt como un halcón y lee los informes específicos de tu hardware antes de confiarle al futuro tu stack raro. La salida del kernel 6.14 duele porque obliga a tomar una decisión que los usuarios ya venían aplazando, y por eso el hilo se nota tan tenso. A nadie le molesta que el software sin soporte acabe muriendo. Les molesta porque, para algunos sistemas, era la última versión que se portaba bien.