Repositorio no-subscription de Proxmox: configurar repos sin romper actualizaciones

noviembre 22, 2025 • febrero 3, 2026 • Lectura: 23 min • Views: 10

¿Te fue útil?

Esa molesta pancarta roja de “No valid subscription” es irritante, pero no es tu verdadero problema. El problema real es la media solución: activar y desactivar repositorios al azar hasta que apt update deje de gritar, justo hasta que la siguiente actualización convierta tu nodo en una pieza de museo.

Si ejecutas Proxmox en producción sin una suscripción, puedes hacerlo correctamente. Pero debes tratar los repositorios APT como gestión de cambios, no como un humor. Esta guía muestra exactamente cómo configurar el repositorio no-subscription correctamente, mantener alineados los suites de Debian y Proxmox, y actualizar sin jugar a la ruleta.

Qué estás cambiando realmente (y por qué importa)

Cuando “cambias al repositorio no-subscription”, no estás girando un interruptor cosmético. Estás cambiando de dónde provienen los paquetes de Proxmox (kernel, qemu, pve-manager, pve-kernel, corosync, a menudo paquetes de Ceph), lo que altera:

Cadencia de actualizaciones: el repositorio enterprise está curado y retrasado; el no-subscription está más cerca de la canalización de empaquetado upstream.
Grafo de dependencias: los paquetes de Proxmox están ligados a una suite Debian específica (por ejemplo, Bullseye o Bookworm). Mezclar suites es como provocar una deriva silenciosa de dependencias.
Seguridad del camino de actualización: las actualizaciones de Proxmox son en realidad upgrades mayores de Debian coordinados más componentes de Proxmox. Los repos son la hoja de ruta; si los configuras mal, te sales del camino.

Es perfectamente legítimo ejecutar no-subscription en laboratorios y en muchas empresas reales. La disciplina que necesitas es la misma que aplicarías a actualizaciones de kernel en producción: fuentes consistentes, suites explícitas y nada de “sólo este paquete desde testing”.

Una cita que sigue siendo válida (idea parafraseada): “En operaciones, la automatización y los valores predeterminados cuidadosos previenen errores humanos repetidos.” — idea parafraseada atribuida a Gene Kim (temas de operaciones DevOps)

Hechos e historia que explican el lío actual de repositorios

La configuración de repos en Proxmox parece extraña hasta que recuerdas cómo creció el proyecto: pila de virtualización, base Debian, Ceph opcional y un canal de soporte de pago. Algo de contexto hace que las convenciones actuales parezcan menos arbitrarias.

Proxmox se basa en Debian por diseño, no solo “compatible con Debian”. Eso significa que APT es de primera clase y la alineación de suites Debian no es negociable.
El repositorio “enterprise” existe principalmente por soporte: actualizaciones más lentas y curadas que coinciden con lo que los clientes que pagan esperan en ventanas de cambio.
El repositorio “no-subscription” no es “inestable”; simplemente tiene menos retraso. Normalmente los paquetes llegan allí antes después de probarse, y esa diferencia de tiempo importa para el riesgo.
La pancarta de suscripción es de nivel UI (pve-manager revisa el estado de repos/suscripción). No es tu hipervisor negándose a funcionar.
Las versiones mayores de Proxmox siguen de cerca los lanzamientos de Debian. Si tu base Debian es Bookworm y tus repos de Proxmox aún apuntan a Bullseye, tienes un sistema con conflicto de identidades.
Ceph en Proxmox está fijado por versión por Proxmox porque los clústeres requieren versiones compatibles en todos los nodos. La discrepancia de repos puede crear un cluster donde la mitad de los nodos quiera un Ceph distinto.
Históricamente, Proxmox empaquetó kernels personalizados temprano para ofrecer funciones de KVM/QEMU sin esperar a Debian stable. Eso es bueno—hasta que tiras de un kernel de la suite equivocada por accidente.
El pinning de APT existe desde los primeros días de Debian para manejar exactamente este problema: múltiples repos, una sola política. La gente lo olvida y luego lo reinventan mal con “hold” por todos lados.

El modelo de repositorios de Proxmox: enterprise vs no-subscription vs Debian

1) Repositorios Debian

