Tutoriales de VPS
Qué hacer cuando apt update / apt install falla en un VPS (2026): diagnóstico de bloqueos de dpkg, claves GPG, repositorios caídos y conflictos de dependencias
Cuando apt update o apt install falla en un VPS Ubuntu/Debian, bloquea directamente todo lo que viene después: Docker, Nginx, PHP, monitorización y más. Este artículo presenta una lista de reparación segura por orden: DNS, repositorios, claves GPG, bloqueos de dpkg, paquetes a medio instalar, conflictos de dependencias y disco/inode.
Cuando compras un VPS Ubuntu nuevo, lo primero que sueles hacer tras entrar por SSH es:
sudo apt update
sudo apt install nginx docker.io curl
Pero antes de empezar a desplegar el sitio web, apt ya da un error:
Failed to fetch
Temporary failure resolving
NO_PUBKEY
The repository does not have a Release file
Could not get lock /var/lib/dpkg/lock-frontend
dpkg was interrupted
You have held broken packages
Este problema es muy común y muy molesto. En cuanto apt se rompe, todas las instalaciones posteriores quedan bloqueadas: no puedes instalar Nginx, no puedes instalar Docker, no puedes instalar PHP, y puede que ni siquiera puedas instalar herramientas de diagnóstico.
Este artículo no explica la teoría del gestor de paquetes; sigue un orden práctico: primero determina si el problema es de red/DNS, de repositorios, de claves GPG, de archivos de bloqueo, de paquetes a medio instalar o de conflictos de dependencias. No copies sin más el comando "borrar el archivo de bloqueo"; en muchos casos eso empeora el problema.
Ejecuta:
sudo apt update
No mires solo la última línea. Clasifica los errores en categorías:
| Palabra clave del error | Dirección habitual |
|---|---|
Temporary failure resolving | Fallo de resolución DNS |
Failed to fetch | Problemas de red, mirror, IPv6 o proxy |
404 Not Found | Ruta del repositorio no válida, versión del sistema EOL |
NO_PUBKEY | Falta la clave GPG de un repositorio de terceros |
Release file | El repositorio no soporta la distribución actual o está obsoleto |
Could not get lock | Ya hay otro apt/dpkg en ejecución |
dpkg was interrupted | La instalación anterior se interrumpió y hay que continuar la configuración |
held broken packages | Conflicto de dependencias o versión retenida (hold) |
Primero clasifica, luego actúa. Lo peor con los problemas de apt es "no mirar nada y directamente borrar bloqueos, cambiar repositorios y eliminar paquetes a la fuerza".
Si ves:
Temporary failure resolving 'archive.ubuntu.com'
Primero confirma si es DNS:
ping -c 3 1.1.1.1
ping -c 3 archive.ubuntu.com
Si la IP responde pero el nombre de dominio no, arregla primero el DNS en lugar de seguir trasteando con apt. Puedes probar temporalmente un DNS público:
dig @1.1.1.1 archive.ubuntu.com
También puedes revisar el resolver local:
resolvectl status
cat /etc/resolv.conf
Si acabas de leer el artículo anterior sobre resolución DNS, sabrás que este tipo de problema debe investigarse empezando por systemd-resolved, /etc/resolv.conf y la configuración DNS que entrega el proveedor cloud.
Si el DNS está bien pero las descargas de apt van lentas o fallan, prueba IPv4:
sudo apt -o Acquire::ForceIPv4=true update
Algunos VPS tienen una dirección IPv6 configurada pero sin ruta funcional, y apt se queda colgado en IPv6. La solución a largo plazo es tratar el enrutamiento IPv6 o la configuración del repositorio; no se recomienda taparlo solo con un parámetro temporal.
Si ves:
404 Not Found
The repository does not have a Release file
Primero revisa la versión del sistema:
lsb_release -a
cat /etc/os-release
Luego mira los archivos de repositorios:
cat /etc/apt/sources.list
ls /etc/apt/sources.list.d/
Cuando una versión de Ubuntu llega a EOL, los repositorios por defecto pueden dejar de ofrecer las rutas correspondientes. Por ejemplo, las versiones antiguas de Ubuntu necesitan cambiar a old-releases, o mejor aún, actualizar a una versión soportada.
No copies a ciegas jammy, noble y focal de internet y los mezcles. Ubuntu 22.04 es jammy y 24.04 es noble. Si la versión del sistema y el nombre en clave del repositorio no coinciden, aparecerá un montón de conflictos de dependencias.
Puedes comprobar rápidamente qué nombres en clave se usan en tus repositorios:
grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/*.list
Si en la misma máquina se mezclan varios nombres en clave de distribución, detente. Mezclar repositorios es una de las principales causas de desastres con apt.
Error habitual:
NO_PUBKEY ABCD1234EFGH5678
The following signatures couldn't be verified
Normalmente esto significa que la clave de firma de un repositorio de terceros no está bien instalada, ha caducado, o un tutorial antiguo sigue usando el obsoleto apt-key.
Primero localiza qué repositorio es:
grep -R "第三方域名或仓库名" /etc/apt/sources.list.d/ /etc/apt/sources.list
El método moderno suele ser colocar la clave en:
/etc/apt/keyrings/
Y luego en el archivo de repositorio usar:
signed-by=/etc/apt/keyrings/example.gpg
Por ejemplo, el repositorio oficial de Docker usa aproximadamente esta estructura. La documentación oficial de instalación de cada software dará los comandos correspondientes. No copies sin más un comando de keyserver de un foro, porque estás confiando en ese repositorio para instalar software en tu sistema.
Después de arreglarlo, vuelve a ejecutar:
sudo apt update
Mucha gente se encuentra con:
Could not get lock /var/lib/dpkg/lock-frontend
y directamente hace:
sudo rm /var/lib/dpkg/lock-frontend
No recomendado.
Primero comprueba si hay una actualización automática del sistema en ejecución:
ps aux | grep -E "apt|dpkg|unattended"
systemctl status apt-daily.service apt-daily-upgrade.service --no-pager
Luego mira quién ocupa el bloqueo:
sudo lsof /var/lib/dpkg/lock-frontend
sudo lsof /var/lib/dpkg/lock
Si apt.systemd.daily o unattended-upgrades están en ejecución, normalmente es más seguro esperar a que terminen.
Solo si confirmas que el proceso está realmente colgado deberías plantearte terminar el proceso relacionado. Antes de terminarlo, confirma que no se está instalando ningún paquete importante:
sudo fuser -v /var/lib/dpkg/lock-frontend
No mates procesos a lo loco solo por ir más rápido. Tras interrumpir dpkg, todavía tendrás que reparar el estado a medio instalar.
Si ves:
dpkg was interrupted, you must manually run 'sudo dpkg --configure -a'
haz lo que indica:
sudo dpkg --configure -a
Este comando continúa configurando los paquetes cuya instalación se interrumpió la última vez.
Cuando termine, ejecuta:
sudo apt --fix-broken install
sudo apt update
La comunidad de Ubuntu y los flujos oficiales de diagnóstico también usan habitualmente comandos como dpkg --configure -a y apt --fix-broken install para reparar el estado interrumpido. El orden importa: primero deja que dpkg termine la configuración incompleta y luego trata las dependencias.
Si ves:
You have held broken packages
primero mira si hay paquetes retenidos (hold):
apt-mark showhold
Si realmente hay paquetes retenidos, averigua por qué. No los liberes a ciegas; puede que se retuvieran antes para fijar la versión de base de datos, PHP o Nginx.
Consulta la política del paquete:
apt-cache policy 包名
Simula la instalación sin ejecutarla realmente:
sudo apt install -s 包名
-s es una simulación, útil para ver primero qué planea instalar y eliminar apt.
Si faltan dependencias:
sudo apt --fix-broken install
Si los repositorios mezclados hacen que las versiones choquen entre sí, prioriza limpiar los repositorios incorrectos en lugar de forzar la instalación.
Puedes auditar con dpkg:
sudo dpkg --audit
También puedes ver estados anómalos:
dpkg -l | grep -E "^(..r|..U|..F|..H|iF|iU|iH)"
Estados habituales:
iU: paquete desempaquetado pero no configuradoiF: fallo de configuraciónrc: paquete eliminado pero quedan archivos de configuración
Para iU y iF, normalmente primero:
sudo dpkg --configure -a
sudo apt --fix-broken install
Si un paquete sigue fallando al configurarse, revisa los errores de su postinst, los logs de arranque del servicio y el espacio en disco, en lugar de eliminarlo a la fuerza directamente.
apt/dpkg necesita escribir caché, desempaquetar y escribir archivos de configuración. Si el disco o los inodes están llenos, también fallará.
Primero mira:
df -h
df -i
Luego limpia la caché de apt:
sudo apt clean
Si /boot está lleno, la causa habitual es que hay demasiados kernels antiguos. Primero mira el kernel en ejecución:
uname -r
Luego mira los kernels instalados:
dpkg -l 'linux-image*' | grep '^ii'
No elimines el kernel que está en ejecución. Para limpiar kernels antiguos se recomienda usar el mecanismo autoremove de apt:
sudo apt autoremove
Antes de ejecutar, mira bien qué va a eliminar.
apt update solo refresca el índice de paquetes. En la instalación real todavía pueden aparecer dependencias, conflictos, disco o fallos de arranque de servicios.
Se recomienda simular primero:
sudo apt install -s nginx
Tras confirmar que no eliminará paquetes extraños, ejecuta:
sudo apt install nginx
Si falla la instalación de algún servicio, como MySQL, Nginx o Docker, sigue revisando los logs del servicio correspondiente:
systemctl status nginx --no-pager
journalctl -u nginx --since "30 minutes ago" --no-pager
Algunos fallos de instalación de paquetes no se deben a que apt esté roto, sino a que el servicio no arranca tras la instalación y el script postinst de dpkg devuelve un error.
Cuando me encuentro con errores de apt/dpkg, normalmente sigo este orden:
sudo apt update
Primero mira el tipo de error. Si es DNS, arregla primero el DNS. Si es un bloqueo:
ps aux | grep -E "apt|dpkg|unattended"
sudo lsof /var/lib/dpkg/lock-frontend
Si es una interrupción:
sudo dpkg --configure -a
Luego arregla las dependencias:
sudo apt --fix-broken install
Limpia la caché y actualiza:
sudo apt clean
sudo apt update
Comprueba estados dañados:
sudo dpkg --audit
apt-mark showhold
Por último instala el software objetivo:
sudo apt install -s 包名
sudo apt install 包名
Este flujo es mucho más estable que "borrar el bloqueo + instalar a la fuerza".
Cambiar de repositorio no es una panacea, pero hay varias situaciones en las que puedes planteártelo:
- El mirror actual lleva mucho tiempo dando 404 o agotando el tiempo de espera
- La región donde está el VPS tiene acceso muy lento a los repositorios oficiales
- El mirror interno del proveedor cloud es más estable
- El repositorio actual no soporta tu versión del sistema
Haz una copia de seguridad antes de cambiar de repositorio:
sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak
Luego confirma el nombre en clave del sistema:
. /etc/os-release
echo "$VERSION_CODENAME"
El nombre en clave del repositorio debe coincidir con el del sistema. No uses repositorios de 24.04 en Ubuntu 22.04, ni mezcles repositorios de Ubuntu en Debian 12.
Después de cambiar:
sudo apt update
Si aparecen errores de GPG, Release file o conflictos de dependencias, significa que los repositorios todavía no están bien emparejados.
Hay situaciones en las que seguir forzando la reparación tiene un riesgo alto:
- Hay una base de datos de producción en ejecución y apt quiere eliminar paquetes relacionados con la base de datos
- Los repositorios del sistema mezclan varios nombres en clave de distribución
/booty/ya están llenos- El estado de dpkg es anómalo en muchos puntos
- No sabes por qué está retenido un paquete con hold
- La imagen del proveedor cloud es demasiado antigua y el sistema ya está EOL
En ese momento, haz primero una instantánea o copia de seguridad y luego continúa. El gestor de paquetes está en la base del sistema; una eliminación forzada puede tumbar a la vez SSH, la red y la base de datos.
- Has leído el error completo de apt, no solo la última línea
- Has descartado primero problemas de DNS/red con
ping,dig,resolvectl - El nombre en clave del repositorio coincide con la versión del sistema
- Los repositorios de terceros usan la clave GPG correcta y
signed-by - Para los bloqueos de dpkg, revisa primero los procesos; no borres directamente el archivo de bloqueo
- Para
dpkg was interrupted, ejecuta primerodpkg --configure -a - Para problemas de dependencias, ejecuta luego
apt --fix-broken install - Usa
dpkg --auditpara revisar paquetes a medio instalar - Usa
apt-mark showholdpara revisar paquetes retenidos - Revisa
df -hydf -i - Simula con
apt install -santes de instalar - Haz una instantánea/copia de seguridad antes de cambiar mucho los repositorios o eliminar paquetes a la fuerza
Los fallos de apt/dpkg parecen un montón de errores en inglés, pero la mayoría se pueden clasificar: resolución de red, configuración de repositorios, firmas, bloqueos, interrupciones, dependencias, disco. Clasifica primero y luego repara en orden. Mientras no empieces borrando bloqueos, cambiando repositorios y eliminando paquetes a la fuerza sin criterio, la mayoría de los apt de VPS se pueden rescatar.