Atascado esperando a Proxmox 9.2: a la caza de kernels más nuevos para ROCm
El punto de ruptura: cuando tu kernel frena tu curiosidad
Hay frustraciones que solo aparecen cuando llevas un montaje más allá de aquello para lo que se hizo. Aquí no era nada escandaloso: ROCm, algunas cargas de LLM, ver de qué es capaz el hardware. Y entonces llegó un muro: ni un cuelgue ni una mala configuración, solo un kernel un poco demasiado viejo.
Surviving the Proxmox VE 9.2 Upgrade: Kernel 7.0 Anxiety, vGPU, & ZFS Risks
Esa es la tensión central de toda esta situación. El usuario no persigue el caos de lo más nuevo, solo un kernel que corrija un par de problemas de upstream, y el camino no está claro. "No veo forma de actualizar sin esperar a la 9.2", admite, y nada indica que la 9.2 esté cerca.
El baño de realidad: "Proxmox no va a tu ritmo"
Una de las respuestas más sensatas despeja la confusión de golpe: Proxmox sigue los kernels de Ubuntu. Eso lo explica todo y lo empeora, porque el retraso está en la cadena upstream y no en el propio Proxmox.
Estás esperando a que se alineen varias capas: el calendario del kernel de Ubuntu, la integración de Proxmox y luego la versión que lo empaqueta. Funciona como una tubería, y no hay ningún interruptor que pulsar. Otro comentarista añadió que, para prever lo que viene, conviene mirar la hoja de ruta de Ubuntu en lugar de los anuncios de Proxmox. Es lógico y ordenado, y desesperadamente lento.
Los hackers: "Pon un kernel nuevo y apáñatelas"
No todo el mundo espera. Siempre hay alguien que se encoge de hombros: "Instala un kernel nuevo y mira si funciona". Es medio consejo, medio desafío.
Es la libertad del homelab: nada es producción, así que puedes romper cosas y volver atrás. Pero fuera de la pila con soporte estás solo. Depurar se vuelve más difícil, las actualizaciones se complican y un entorno Proxmox predecible va derivando hacia algo frágil. Para algunos, esperar sigue siendo peor que trastear.
El bando de los apaños: "Si el host no puede, usa una VM"
El movimiento pragmático es dejar de pelearse con el kernel del host. Levanta una VM, pásale la GPU y ejecuta la distribución que quieras, sea Fedora, Arch o cualquier otra con el kernel que necesitas.
No sale gratis. El passthrough de GPU tiene sus propios quebraderos de cabeza; a un usuario le "encantaría" cambiar del todo, pero se echó atrás por la complejidad del passthrough de la iGPU para sus cargas de trabajo, y esa fricción puede echar por tierra la idea. Aun así, Proxmox sigue siendo el hipervisor estable mientras los kernels más nuevos se ejecutan donde importan.
La capa de confusión: Debian, Ubuntu y qué es Proxmox en realidad
Parte de esto es una confusión de identidad. Proxmox se basa en Debian, pero la historia del kernel lo complica. Como dijo un comentarista sorprendido: "Pensaba que Proxmox se basaba en Debian… pero usa un kernel de Ubuntu modificado".
Esperas los plazos de Debian, pero estás atado al ritmo del kernel de Ubuntu, y eso cambia cómo planificas una actualización, cómo diagnosticas la compatibilidad y qué expectativas te pones.
El panorama general: algo más que un número de versión
Lo que resulta fácil de reconocer es el desfase: el hardware está listo, upstream tiene la corrección y la plataforma va un paso por detrás.
Puedes esperar y mantenerlo limpio, forzar el avance y aceptar el riesgo, o añadir apaños que cambian complejidad por progreso. Ninguna opción es perfecta.
Al final, Proxmox 9.2 es solo el ejemplo actual de la negociación permanente entre estabilidad y curiosidad, y si ejecutas cargas de LLM en un homelab, ya sabes hacia qué lado te inclinas.