Tu nodo es Debian. Debian proporciona el userland base: libc, systemd, openssl, python, journald y mucha infraestructura “aburrida” sobre la que se sostiene Proxmox. Proxmox espera suites Debian específicas:

PVE 7.x → Debian 11 (bullseye)
PVE 8.x → Debian 12 (bookworm)

Cuando actualizas versiones mayores de PVE, estás efectivamente realizando una actualización mayor de Debian más los paquetes de Proxmox. Eso significa que tus líneas deb de Debian deben coincidir con tu versión mayor de PVE.

2) Repositorio enterprise de Proxmox

Este es el canal de pago. Si no tienes suscripción, dejar enterprise habilitado normalmente produce 401 Unauthorized o errores de apt. Lo peor no es el error; es lo que la gente hace después: añaden repos extra para “arreglarlo” y crean accidentalmente un host Frankenstein con suites mezcladas.

3) Repositorio no-subscription de Proxmox

Este es el repositorio correcto para sistemas sin suscripción. Está mantenido por Proxmox, pero sin el filtrado enterprise. Aún recibirás actualizaciones de seguridad; simplemente en un cronograma diferente.

4) Repos de Ceph (si usas Ceph)

Si ejecutas Proxmox con Ceph, trata los repos de Ceph como parte de la plataforma, no como un aderezo opcional. Proxmox suele esperar una versión mayor de Ceph por cada versión de PVE. Mezclar repos de Ceph es la forma de convertir un clúster de almacenamiento en arte abstracto.

Broma #1: Los repositorios APT son como las máquinas de café de la oficina: todos creen que pueden “ajustarla un poco” y luego nadie puede trabajar.

Línea base: cómo debe verse una configuración no-subscription correcta

Una configuración correcta tiene tres rasgos:

Solo un canal de Proxmox (enterprise O no-subscription, no ambos).
La suite de Debian coincide con la versión mayor de PVE (bullseye para PVE7, bookworm para PVE8).
Repos de Ceph alineados (o el repo de Ceph proporcionado por Proxmox para tu release de PVE, o ninguno si no usas paquetes Ceph).

