apt upgrade vs dist-upgrade: la trampa en Proxmox en la que casi todos caen

Si pasas suficiente tiempo en el mundo del homelab, verás repetirse la misma historia una y otra vez: alguien se dispone a lanzar actualizaciones, un comando erróneo se cuela por memoria muscular y de repente su host de Proxmox se mantiene en pie a base de cinta aislante y esperanza. La última anécdota que circula por foros cuenta exactamente eso. Un apt upgrade fuera de lugar ejecutado desde la automatización, un repositorio extraviado de trixie al acecho en las fuentes sin que nadie lo advirtiera, y un sistema Proxmox 8 en perfecto estado que amaneció con un puñado de paquetes de Proxmox 9 soldados encima.

No hace falta ser descuidado ni ignorar la documentación para acabar en este punto. Resulta facilísimo asumir que apt upgrade, el comando que casi cualquier usuario de Linux teclea en piloto automático, es seguro en cualquier sitio. ¿En Debian? Claro. ¿En Ubuntu? Por lo general. En un hipervisor que incorpora su propia lógica de dependencias y se enlaza de forma íntima con la distribución subyacente, ahí es donde empiezan los problemas, y casi todo el mundo se da de bruces contra este muro tarde o temprano.

El comando diminuto que rompe cosas grandes

La situación del usuario se desarrolló de un modo dolorosamente familiar. Acababa de leer que apt upgrade puede romper Proxmox, pero un error tipográfico en Ansible lo ejecutó igualmente. La actualización avanzó sin quejas, al principio nada parecía catastrófico y las VM seguían activas. Entonces llegó el síntoma grave: la interfaz gráfica web de Proxmox había desaparecido.

Este es el momento en que la mayoría empieza a sudar frío. Cuando la interfaz se apaga pero el nodo sigue arrancando, entras en ese limbo inquietante donde el sistema está vivo pero no sano. En esta ocasión, la prueba irrefutable apareció en pveversion -v, que arrojó una lista caótica de paquetes procedentes a la vez de Proxmox 8 (Bookworm) y de Proxmox 9 (Trixie). Era una actualización parcial entre versiones mayores, el peor escenario imaginable.

En cuanto obtienes componentes esenciales como pve-manager, libpve-* o qemu-server de una versión mayor por delante del resto del sistema, te encuentras lidiando con dependencias desajustadas que no se ponen de acuerdo sobre versiones de libc, módulos auxiliares del kernel o paquetes básicos de Perl. Terminas con decenas de paquetes retenidos y un árbol de dependencias que parece una torre de Jenga a punto de caer. Eso fue lo que ocurrió aquí, y muchos intervinieron para confirmar que habían pasado por lo mismo.

Por qué apt upgrade es una trampa

La documentación de Proxmox lo explica con claridad, pero muchos usuarios, sobre todo quienes vienen de Debian o Ubuntu, lo pasan por alto:

• apt upgrade solo actualiza paquetes que no introducen nuevas dependencias.
• Proxmox a menudo requiere dependencias nuevas durante las actualizaciones, incluso en las menores.
• Al bloquear esas dependencias, las actualizaciones de Proxmox se aplican solo a medias, el estado más peligroso posible.

En un sistema Linux convencional, esta limitación suele ser inofensiva. Un hipervisor es un entorno muy distinto: una pila estrechamente orquestada donde la interfaz web, el gestor de clúster, QEMU, el almacenamiento, las bibliotecas de red e incluso el código de integración intermedio esperan evolucionar al unísono.

Ejecutar apt upgrade puede dejarte con:

• piezas nuevas de Proxmox
• piezas antiguas de Proxmox
• kernels desalineados
• paquetes retenidos por tiempo indefinido
• y dependencias incapaces de instalarse sin cambiar de versión de repositorio

Así es como una única actualización acaba descargando paquetes de Proxmox 9 sin que nadie lo perciba, pese a que el sistema sigue basándose formalmente en Proxmox 8.

Entonces, ¿qué ocurrió realmente aquí?

Tras investigar un poco, el autor encontró el origen: tiempo atrás se había añadido una fuente de apt que apuntaba al repositorio "trixie" de Proxmox 9 sin que nadie se percatara. Cuando se ejecutó apt upgrade, recogió los parches habituales y además incorporó con total naturalidad paquetes de la siguiente versión mayor.

Una sola línea en sources.list.d bastó para incorporar:

• nuevos módulos auxiliares del kernel
• nuevos componentes de la interfaz web
• nuevas bibliotecas de clúster
• y un puñado de paquetes dependientes de Debian Trixie, no de Debian Bookworm

Una vez producida esa mezcla, no hay vuelta atrás sencilla. No puedes degradar libc sin romper el sistema. No puedes degradar paquetes de Proxmox a medio actualizar sin perseguir dependencias a mano. Y no puedes limitarte a actualizarlo todo limpiamente porque el resto del sistema sigue anclado en Bookworm.

Por eso varios comentarios coincidieron en lo mismo: llegados a este punto, actualizar por completo a Proxmox 9 podría ser la única vía estable hacia adelante.

Los intentos de rescate que sugirió la comunidad

Muchos usuarios aportaron soluciones, algunas prudentes y otras más arriesgadas.

1. Intentar reparar el sistema mediante:

