Solucionar fallos de apt update en Proxmox: DNS, repos y claves GPG (Paso a paso)

enero 26, 2026 • febrero 3, 2026 • Lectura: 26 min • Views: 6

¿Te fue útil?

Cuando apt update falla en un nodo Proxmox, rara vez es “solo apt”. Es tu DNS. O tu elección de repositorio. O un proxy que reescribe TLS silenciosamente. O una clave que expiró a las 02:00 un domingo, como si alguien que odia dormir la hubiese programado.

Esta guía está escrita para quien opera clústeres en producción y no tiene tiempo para admirar mensajes de error. Diagnosticarás rápido, harás cambios limpios y dejarás el nodo más predecible de lo que lo encontraste.

Guía rápida de diagnóstico

Si quieres un conjunto único de comprobaciones que encuentre el cuello de botella rápido, haz esto en orden. Para tan pronto como encuentres la primera capa rota. Apilar arreglos sin entender es como terminas con “funciona en este nodo pero no en aquel” durante el próximo año.

1) Alcance de red (¿hay camino en absoluto?)

Verifica la dirección IP, la ruta por defecto y el estado del enlace.
Haz ping a tu gateway y a una IP pública conocida.
Si no puedes alcanzar IPs, no toques apt, repos o claves todavía.

2) Resolución DNS (¿el nodo sabe los nombres?)

Resuelve los nombres de los repositorios con getent y resolvectl.
Busca DNS dividido, resolutores intermedios o un resolutor apuntando a 127.0.0.1 sin nada escuchando.

3) Corrección de los repositorios (¿estás pidiendo al servidor correcto el distro correcto?)

Verifica que el nombre de la release de Debian coincida con tu versión de Proxmox.
Confirma que no estés usando el repositorio enterprise por accidente sin suscripción.
Asegúrate de no haber copiado una entrada de repo de Ubuntu dentro de Debian. Sí, la gente lo hace.

4) TLS/certificados/proxy (¿se te permite descargar?)

Busca proxy MITM corporativo, portal cautivo o errores TLS.
Confirma que la hora del sistema sea coherente (una hora incorrecta hace que TLS parezca “roto”).

5) Claves de firma GPG (¿apt puede verificar lo que descargó?)

Busca NO_PUBKEY o “signed by unknown key”.
Usa keyrings por repositorio, no la vieja práctica de “esparcir claves en apt-key”.

Idea parafraseada de Werner Vogels (CTO de Amazon): “Si lo construyes, lo operas.” Eso significa que también lo depuras en momentos inconvenientes.

Hechos y contexto (para los curiosos y los curtidos)

La verificación de firmas APT se volvió menos opcional con el tiempo. En las épocas tempranas de Debian la gente usaba apt-key; la guía moderna impulsa keyrings por repositorio para contener el alcance de confianza.
Proxmox está basado en Debian, no es “algo parecido a Debian”. Los errores al mezclar repositorios ocurren porque muchos lo tratan como un appliance genérico y luego se extrañan por la resolución de dependencias.
Proxmox separa repositorios según modelo de soporte. El repo enterprise está restringido; el no-subscription está abierto pero no ofrece la misma promesa de estabilidad.
Las fallas de DNS son el problema de apt más común en centros de datos. Porque el DNS es una de las pocas cosas que todos asumen que “está bien”.
La hora del sistema es una dependencia oculta de la gestión de paquetes. TLS, ventanas de validez de claves y algunos proxies dependen de relojes coherentes.
IPv6 puede ser héroe y villano a la vez. Si un nodo prefiere IPv6 pero tu red solo lo soporta parcialmente, tendrás bloqueos lentos y fallos intermitentes.
HTTP 401/403 desde repos Proxmox suele ser política, no una caída transitoria. A menudo significa “estás golpeando el repo enterprise sin credenciales”.
Los nombres de release y suite importan. Un solo codename equivocado (como bullseye vs bookworm) puede aparecer como “Release file changed”, “no tiene Release file” o conflictos de dependencias.

Qué significa realmente “apt update failed” en Proxmox

apt update es una tubería:

Resolver nombres (DNS, /etc/hosts, systemd-resolved, resolutores en caché locales).
Conectarse a servidores (enrutamiento, firewall, reglas de proxy).
Negociar TLS (cadena de certificados, hora del sistema, interceptación de proxy).
Descargar metadatos (archivos Release/InRelease).
Verificar firmas (claves GPG y configuración de confianza).
Parsear metadatos del repo y construir el índice de paquetes.