Proxmox usa una mezcla de /etc/apt/sources.list y /etc/apt/sources.list.d/*.list. Tu objetivo es la claridad. Si no puedes explicar qué hace cada línea, no pertenece a producción.

Tareas prácticas con comandos, salidas y decisiones (12+)

Task 1: Identifica tus versiones de Proxmox y Debian (no adivines)

cr0x@server:~$ pveversion -v
proxmox-ve: 8.2.2 (running kernel: 6.8.12-2-pve)
pve-manager: 8.2.4 (running version: 8.2.4/2f1f9a3d)
pve-kernel-6.8: 6.8.12-2
qemu-server: 8.2.2
pve-qemu-kvm: 9.0.2-3

Qué significa: Esto es PVE 8.x. Tu base Debian debe ser Bookworm, y la suite de tu repo de Proxmox debería ser bookworm.

Decisión: Si ves PVE 7.x, usa suites Bullseye. Si PVE 8.x, usa Bookworm. Cualquier desajuste es un problema crítico antes de actualizar.

cr0x@server:~$ cat /etc/debian_version
12.5

Qué significa: Debian 12 (Bookworm). Eso coincide con PVE 8.x. Bien.

Decisión: Si esto muestra Debian 11 mientras tienes PVE 8, ya estás en una situación de actualización parcial. Arregla los repos antes de tocar otra cosa.

Task 2: Volcar todas las fuentes APT en una vista (los humanos necesitan una página)

cr0x@server:~$ grep -R --line-number --no-messages '^deb ' /etc/apt/sources.list /etc/apt/sources.list.d/*.list
/etc/apt/sources.list:1:deb http://deb.debian.org/debian bookworm main contrib
/etc/apt/sources.list:2:deb http://deb.debian.org/debian bookworm-updates main contrib
/etc/apt/sources.list:3:deb http://security.debian.org/debian-security bookworm-security main contrib
/etc/apt/sources.list.d/pve-no-subscription.list:1:deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription
/etc/apt/sources.list.d/pve-enterprise.list:1:deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise

Qué significa: Tanto enterprise como no-subscription están habilitados. Eso no es “redundancia extra”, es una política en conflicto.

Decisión: Desactiva enterprise si no tienes suscripción. Mantén solo no-subscription.

Task 3: Desactivar enterprise limpiamente (no borres historial a menos que sea necesario)

cr0x@server:~$ sudo sed -i 's/^[[:space:]]*deb /# deb /' /etc/apt/sources.list.d/pve-enterprise.list

cr0x@server:~$ cat /etc/apt/sources.list.d/pve-enterprise.list
# deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise

Qué significa: La línea del repo enterprise está comentada, preservada para auditoría.

Decisión: Si tienes suscripción, haz lo contrario: mantén enterprise y desactiva no-subscription. Elige uno.

Task 4: Asegurar que el repo no-subscription exista y apunte a la suite correcta

cr0x@server:~$ cat /etc/apt/sources.list.d/pve-no-subscription.list
deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription

Qué significa: Correcto para PVE 8.x en Bookworm.

Decisión: Si ves bullseye aquí en un host Bookworm, arréglalo antes de actualizar.

Task 5: Ejecutar apt update e interpretar fallos como un adulto

cr0x@server:~$ sudo apt update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://deb.debian.org/debian bookworm-updates InRelease
Hit:3 http://security.debian.org/debian-security bookworm-security InRelease
Hit:4 http://download.proxmox.com/debian/pve bookworm InRelease
Reading package lists... Done
Building dependency tree... Done
All packages are up to date.

Qué significa: La autenticación del repo está bien, los archivos de release son válidos y APT está contento.

Decisión: Si obtienes 401 Unauthorized, todavía tienes enterprise habilitado o las credenciales en caché son incorrectas. Si obtienes “Release file changed”, confirma que estás en la suite prevista.

Task 6: Inspeccionar versiones candidatas para detectar suites mixtas (silenciosamente mortales)

cr0x@server:~$ apt-cache policy pve-manager
pve-manager:
  Installed: 8.2.4
  Candidate: 8.2.4
  Version table:
 *** 8.2.4 500
        500 http://download.proxmox.com/debian/pve bookworm/pve-no-subscription amd64 Packages
        100 /var/lib/dpkg/status

Qué significa: pve-manager proviene únicamente del repo Proxmox previsto.

Decisión: Si ves candidatos de múltiples suites o repos desconocidos, detente y elimina los agresores. Orígenes mixtos pueden producir actualizaciones “exitosas” pero operativamente rotas.

Task 7: Detectar dependencias Debian cruzadas antes de actualizar

cr0x@server:~$ apt-cache policy libc6 | sed -n '1,12p'
libc6:
  Installed: 2.36-9+deb12u9
  Candidate: 2.36-9+deb12u9
  Version table:
 *** 2.36-9+deb12u9 500
        500 http://deb.debian.org/debian bookworm/main amd64 Packages
        500 http://security.debian.org/debian-security bookworm-security/main amd64 Packages
        100 /var/lib/dpkg/status

Qué significa: libc6 es estrictamente Bookworm. Bien.

Decisión: Si ves un candidato desde testing, sid u otra release Debian, tienes deriva de repos. Arregla las fuentes y posiblemente aplica pinning.

Task 8: Verificar las suites configuradas a nivel del sistema (sanidad de preferencias APT)

cr0x@server:~$ apt-cache policy | sed -n '1,40p'
Package files:
 100 /var/lib/dpkg/status
 500 http://download.proxmox.com/debian/pve bookworm InRelease
 500 http://security.debian.org/debian-security bookworm-security InRelease
 500 http://deb.debian.org/debian bookworm-updates InRelease
 500 http://deb.debian.org/debian bookworm InRelease
Pinned packages:

Qué significa: Solo están presentes Bookworm y los repos Proxmox Bookworm.

Decisión: Si ves bullseye + bookworm simultáneamente, casi siempre está mal salvo durante una ventana de upgrade mayor cuidadosamente gestionada.

Task 9: Buscar paquetes en hold (a veces están justificados, a menudo olvidados)

cr0x@server:~$ apt-mark showhold
pve-kernel-6.5.13-5-pve

Qué significa: Alguien marcó un kernel antiguo en hold. Puede ser por un workaround de drivers. O puede no tener razón.

Decisión: Si es intencional, documéntalo y planifica su remoción. Si es accidental, quítale el hold o fallarás futuras actualizaciones con errores de dependencias extraños.

cr0x@server:~$ sudo apt-mark unhold pve-kernel-6.5.13-5-pve
Canceled hold on pve-kernel-6.5.13-5-pve.

Task 10: Simular una actualización antes de hacerla (seguro barato)

cr0x@server:~$ sudo apt -o Debug::pkgProblemResolver=yes -s dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Calculating upgrade... Done
The following packages will be upgraded:
  pve-manager pve-kernel-6.8.12-2-pve proxmox-ve qemu-server
4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Inst pve-kernel-6.8.12-2-pve [6.8.12-1] (6.8.12-2 Proxmox bookworm/pve-no-subscription amd64)
Inst pve-manager [8.2.3] (8.2.4 Proxmox bookworm/pve-no-subscription amd64)
Inst proxmox-ve [8.2.1] (8.2.2 Proxmox bookworm/pve-no-subscription amd64)
Inst qemu-server [8.2.1] (8.2.2 Proxmox bookworm/pve-no-subscription amd64)
Conf proxmox-ve (8.2.2 Proxmox bookworm/pve-no-subscription amd64)

Qué significa: La actualización es directa: sin eliminaciones, sin maniobras raras del resolvedor.

Decisión: Si la simulación propone eliminar proxmox-ve, pve-manager o la mitad de tu pila de red, detente. Eso indica repos mixtos, pins o una actualización parcial.

Task 11: Confirmar tu kernel en ejecución vs kernels instalados (evita sorpresas al reiniciar)

cr0x@server:~$ uname -r
6.8.12-1-pve

cr0x@server:~$ dpkg -l 'pve-kernel-*' | awk '/^ii/ {print $2, $3}'
pve-kernel-6.8.12-1-pve 6.8.12-1
pve-kernel-6.8.12-2-pve 6.8.12-2

Qué significa: El kernel nuevo está instalado pero aún no en ejecución.

Decisión: Planifica una ventana de reinicio. Las actualizaciones de kernel sin reinicios son como comprar extintores y dejarlos en la tienda.

Task 12: Comprobar la salud de servicios Proxmox tras las actualizaciones (no confíes en “apt succeeded”)

cr0x@server:~$ systemctl --failed
  UNIT LOAD ACTIVE SUB DESCRIPTION
0 loaded units listed.

Qué significa: No hay unidades systemd fallidas.

Decisión: Si ves pveproxy o pvedaemon fallando, tu actualización no está “terminada”. Arregla eso antes de tocar otro nodo.

Task 13: Si usas cluster, confirma la salud del cluster antes y después de cambiar repos

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   27
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Thu Dec 26 14:03:41 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2a
Quorate:          Yes

Qué significa: Tienes quórum. No estás cambiando repos en un nodo que ya está en llamas.

Decisión: Si no hay quórum, no actualices. Arregla la comunicación del cluster primero.

Task 14: Si ejecutas Ceph, confirma origen de paquetes Ceph y estado del cluster

cr0x@server:~$ ceph -s
  cluster:
    id:     9a1b2c3d-1111-2222-3333-abcdefabcdef
    health: HEALTH_OK

  services:
    mon: 3 daemons, quorum a,b,c (age 5h)
    mgr: a(active, since 5h), standbys: b
    osd: 12 osds: 12 up (since 5h), 12 in (since 5h)

  data:
    pools:   4 pools, 128 pgs
    objects: 3.1M objects, 12 TiB
    usage:   36 TiB used, 72 TiB / 108 TiB avail
    pgs:     128 active+clean

Qué significa: Ceph está sano en este momento.

Decisión: Si Ceph está degradado, no apiles actualizaciones encima. Los cambios de repos que alteran versiones de Ceph pertenecen a ventanas de mantenimiento con planes explícitos de rolling upgrade.

cr0x@server:~$ apt-cache policy ceph-common | sed -n '1,20p'
ceph-common:
  Installed: 18.2.2-pve1
  Candidate: 18.2.2-pve1
  Version table:
 *** 18.2.2-pve1 500
        500 http://download.proxmox.com/debian/ceph-reef bookworm InRelease
        100 /var/lib/dpkg/status

Qué significa: Los paquetes Ceph vienen del repo Ceph proporcionado por Proxmox para esta serie de Ceph (ejemplo: Reef).

Decisión: Si los paquetes Ceph provienen de Debian main o de repos de terceros aleatorios, detente. Alinea con el repo Ceph de Proxmox que coincida con tu matriz de soporte PVE.

Task 15: Detectar y eliminar repos “útiles” de terceros

cr0x@server:~$ ls -1 /etc/apt/sources.list.d
pve-enterprise.list
pve-no-subscription.list
random-kernel-tuning.list

cr0x@server:~$ cat /etc/apt/sources.list.d/random-kernel-tuning.list
deb http://deb.debian.org/debian sid main

Qué significa: Alguien añadió Debian sid. Así es como obtienes libstdc++ nuevo a las 14:00 y una caída a las 14:05.

Decisión: Elimínalo o coméntalo inmediatamente salvo que estés deliberadamente ejecutando una suite mixta con pinning (raro, deliberado, documentado).

Task 16: Usa pinning de APT si tienes una excepción justificada (y documéntala)

Si realmente debes mantener un repo extra (por una herramienta de drivers específica, por ejemplo), haz pinning para que no pueda “ganar” por accidente. Ejemplo mínimo que prefiere Bookworm y Proxmox, permitiendo un repo externo solo cuando se solicite explícitamente.

cr0x@server:~$ sudo tee /etc/apt/preferences.d/99-local-pinning >/dev/null <<'EOF'
Package: *
Pin: release n=bookworm
Pin-Priority: 990

Package: *
Pin: origin "download.proxmox.com"
Pin-Priority: 990

Package: *
Pin: release a=unstable
Pin-Priority: 50
EOF

cr0x@server:~$ apt-cache policy | sed -n '1,60p'
Package files:
 100 /var/lib/dpkg/status
 500 http://download.proxmox.com/debian/pve bookworm InRelease
 500 http://security.debian.org/debian-security bookworm-security InRelease
 500 http://deb.debian.org/debian bookworm InRelease
 500 http://deb.debian.org/debian sid InRelease
Pinned packages:
     release n=bookworm priority 990
     origin download.proxmox.com priority 990
     release a=unstable priority 50

Qué significa: APT preferirá casi siempre Bookworm y Proxmox. Unstable está visible pero efectivamente “opt-in”.

Decisión: Si no necesitas repos extra, no los añadas. El pinning es un cinturón de seguridad, no un permiso para acrobacias.

Guion de diagnóstico rápido

Cuando las actualizaciones fallan, quieres encontrar el cuello de botella rápido: repo equivocado, suite equivocada, paquetes rotos o restricciones de cluster. Aquí está el orden que ahorra tiempo.

Primero: alcance y autenticación del repo

Ejecuta apt update. Busca 401, errores de Release file o fallos DNS/TLS.
Si 401 Unauthorized: el repo enterprise está habilitado sin credenciales. Desactívalo.
Si TLS o DNS falla: arregla red, sincronización de tiempo o ajustes de proxy antes de cambiar repos.

Segundo: alineación de suites (Debian y Proxmox deben coincidir)

Comprueba pveversion -v y /etc/debian_version.
Vuelca todas las líneas deb con grep a través de las fuentes.
Cualquier mezcla Bullseye/Bookworm fuera de una ventana de upgrade es objetivo inmediato de rollback.

Tercero: vista previa del resolvedor de dependencias

Simula apt -s dist-upgrade.
Señales de alarma: propone eliminaciones de proxmox-ve, pve-manager, corosync, systemd, libc6, ifupdown2.
Estrategia de resolución: elimina repos extraños; quita holds; arregla pins; luego resimula.

Cuarto: restricciones de cluster y almacenamiento

Si estás en cluster: verifica quórum (pvecm status) antes de tocar nada.
Si Ceph: verifica ceph -s y orígenes de paquetes Ceph. No cambies repos de Ceph en medio de un incidente.

Tres mini-historias corporativas desde las trincheras de los repos

Mini-historia 1: El incidente causado por una suposición equivocada

Tenían un pequeño cluster Proxmox usado para herramientas internas: runners CI, ticketing, una VM de monitorización que todos olvidaron que era crítica hasta que dejó de serlo. Sin suscripción. Alguien vio la pancarta de suscripción y decidió “ordenar”.

La suposición: “El repo enterprise solo da mejores actualizaciones; no hará daño dejarlo.” Habilitaron enterprise, ejecutaron apt update, obtuvieron error de autenticación y lo “arreglaron” añadiendo un repo Debian que encontraron en un hilo de foro. Ese repo resultó ser de otra suite Debian.

La actualización pareció normal al principio. Se actualizaron algunos paquetes. Luego los servicios de Proxmox empezaron a reiniciarse de forma extraña. La UI web fluctuaba. Las operaciones de arranque de VMs fallaban intermitentemente porque qemu y librerías ya no coincidían con el set de dependencias esperado.

El postmortem fue aburrido en el buen sentido: APT hizo exactamente lo que le dijeron. Las fuentes del sistema describían un SO que no existía. La solución también fue aburrida: eliminar enterprise para nodos sin suscripción, volver a la suite Debian correcta y volver a ejecutar la actualización en secuencia controlada con simulaciones primero.

Lo que cambiaron después: añadieron una checklist previa al cambio para ediciones de repos y convirtieron “volcar todas las fuentes APT” en un paso obligatorio antes de cualquier actualización. No fue nada sofisticado. Detuvo la hemorragia.

Mini-historia 2: La optimización que salió mal

Otro equipo quería actualizaciones más rápidas, CI más veloz, todo más rápido. Crearon un proxy de caching local para APT y replicaron “todo lo que podrían necesitar” para acelerar instalaciones. Objetivo excelente. El error fue sutil: replicaron múltiples suites y no forzaron cuál suite debían usar los clientes.

Con el tiempo, nodos empezaron a tirar paquetes del caché que no coincidían con su release OS, porque el caché se los presentaba y las prioridades de APT básicamente eran “lo que parezca más nuevo”. No fue malicia; fue entropía como servicio.

Durante meses “funcionó”, hasta que una actualización de seguridad subió una dependencia central. De repente, un subconjunto de nodos actualizó una librería desde la suite equivocada y los paquetes Proxmox en esos nodos rechazaron configurarse correctamente. La caída no fue total; fue peor: parcial, intermitente y difícil de reproducir.

La solución no fue abandonar el caching. Fue restringirlo. Dividieron caches por suite (Bookworm vs Bullseye), forzaron líneas de repos coherentes y usaron pinning para que “lo más nuevo” no significara “lo equivocado”. Volvió el rendimiento. Volvió la cordura.

Mini-historia 3: La práctica correcta y aburrida que salvó el día

Esta es a propósito poco sexy. Una organización financiera ejecutaba un cluster Proxmox para VDI y algunas apps legacy. Sin suscripción, pero trataban las actualizaciones como cambios de producción: actualizaciones por fases nodo a nodo, repos consistentes y una regla de que ninguna línea nueva de repo entra en producción sin ticket.

Un día, un ciclo de actualización de rutina coincidió con que un proveedor publicó un paquete roto en un repo de terceros que usaban para un agente de monitorización. Ese repo no debía influir en Proxmox, pero podría haberlo hecho si las prioridades de APT lo permitían.

Estaban protegidos por dos decisiones aburridas. Primero, ese repo tercero tenía pinning bajo, así que no podía sobreescribir paquetes del sistema. Segundo, siempre ejecutaban una simulación de dist-upgrade en la revisión del cambio, y la simulación mostró al resolvedor queriendo eliminar un meta-paquete de Proxmox. Eso es una alarma de humo, no una sugerencia.

Arreglaron la línea del repo y siguieron. Sin incidente, sin heroísmos, sin llamada de fin de semana. Solo otro recordatorio de que la excelencia operativa a menudo se ve como “no pasó nada”.

Errores comunes: síntomas → causa raíz → solución

1) Síntoma: `apt update` muestra `401 Unauthorized` para enterprise

Causa raíz: Repo enterprise habilitado sin token de suscripción.

Solución: Comenta /etc/apt/sources.list.d/pve-enterprise.list o elimina el archivo. Habilita solo no-subscription para nodos sin suscripción.

2) Síntoma: “Release file changed” o “repository does not have a Release file”

Causa raíz: Nombre de suite incorrecto (bullseye vs bookworm), o una línea obsoleta dejada después de intentar una actualización mayor.

Solución: Verifica la versión mayor de PVE y la versión de Debian, y luego asegúrate de que todas las líneas coincidan. Limpia fuentes obsoletas en sources.list.d.

3) Síntoma: dist-upgrade quiere eliminar `proxmox-ve`

Causa raíz: Repos mixtos o deriva de dependencias (a menudo por testing/sid de Debian, o repos de terceros que sobreescriben dependencias).

Solución: Elimina los repos ofensores; quita holds; vuelve a ejecutar apt-cache policy proxmox-ve y asegúrate de que los candidatos provengan del repo Proxmox correcto.

4) Síntoma: la UI de Proxmox funciona, pero los arranques de VM fallan con errores raros de qemu

Causa raíz: qemu-server y pve-qemu-kvm desincronizados por actualizaciones parciales u orígenes mixtos.

Solución: Comprueba apt-cache policy para paquetes qemu. Alinea repos; ejecuta un dist-upgrade completo; reinicia si el kernel/qemu lo requieren.

5) Síntoma: el clúster Ceph empieza a quejarse tras “limpiar repos”

Causa raíz: Paquetes Ceph ahora provienen del repo equivocado (Debian main u otra serie Ceph) o se eliminó el repo mientras los paquetes permanecen.

Solución: Vuelve a añadir la serie Ceph correcta proporcionada por Proxmox para tu versión PVE; verifica con apt-cache policy ceph-common; actualiza Ceph solo con un procedimiento de rolling planificado.

6) Síntoma: “You have held broken packages” durante la actualización

Causa raíz: Paquetes retenidos, versiones fijadas o estado de actualización parcial.

Solución: Inspecciona holds con apt-mark showhold. Quita el hold si fue accidental. Usa la simulación para ver qué quiere cambiar. Arregla repos antes de forzar instalaciones.

7) Síntoma: El nodo se actualiza pero las herramientas de cluster se comportan mal (advertencias corosync, quórum extraño)

Causa raíz: Actualizar un nodo a una versión mayor desajustada o tirar de paquetes relacionados con el cluster desde fuentes distintas.

Solución: Mantén los nodos del cluster en la misma serie mayor durante operaciones normales. Si realizas una actualización mayor, sigue una ruta de rolling upgrade planificada y mantiene repos consistentes por fase.

Broma #2: Mezclar repos Bullseye y Bookworm es como fusionar dos organigramas: de pronto todos reportan a “Depends” y nadie aprueba el cambio.

Listas de verificación / plan paso a paso

Checklist A: Convertir un nodo independiente a no-subscription de forma segura (PVE ya instalado)

Haz snapshot de tu estado actual (legible por humanos): vuelca fuentes y versiones.
- Ejecuta pveversion -v y guarda la salida.
- Ejecuta grep sobre las fuentes APT y guarda la salida.
Desactiva el repo enterprise comentándolo, no borrándolo (a menos que cumplimiento requiera borrarlo).
Habilita el repo no-subscription para la suite correcta (bullseye para PVE7, bookworm para PVE8).
Ejecuta apt update y asegúrate de que no haya errores de auth o release-file.
Inspecciona orígenes candidatos para pve-manager, proxmox-ve, pve-kernel, qemu-server.
Simula dist-upgrade. Si se proponen eliminaciones, detente y arregla repos.
Realiza la actualización en una ventana de mantenimiento si hay cambios de kernel/qemu.
Reinicia si se instaló un kernel nuevo. Verifica uname -r después.
Chequeo posterior: verifica servicios Proxmox y operaciones de arranque de VMs.

Checklist B: Cambio de repos con conciencia de cluster (porque un nodo nunca es “solo un nodo”)

Confirma quórum (pvecm status).
Elige un orden: actualiza nodos no críticos primero; mantén al menos N-1 capacidad para HA cuando sea posible.
Asegura fuentes APT idénticas entre nodos para la misma release PVE. Las diferencias son incidentes futuros.
Un nodo a la vez: cambio de repo, apt update, simular, actualizar, reiniciar, validar.
Valida funciones del cluster: migraciones, gestor HA, conectividad de almacenamiento, estabilidad de corosync.

Checklist C: Si Ceph está involucrado, trata los repos como parte de la plataforma de almacenamiento

Comprueba la salud de Ceph (ceph -s) antes de tocar paquetes.
Verifica el origen de paquetes Ceph (apt-cache policy ceph-common).
Alinea la serie del repo Ceph en todos los nodos que ejecuten demonios Ceph.
No mezcles “actualizar Proxmox” y “actualizar Ceph” en un cambio no acotado. Sepáralos salvo que tengas un runbook combinado probado.

Preguntas frecuentes

1) ¿El repositorio no-subscription es “inseguro”?

No. Tiene menos retraso que enterprise, lo que aumenta la velocidad de cambios y por tanto el riesgo si no gestionas las actualizaciones. La seguridad viene de tu proceso: staging, simulación, suites consistentes y reinicios cuando sean necesarios.

2) ¿Puedo habilitar enterprise y no-subscription y dejar que APT elija?

No lo hagas. APT elegirá basado en números de versión y prioridades. Esa “elección” no es una política; es un accidente esperando ocurrir. Elige un canal.

3) ¿Desactivar el repo enterprise quitará la pancarta de suscripción?

Cambia las condiciones que disparan algunas advertencias, pero la pancarta es fundamentalmente sobre el estado de suscripción. Tu objetivo debe ser una ruta de actualización limpia, no una UI silenciosa.

4) ¿Por qué Proxmox se preocupa tanto por la alineación de suites Debian?

Porque los paquetes de Proxmox se construyen contra las librerías y toolchain de una release Debian específica. Mezclar suites significa mezclar libc, OpenSSL, componentes systemd y stacks de Python. A veces puedes salirte con la tuya—hasta que no puedas.

5) Actualicé Debian a Bookworm. ¿Puedo mantener repos PVE 7 temporalmente?

Eso es un estado de actualización parcial. Puede arrancar, pero no es una política estable. Alinea los repos de Proxmox con la versión mayor de PVE que pretendes ejecutar y sigue una ruta de actualización mayor de PVE adecuada en vez de improvisar.

6) ¿Necesito el repo Ceph si no uso Ceph?

No. Si no usas paquetes Ceph, no habilites repos Ceph “por si acaso”. Cada repo habilitado es otra pieza en movimiento en la resolución de dependencias.

7) ¿Cuál es la forma más segura de detectar un sistema con suites mixtas?

Usa apt-cache policy en paquetes núcleo (libc6, systemd, pve-manager) y revisa los nombres de release en la salida. También vuelca todas las líneas deb desde sources.list*. Las suites mixtas aparecen rápido.

8) ¿Debo usar `apt full-upgrade` o `apt dist-upgrade` en Proxmox?

Su intención es efectivamente la misma (permitir cambios de dependencias). La clave es simular primero e interpretar las eliminaciones propuestas como una señal de advertencia. Usa el que tu equipo estandarice, pero sé consistente.

9) ¿Puedo “arreglar” una actualización rota forzando paquetes con `dpkg --force`?

Puedes, y también puedes arreglar una tubería reventada con chicle. Si las dependencias están rotas porque los repos están mal, forzar paquetes normalmente hace que la recuperación posterior sea más difícil. Arregla fuentes y políticas primero.

10) ¿Cómo mantengo consistentes múltiples nodos Proxmox en el tiempo?

Estandariza los archivos de repos, audítalos periódicamente y trata los cambios de repos como cambios de configuración. En la práctica: gestiona /etc/apt/sources.list.d/ vía automatización y ejecuta comprobaciones periódicas que comparen salidas de grep y apt-cache policy entre nodos.

Conclusión: próximos pasos que puedes hacer hoy

Ejecutar Proxmox sin suscripción no es un pecado. Ejecutarlo con repositorios caóticos sí lo es. Si quieres actualizaciones limpias, elige un carril (enterprise o no-subscription), mantén las suites Debian alineadas con las versiones mayores de PVE y nunca “arregles” un error de autenticación añadiendo repos aleatorios.

Próximos pasos:

En un nodo, vuelca todas las fuentes APT y confirma que tienes exactamente un canal de Proxmox habilitado.
Ejecuta apt-cache policy pve-manager y confirma que el candidato proviene del repo y suite esperados.
Simula un dist-upgrade. Si quiere eliminar paquetes centrales de Proxmox, trátalo como un defecto de configuración, no como un paso de actualización.
Si estás en cluster, realiza cambios nodo a nodo con comprobaciones de quórum y validación posterior al reinicio.