apt update
apt --fix-broken install
dpkg --configure -a
apt clean
apt dist-upgrade

Esto da resultado cuando las dependencias están solo ligeramente enredadas. En este caso particular, no sirvió de mucho.

El sistema reportó más de 70 paquetes retenidos y una larga lista de dependencias incumplidas que afectaban a libc, perl, OpenSSL y módulos centrales de Proxmox. Cuando aparecen desajustes en libc, cualquiera familiarizado con Debian sabe que la habitación se está llenando de humo.

2. Intentar reinstalar los componentes de la interfaz gráfica

Algunos usuarios sugirieron reinstalar pve-manager y proxmox-widget-toolkit. Esto tampoco funcionó, porque el sistema lo rechazó debido a dependencias insatisfechas originadas por las versiones desparejadas de Debian.

3. Localizar los repositorios mezclados y completar el paso a Proxmox 9

Con diferencia, la propuesta más práctica fue que, si ya estás a mitad de camino dentro de Proxmox 9, bien puedes dar el salto definitivo. Eso implica cambiar cada repositorio de Bookworm a Trixie, ejecutar una actualización completa y permitir que Proxmox 9 termine lo que Proxmox 8 ya no puede ordenar.

No es una maniobra apta para principiantes. Con todo, resulta menos farragosa que intentar revertir quirúrgicamente decenas de paquetes que ni siquiera existen ya en repositorios anteriores.

4. Reinstalación completa (la opción nuclear)

Nadie quiere llegar a este extremo, y todo el mundo sabe que equivale al botón de rendición. El autor también aclaró que no disponía de copias de seguridad completas de las VM, sino únicamente de archivos sueltos.

Aun así, varios participantes reconocieron que, si el intento de reparación fracasa y la ruta de actualización al 9 se estrella, reinstalar puede ser la última salida segura.

Por qué incluso usuarios con experiencia caen en esto

Muchos dejaron comentarios parecidos a: "Un momento… ¿dist-upgrade es la vía recomendada? Llevo un año usando apt upgrade".

Esa reacción resume por qué esto sigue pasando. El instinto de un usuario veterano de Linux choca con las reglas específicas del ecosistema de Proxmox, y el comando que resulta seguro en Debian se transforma en el peligroso dentro de este entorno.

Hay además un detalle añadido: Proxmox incluye sus propias utilidades de actualización, pveupdate y pveupgrade. Muchos usuarios las pasan por alto por completo porque apt les resulta universal y cercano. Y dado que la mayor parte de Proxmox no es más que Debian por debajo, es fácil olvidar que ciertas partes no lo son.

Juntas todos esos factores y obtienes la tormenta perfecta: un entorno de homelab, hábitos aprendidos a medias, un retoque rápido en la automatización y de pronto estás ejecutando Proxmox 8 con módulos del kernel de Proxmox 9 en un sistema Debian 12 que se cree medio Debian 13. Llegados a ese punto, hasta el propio sistema está confundido.

La lección de fondo a la que siempre vuelve la comunidad

Todo este hilo insiste en algo que los veteranos de Proxmox llevan años repitiendo: tu hipervisor no es lugar para comandos dictados por la costumbre. Actualizarlo no se parece en nada a poner al día un portátil o un servidor web, porque constituye una capa de orquestación entera situada por debajo de tus VM, tus contenedores y, en algunos casos, tu almacenamiento.

Lo que significa:

• Revisa siempre tus repositorios antes de actualizar
• Usa siempre los comandos recomendados por Proxmox
• Haz siempre una copia de seguridad antes de una actualización mayor
• Apaga siempre las máquinas virtuales antes de aplicar actualizaciones profundas
• Comprueba tres veces cualquier cambio que toque la automatización

La paradoja es que una simple errata, literalmente un cambio de una sola línea, puede provocar horas de tareas de rescate y la sospecha persistente de que algún otro elemento podría seguir dañado.

Esto pasa mucho más de lo que la gente reconoce

A juzgar por las reacciones, casi cualquiera en este entorno ha cometido exactamente este fallo al menos una vez. Algunos descubrieron la regla de dist-upgrade tras un buen susto. Otros vieron venirse abajo las dependencias tras lanzar apt upgrade. Y muchos admitieron que jamás se habían percatado de que la documentación de Proxmox desaconseja de forma explícita su uso.

Es uno de esos ritos de iniciación que nadie busca pero por el que todos terminan pasando. Probablemente por eso esta historia conectó con tanta gente: más allá del problema técnico, recuerda que incluso en un espacio lleno de veteranos de Linux, los pequeños detalles siguen importando, y las herramientas que crees dominar mejor a veces son las que te dan el golpe más duro.

La conclusión clave para cualquiera que use Proxmox

Si no recuerdas nada más, quédate con esto: en Proxmox, apt dist-upgrade (o full-upgrade) es la opción segura, y apt upgrade es la que te mete en problemas.

Y si tu sistema empieza alguna vez a descargar paquetes de una versión futura, detente y comprueba tres veces tus repositorios antes de tocar cualquier otra cosa. Ese hábito marca la diferencia entre una ruta de actualización limpia y un fin de semana intentando reconstruir las piezas rotas, porque en los hipervisores de homelab el daño suele venir de pequeñas trampas ocultas en comandos que ejecutas sin pensar, con mucha más frecuencia que de un fallo catastrófico.