Tu mensaje de error te dice en qué etapa falló, pero solo si sabes leerlo. “Temporary failure resolving” significa DNS; “The following signatures couldn’t be verified” significa claves; “401 Unauthorized” significa que estás llamando a la puerta enterprise sin el pase.

Broma #1: El DNS es como el oxígeno—nadie se preocupa hasta que falta, y entonces todos de repente se vuelven especialistas en respiración.

Tareas prácticas: comandos, salidas y decisiones (la chicha)

A continuación hay tareas prácticas que puedes ejecutar en el nodo Proxmox. Cada tarea incluye un comando, salida realista, qué significa y qué decisión tomar a continuación. Hazlas en orden salvo que ya sepas qué capa está fallando.

Task 1: Confirmar alineación de versiones Proxmox y Debian

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/2a1b3c0c)
pve-kernel-6.8: 6.8.12-2
pve-kernel-helper: 8.1.0
pve-kernel-libc-dev: 6.8.12-2
pve-qemu-kvm: 8.1.5
pve-container: 5.0.1
ceph-fuse: 16.2.15-pve1
corosync: 3.1.8-pve1
cr0x@server:~$ . /etc/os-release && echo "$PRETTY_NAME"
Debian GNU/Linux 12 (bookworm)

Qué significa: PVE 8 sigue a Debian 12 (bookworm). Esa es tu suposición base para las suites de los repositorios.

Decisión: Si tu release de OS es Debian 11 pero estás usando repos PVE 8 (o viceversa), detente y corrige el desajuste antes de tocar claves.

Task 2: Captura el fallo exacto de apt sin “arreglar” nada

cr0x@server:~$ apt-get update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Err:2 https://enterprise.proxmox.com/debian/pve bookworm InRelease
  401  Unauthorized [IP: 51.91.38.34 443]
Reading package lists... Done
E: Failed to fetch https://enterprise.proxmox.com/debian/pve/dists/bookworm/InRelease  401  Unauthorized [IP: 51.91.38.34 443]
E: The repository 'https://enterprise.proxmox.com/debian/pve bookworm InRelease' is not signed.

Qué significa: La red y el DNS están bien. Alcanzaste el repo enterprise, pero no estás autorizado. La línea “not signed” es un efecto secundario de no poder descargar el archivo Release firmado, no necesariamente un problema de claves.

Decisión: Arregla la selección del repositorio (enterprise vs no-subscription) antes de perseguir claves GPG.

Task 3: Comprobar interfaz básica y enrutamiento

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
vmbr0            UP             10.20.30.41/24 fe80::a00:27ff:fe4e:1122/64
cr0x@server:~$ ip route
default via 10.20.30.1 dev vmbr0
10.20.30.0/24 dev vmbr0 proto kernel scope link src 10.20.30.41

Qué significa: El enlace está arriba, la ruta por defecto existe y no estás en una situación extraña de “sin gateway”.

Decisión: Si la ruta por defecto falta o apunta a la interfaz equivocada (común tras renombrar un bridge), arregla la red primero. Apt no puede vencer a la física.

Task 4: Demuestra que puedes llegar a Internet por IP (independiente de DNS)

cr0x@server:~$ ping -c 2 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=1.78 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=1.72 ms

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 1.721/1.750/1.780/0.029 ms

Qué significa: El enrutamiento hacia el exterior funciona.

Decisión: Si esto falla, mira reglas de firewall, enrutamiento upstream o etiquetas VLAN. No edites fuentes de apt hasta arreglar la conectividad básica.

Task 5: Probar resolución DNS de la forma que usa apt

cr0x@server:~$ getent ahosts deb.debian.org | head
2a04:4e42:83::644 deb.debian.org
2a04:4e42:83::644 STREAM deb.debian.org
2a04:4e42:83::644 DGRAM  deb.debian.org
2a04:4e42:83::644 RAW    deb.debian.org
146.75.106.132 deb.debian.org
146.75.106.132 STREAM deb.debian.org

Qué significa: La resolución de nombres funciona. Estás obteniendo respuestas IPv6 e IPv4.

Decisión: Si getent falla pero dig tiene éxito, tienes un problema con NSS/systemd-resolved. Arregla la pila de resolutor, no la lista de repos.

Task 6: Inspeccionar la configuración del resolutor (systemd-resolved vs /etc/resolv.conf)

cr0x@server:~$ readlink -f /etc/resolv.conf
/run/systemd/resolve/stub-resolv.conf
cr0x@server:~$ resolvectl status | sed -n '1,35p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.20.30.10
       DNS Servers: 10.20.30.10 10.20.30.11
Fallback DNS Servers: 1.1.1.1 8.8.8.8

Qué significa: Estás usando systemd-resolved, apuntando a DNS internos, con fallback configurado.

Decisión: Si tu “Current DNS Server” está vacío, o apunta a algo inalcanzable, arregla la configuración de red (a menudo en /etc/network/interfaces para Proxmox) o los ajustes DHCP/estáticos de DNS.

Task 7: Identificar bloqueos y fallos relacionados con IPv6

cr0x@server:~$ apt-get -o Acquire::ForceIPv4=true update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://deb.debian.org/debian-security bookworm-security InRelease
Err:3 https://download.proxmox.com/debian/pve bookworm InRelease
  Temporary failure resolving 'download.proxmox.com'
Reading package lists... Done
W: Failed to fetch https://download.proxmox.com/debian/pve/dists/bookworm/InRelease  Temporary failure resolving 'download.proxmox.com'
W: Some index files failed to download. They have been ignored, or old ones used instead.

Qué significa: Forzar IPv4 cambió el comportamiento. Si forzar IPv4 lo hace funcionar (o fallar más rápido), tu ruta IPv6 o el resolutor puede ser inestable.

Decisión: Si IPv6 rompe apt, arregla IPv6 correctamente (preferible) o temporalmente fuerza IPv4 para apt mientras coordinas una solución en la red.

Task 8: Detectar ajustes de proxy que cambian el comportamiento de apt

cr0x@server:~$ grep -R "Acquire::http::Proxy\|Acquire::https::Proxy" -n /etc/apt/apt.conf /etc/apt/apt.conf.d 2>/dev/null
/etc/apt/apt.conf.d/99proxy:1:Acquire::http::Proxy "http://proxy.corp.local:3128";
/etc/apt/apt.conf.d/99proxy:2:Acquire::https::Proxy "http://proxy.corp.local:3128";

Qué significa: Apt usa explícitamente un proxy para HTTP y HTTPS. Si este proxy intercepta TLS o requiere autenticación, tus errores parecerán fallos de TLS o de repositorio.

Decisión: Confirma la alcanzabilidad del proxy y si soporta CONNECT para HTTPS. Si es un host Proxmox, considera aplicar el uso de proxy con cautela: los proxies que reescriben contenido siguen creando problemas.

Task 9: Validar la hora del sistema (TLS y validez de claves dependen de ello)

cr0x@server:~$ timedatectl
               Local time: Thu 2025-12-26 10:14:11 UTC
           Universal time: Thu 2025-12-26 10:14:11 UTC
                 RTC time: Thu 2025-12-26 10:14:10
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Qué significa: El reloj está sincronizado. Bien—TLS no fallará porque el nodo crea que es 1970 o 2038.

Decisión: Si la sincronización es no, arregla NTP primero. Un reloj equivocado genera falsos positivos como “certificate is not yet valid” y “key expired”.

Task 10: Inspeccionar fuentes apt para Proxmox y Debian

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-enterprise.list:1:deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise

Qué significa: El nodo está configurado para usar el repo enterprise. Si no tienes suscripción, recibirás errores 401. Si la tienes pero aún ves 401, revisa la instalación de la clave de suscripción y la autenticación del proxy saliente.

Decisión: Decide qué repo de Proxmox quieres. Para labs y muchas empresas pequeñas: no-subscription. Para entornos regulados: enterprise, con soporte real.

Task 11: Cambiar de repositorio enterprise a no-subscription (cuando sea apropiado)

cr0x@server:~$ sed -i 's/^deb /# deb /' /etc/apt/sources.list.d/pve-enterprise.list
cr0x@server:~$ cat >/etc/apt/sources.list.d/pve-no-subscription.list <<'EOF'
deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription
EOF
cr0x@server:~$ apt-get update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://security.debian.org/debian-security bookworm-security InRelease
Hit:3 http://deb.debian.org/debian bookworm-updates InRelease
Get:4 http://download.proxmox.com/debian/pve bookworm InRelease [2,768 B]
Get:5 http://download.proxmox.com/debian/pve bookworm/pve-no-subscription amd64 Packages [312 kB]
Fetched 315 kB in 1s (451 kB/s)
Reading package lists... Done

Qué significa: Ahora usas el repo correcto para un entorno sin suscripción enterprise, y apt puede recuperar metadatos.

Decisión: Si esto funciona, has solucionado el problema de autorización del repo. Pasa a higiene de claves y prevención de regresiones.

Task 12: Diagnosticar “NO_PUBKEY” y errores de firma limpiamente

cr0x@server:~$ apt-get update
Get:1 http://download.proxmox.com/debian/pve bookworm InRelease [2,768 B]
Err:1 http://download.proxmox.com/debian/pve bookworm InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 7BF2812E8A6E88E0
Reading package lists... Done
W: GPG error: http://download.proxmox.com/debian/pve bookworm InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 7BF2812E8A6E88E0
E: The repository 'http://download.proxmox.com/debian/pve bookworm InRelease' is not signed.

Qué significa: El repo es accesible, pero apt se niega a confiar porque la clave de firma no está disponible en los keyrings configurados.

Decisión: Instala la clave del archivo de Proxmox en un keyring dedicado y refiérelo con signed-by. No uses apt-key add a menos que quieras confianza global y que el tú del futuro odie al tú presente.

Task 13: Instalar la clave del repo Proxmox de la forma moderna (keyring dedicado)

cr0x@server:~$ install -d -m 0755 /etc/apt/keyrings
cr0x@server:~$ wget -qO /etc/apt/keyrings/proxmox-archive-keyring.gpg /usr/share/keyrings/proxmox-archive-keyring.gpg && echo "ok"
ok
cr0x@server:~$ chmod 0644 /etc/apt/keyrings/proxmox-archive-keyring.gpg
cr0x@server:~$ cat >/etc/apt/sources.list.d/pve-no-subscription.list <<'EOF'
deb [signed-by=/etc/apt/keyrings/proxmox-archive-keyring.gpg] http://download.proxmox.com/debian/pve bookworm pve-no-subscription
EOF
cr0x@server:~$ apt-get update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://security.debian.org/debian-security bookworm-security InRelease
Hit:3 http://deb.debian.org/debian bookworm-updates InRelease
Hit:4 http://download.proxmox.com/debian/pve bookworm InRelease
Reading package lists... Done

Qué significa: Apt ahora confía en el repo Proxmox usando una clave explícita vinculada a ese repo.

Decisión: Mantén las claves con alcance limitado. Si la clave de un repo se compromete, quieres radio de daño limitado, no fuegos artificiales.

Task 14: Depurar “Release file changed” y desajuste de suite

cr0x@server:~$ apt-get update
Err:1 http://deb.debian.org/debian stable InRelease
  404  Not Found [IP: 151.101.130.132 80]
Reading package lists... Done
E: The repository 'http://deb.debian.org/debian stable InRelease' does not have a Release file.

Qué significa: Tus fuentes están mal. “stable” puede funcionar en algunos contextos, pero en nodos de infraestructura quieres el codename explícito para evitar sorpresas durante una transición de Debian stable.

Decisión: Sustituye stable por el codename correcto (p. ej., bookworm) en todas las líneas relevantes. La consistencia importa más que la creatividad.

Task 15: Detectar interceptación TLS o problemas de cadena de certificados

cr0x@server:~$ apt-get update
Err:1 https://download.proxmox.com/debian/pve bookworm InRelease
  Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown.  Could not handshake: Error in the certificate verification. [IP: 144.217.225.162 443]
Reading package lists... Done
W: Failed to fetch https://download.proxmox.com/debian/pve/dists/bookworm/InRelease  Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown.  Could not handshake: Error in the certificate verification.
W: Some index files failed to download. They have been ignored, or old ones used instead.

Qué significa: O tu paquete de CA está roto/obsoleto, la hora está mal, o un proxy corporativo intercepta TLS and presenta una CA personalizada no confiada por el nodo.

Decisión: No desactives la verificación de certificados. Arregla la confianza de CA correctamente (instala la CA raíz corporativa en el store de confianza del sistema si debes usar interceptación) o evita el proxy para los dominios de repos.

Task 16: Confirmar el paquete de certificados CA y actualizarlo

cr0x@server:~$ dpkg -l ca-certificates | awk 'NR==1 || $1 ~ /^ii/ {print}'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name            Version         Architecture Description
ii  ca-certificates 20230311        all          Common CA certificates
cr0x@server:~$ update-ca-certificates | tail -n 5
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.

Qué significa: El paquete de CA está presente y el almacén de certificados se actualizó. Si TLS sigue fallando, sospecha de interceptación o de un proxy roto.

Decisión: Si estás en una red corporativa con interceptación TLS, instala la CA corporativa (correctamente) o configura apt para ir directo.

Task 17: Revisar pinning y retenciones que hacen que las actualizaciones “parezcan rotas”

cr0x@server:~$ apt-mark showhold
pve-kernel-6.8.12-2-pve
cr0x@server:~$ apt-cache policy pve-kernel-6.8.12-2-pve | sed -n '1,25p'
pve-kernel-6.8.12-2-pve:
  Installed: 6.8.12-2
  Candidate: 6.8.12-2
  Version table:
 *** 6.8.12-2 500
        500 http://download.proxmox.com/debian/pve bookworm/pve-no-subscription amd64 Packages
        100 /var/lib/dpkg/status

Qué significa: Las retenciones no rompen apt update, pero pueden causar confusión de “¿por qué no actualiza?” tras arreglar update.

Decisión: Quita retenciones solo si sabes por qué existen. Retenciones de kernel pueden ser intencionales (drivers de almacenamiento, módulos fuera del árbol o ventanas de cambios conservadoras).

Task 18: Asegurar que apt puede escribir sus listas (espacio en disco y permisos)

cr0x@server:~$ df -h /var
Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/pve-root                94G   92G     0 100% /
cr0x@server:~$ apt-get update
E: Write error - write (28: No space left on device)
E: Failed to fetch http://deb.debian.org/debian/dists/bookworm/InRelease  Write error - write (28: No space left on device)
E: Some index files failed to download. They have been ignored, or old ones used instead.

Qué significa: Tu filesystem raíz está lleno. Apt no puede actualizar sus listas y, aun si pudiera, probablemente no puedas instalar nada.

Decisión: Libera espacio primero (logs, kernels antiguos, ISOs movidos fuera de root). Solo entonces reintenta apt.

Task 19: Ver qué cree apt que debe descargar (depuración de adquisición)

cr0x@server:~$ apt-get -o Debug::Acquire::https=true update 2>&1 | sed -n '1,30p'
Acquire::https::download.proxmox.com:443: Server supports multiplexing
Acquire::https::download.proxmox.com:443: Negotiating SSL
Acquire::https::download.proxmox.com:443: Verify-Peer: 1
Acquire::https::download.proxmox.com:443: Cipher: TLS_AES_256_GCM_SHA384
Get:1 https://download.proxmox.com/debian/pve bookworm InRelease [2,768 B]
Fetched 2,768 B in 0s (14.2 kB/s)
Reading package lists... Done

Qué significa: Útil cuando el proxy/TLS se comporta raro. Puedes ver negociación y decisiones de verificación.

Decisión: Si ves reconexiones repetidas, problemas SNI o verificación alterada, probablemente trates con un proxy interceptador o una cadena de CA rota.

Task 20: Validar que las entradas de repo de Proxmox no estén duplicadas o en conflicto

cr0x@server:~$ awk 'NF && $1 != "#" {print FILENAME ":" NR ":" $0}' /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 [signed-by=/etc/apt/keyrings/proxmox-archive-keyring.gpg] http://download.proxmox.com/debian/pve bookworm pve-no-subscription

Qué significa: Un set claro de Debian, un set claro de Proxmox. Sin duplicados, sin enterprise viejo todavía activo.

Decisión: Si ves múltiples líneas de Proxmox para distintas suites o enterprise y no-subscription activados juntos, límpialo. Apt no va a “elegir la correcta”. Elegirá el caos.

Broma #2: Los errores de APT son como los correos corporativos—técnicamente informativos, emocionalmente poco útiles y siempre llegan cuando ya estás ocupado.

Listas de verificación / plan paso a paso

Esta es la secuencia práctica que uso en producción. Evita “arreglar lo incorrecto” y deja migas de pan para el siguiente operador.

Checklist A: Arreglar fallos de apt relacionados con DNS

Confirma que el enrutamiento funciona (Task 3–4). Si la conectividad IP falla, detente aquí.
Confirma la resolución de nombres vía NSS (Task 5). Si getent falla, no confíes en dig como prueba de que apt funcionará.
Inspecciona el estado de systemd-resolved (Task 6). Confirma que los servidores DNS actuales sean alcanzables.
Comprueba si el DNS solo está roto para dominios externos (común con DNS dividido). Prueba nombres internos y externos.
Decide una estrategia de resolutor:
- Preferido: arreglar los servidores DNS upstream y la configuración DHCP/estática.
- Aceptable a corto plazo: fijar resolutores explícitos en la configuración de red para que los nodos Proxmox no dependan del scope DHCP de estaciones.
Vuelve a ejecutar apt update y confirma que la clase de error cambió. Ningún cambio significa que arreglaste la capa equivocada.

Checklist B: Arreglar problemas de repositorio y suite

Identifica versión de Proxmox y codename de Debian (Task 1).
Imprime todas las líneas de repos (Task 10, Task 20). Busca:
- Codename equivocado (bullseye en Debian 12).
- Usar stable en vez del codename explícito (Task 14).
- Repo enterprise habilitado sin suscripción (Task 2).
- Protocolos mixtos y entradas duplicadas.
Toma una decisión de repositorio:
- Repo enterprise si tienes suscripción y quieres el ciclo de soporte curado.
- Repo no-subscription si no la tienes. Sé honesto y configura en consecuencia.
Desactiva el repo que no uses (coméntalo, no lo borres; quieres auditoría).
Ejecuta apt update otra vez y verifica que las descargas de repos sean Hit/Get, no Err.

Checklist C: Arreglar claves y verificación de firmas correctamente

Confirma que el fallo trata realmente de firmas (Task 12). Si obtienes HTTP 401/404, las claves no son el problema.
Crea /etc/apt/keyrings (Task 13). Esta es la convención moderna.
Usa un keyring por repo y signed-by (Task 13). Limita la confianza.
Vuelve a ejecutar apt update. Si sigue fallando, revisa la hora (Task 9) y la interceptación TLS (Task 15–16).

Checklist D: Arreglar proxy y roturas TLS sin desactivar seguridad

Encuentra la configuración de proxy (Task 8). Los ajustes de proxy para apt pueden vivir en varios archivos.
Confirma que tu proxy soporte HTTPS CONNECT. Si no, los repos HTTPS fallarán con errores de handshake.
Arregla la confianza de CA correctamente:
- Si tu org intercepta TLS, instala la CA raíz corporativa en el store del OS.
- Si tu org puede permitir acceso directo a dominios de repos, evita el proxy para esos dominios.
Valida con la salida de depuración de apt (Task 19). Hazlo aburrido.

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

Estos aparecen constantemente en entornos Proxmox porque la gente copia/pega configuraciones de repos entre nodos y porque la UI de Proxmox facilita hacer clic hasta meter la pata.

1) “Temporary failure resolving ‘download.proxmox.com’”

Síntoma: Apt falla con errores de resolución; ping por IP funciona.
Causa raíz: DNS mal configurado; systemd-resolved stub apunta a ninguna parte; firewall bloquea UDP/TCP 53; DNS dividido rompe resolución externa.
Solución: Valida con getent y resolvectl status; corrige servidores DNS en la configuración de red; asegúrate de que el resolutor sea alcanzable; vuelve a probar.

2) “401 Unauthorized” desde enterprise.proxmox.com

Síntoma: Fetch al repo enterprise falla con 401, a veces seguido por “not signed”.
Causa raíz: Repo enterprise activado sin suscripción; o proxy elimina autenticación; o clave de suscripción no instalada donde se espera.
Solución: Desactiva el repo enterprise si no tienes suscripción y habilita no-subscription; si sí la tienes, verifica el estado de la suscripción en Proxmox y revisa el comportamiento del proxy.

3) “NO_PUBKEY … The repository is not signed”

Síntoma: Apt alcanza el repo pero se niega a confiar en los metadatos.
Causa raíz: Falta la clave de firma del archivo, keyring equivocado o configuración de confianza obsoleta.
Solución: Usa keyrings por repositorio en /etc/apt/keyrings y signed-by; no dependas de métodos globales obsoletos.

4) “Certificate verification failed: issuer unknown”

Síntoma: Handshake TLS falla; apt reporta emisor desconocido o certificado no confiable.
Causa raíz: Interceptación TLS corporativa sin CA raíz instalada; bundle de CA roto; hora incorrecta; proxy presenta certificado custom.
Solución: Arregla sincronización horaria; actualiza bundle de CA; instala la CA corporativa si es necesario; evita desactivar verificación.

5) “does not have a Release file”

Síntoma: 404 o “Release file missing”, a menudo tras cambiar etiquetas de suite Debian.
Causa raíz: Suite/codename incorrecto, distribución errónea, typo en la línea del repo o uso de un repo que no es para tu release de Debian.
Solución: Confirma el codename de Debian; corrige la línea del repo; evita stable en nodos de infraestructura si buscas comportamiento predecible durante transiciones de Debian.

6) Apt update funciona, pero las actualizaciones rompen dependencias después

Síntoma: apt update tiene éxito; apt full-upgrade quiere eliminar paquetes Proxmox o retiene críticos.
Causa raíz: Repos mezclados de distintas suites; definiciones duplicadas; líneas accidentales de testing/unstable; mezcla enterprise/no-subscription obsoleta.
Solución: Limpia fuentes a una suite Debian y un canal Proxmox; elimina líneas accidentales; usa apt-cache policy para confirmar orígenes.

7) “Write error (28: No space left on device)”

Síntoma: Apt no puede escribir archivos de lista; update falla a mitad de flujo.
Causa raíz: Filesystem raíz lleno (logs, volcados, ISOs, kernels antiguos).
Solución: Libera espacio y luego vuelve a ejecutar update; considera mover almacenamiento pesado fuera de root e implementar retención de logs.

Tres micro-historias corporativas desde el terreno

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

Tenían un clúster Proxmox ordenado en un colo: tres nodos, un pequeño pool Ceph y una ventana de cambios que siempre empezaba tarde por reuniones. Durante un parche rutinario, un nodo se negó a actualizar. El error parecía de clave, así que el operador fue a buscar soluciones GPG.

La suposición equivocada: “Si apt dice ‘not signed’, siempre es un problema de clave.” No lo era. El nodo tenía una línea de repo enterprise habilitada porque alguien copió el mismo archivo .list desde un entorno con suscripción meses antes. Este entorno no estaba suscrito. Apt recibió un 401, y luego se quejó de no poder verificar un archivo que nunca obtuvo.

El equipo intentó tres importaciones de claves, añadió una excepción de proxy y consideró desactivar la verificación. Por suerte, el último paso fue bloqueado por un ingeniero de seguridad malhumorado que por una vez tenía razón. Cuando finalmente leyeron la primera línea fallida con atención—401 Unauthorized—desactivaron el repo enterprise y activaron no-subscription. Problema resuelto en minutos.

El coste real fue tiempo y confianza. El nodo quedó retrasado en actualizaciones de seguridad más tiempo del necesario. Además, una vez que “arreglas” cosas al azar, no puedes explicar fácilmente más tarde qué cambio importó. Tras el incidente, añadieron una comprobación previa simple: grep por líneas enterprise y fallar el trabajo de parcheo si se encuentran en clústeres no suscritos.

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

Otra compañía ejecutaba nodos Proxmox en una red con política de egress estricta. Para acelerar actualizaciones, alguien introdujo un proxy de caché HTTP(S) y forzó todo el tráfico Debian y Proxmox por él. En papel: descargas más rápidas, menos conexiones externas, auditoría más sencilla. Una idea que queda fantástica en una diapositiva.

Luego llegó la realidad. El proxy tenía interceptación TLS activada para “escaneo de seguridad”. El equipo Linux no instaló la CA raíz corporativa en los nodos Proxmox porque “son solo actualizaciones de paquetes, estará bien”. No lo estuvo. Apt empezó a fallar con errores de emisor de certificado—de forma intermitente—dependiendo de qué nodo proxy contestara.

“Optimizaban” más permitiendo fallback a HTTP para algunos repos. Eso hizo que los errores desaparecieran, hasta que alguien notó que metadata y paquetes viajaban sin TLS. Vino una revisión de incidente de seguridad y un rollback rápido y desagradable.

La solución fue aburrida: instalar la CA raíz corporativa correctamente, evitar la interceptación para dominios de repos donde la política lo permitía, y mantener todo en HTTPS. Aún usaban proxy para caché, pero dejaron de permitir que fingiera ser Internet. Las ganancias de rendimiento permanecieron, pero ahora las actualizaciones eran predecibles.

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

Otro equipo tenía una costumbre que parecía excesivamente cautelosa: cada nodo Proxmox tenía el mismo layout de repos, la misma ruta de keyring y el mismo script de preflight que corría antes de parchear. Nada sofisticado. Sin depuración heroica durante la ventana de cambios—porque la mayoría de problemas se detectaban antes.

Una noche, un nodo empezó a fallar actualizaciones con “Temporary failure resolving”. Pero su preflight no solo ejecutaba apt update; también corría comprobaciones getent para los hostnames de los repos, registraba el estado del resolutor y confirmaba la sincronización horaria. La salida se adjuntó al ticket automáticamente.

Cuando el de guardia abrió el ticket, no tuvo que adivinar. Vio que el nodo había cambiado servidores DNS tras un mantenimiento de red, apuntando a un resolutor que servía zonas internas pero bloqueaba recursión externa. Apt no estaba roto; la política DNS lo estaba.

Lo arreglaron restaurando los resolutores correctos en la configuración del nodo y actualizando el playbook de red para que futuros cambios no dejaran infraestructura en DNS “solo-interna”. La práctica aburrida no solo aceleró la resolución; hizo el incidente menos estresante. Menos estrés significa menos malas decisiones. Menos malas decisiones significa menos incidentes secundarios. Ese es el objetivo.

Preguntas frecuentes (FAQ)

1) ¿Debo usar el repo enterprise o el no-subscription?

Si tienes suscripción y te importa el soporte y un flujo de actualizaciones curado, usa enterprise. Si no la tienes, desactiva enterprise y usa no-subscription. Ejecutar enterprise sin derecho solo te hará perder tiempo con errores 401.

2) ¿Por qué apt dice “repository is not signed” después de un error HTTP?

Porque apt espera metadatos firmados (InRelease/Release.gpg). Si no puede obtenerlos—por 401/404/red—puede reportar problemas de firma como efecto secundario. Lee la primera línea “Err:”; normalmente esa es la falla real.

3) ¿Está bien poner `Acquire::https::Verify-Peer "false";`?

No. Así enseñas a tu infraestructura a aceptar paquetes manipulados. Arregla la confianza de CA o el comportamiento del proxy en su lugar. Si debes hacer algo temporal en una emergencia, documentalo, limita el alcance y elimínalo inmediatamente.

4) Arreglé DNS pero apt aún falla a veces. ¿Por qué es intermitente?

Causas comunes: varios servidores DNS con reglas de recursión inconsistentes, ruta IPv6 rota, balanceo de carga de proxy defectuoso o problemas de MTU que bloquean el handshake TLS. Intermitente significa “existen dos caminos y uno está malo”.

5) ¿Cuál es la forma más segura de gestionar claves apt en Proxmox?

Usa archivos keyring por repositorio bajo /etc/apt/keyrings y refiérelos con signed-by= en la línea del repo. Evita stores de confianza globales a menos que quieras que una clave comprometida bendiga todo.

6) ¿Puedo mezclar repos Debian de distintos releases en Proxmox?

Puedes, pero no deberías. Mezclar suites invita a conflictos de dependencias y actualizaciones impredecibles. Mantén un solo codename Debian y un solo canal Proxmox. Lo aburrido gana.

7) ¿Por qué forzar IPv4 a veces “arregla” apt update?

Si tu nodo prefiere IPv6 y el IPv6 de la red está mal enrutado, filtrado o da respuestas DNS rotas, las conexiones pueden colgar o fallar. Forzar IPv4 es una herramienta de diagnóstico; la solución real es hacer que IPv6 funcione o desactivarlo intencional y consistentemente.

8) apt update funciona, pero la GUI de Proxmox aún se queja de repositorios. ¿Por qué?

La GUI puede advertir sobre configuración enterprise, estado de suscripción o canales que no coinciden. Confirma que los archivos reales en /etc/apt/sources.list.d coincidan con tu intención y luego refresca la interfaz.

9) ¿Y si el nodo está aislado o sin Internet saliente?

Entonces apt update debe apuntar a un mirror interno que controles, con claves de firma correctas y disponibilidad predecible. Trata ese mirror como infraestructura de producción. Si es inestable, tus parches serán inestables.

Siguientes pasos (mantenerlo arreglado)

Una vez que apt update funcione, no te quedes en “verde”. Haz que siga verde.

Estandariza archivos de repos entre nodos. Un codename Debian, una decisión de repo Proxmox, sin duplicados.
Limita la confianza con keyrings signed-by. Es más limpio, seguro y fácil de auditar.
Haz DNS y sincronización horaria dependencias no negociables. Monitoriza la alcanzabilidad del resolutor y el estado NTP como monitorizas la latencia de almacenamiento.
Documenta el comportamiento del proxy. Si existe interceptación TLS, integra la instalación de la CA en el provisioning. No lo dejes como conocimiento tribal.
Añade un script de preflight. Ejecútalo antes de ventanas de parcheo: enrutamiento, DNS via getent, sincronización horaria, comprobaciones de repos y espacio disco.

Si haces lo anterior, la próxima vez que alguien diga “apt está caído”, ya sabrás cuál capa está fallando.