do-release-upgrade: no se encontró una nueva versión

Por qué do-release-upgrade indica que no se encontró una nueva versión

do-release-upgrade que termina en No new release found. casi nunca indica que la herramienta esté dañada. La ruta solicitada está cerrada en ese momento, y la herramienta lo informa de la forma más breve posible. Hay cinco causas posibles: el ajuste Prompt de /etc/update-manager/release-upgrades, el requisito de una versión intermedia en las actualizaciones LTS (soporte a largo plazo), los repositorios de terceros, los paquetes retenidos o configurados parcialmente y una versión cuyo soporte ya terminó.

Revise estas causas en ese orden. Cada una tiene un comando que confirma si se aplica a su servidor. Así no tendrá que adivinar cuál de las cinco está bloqueando la actualización.

Qué informa realmente la opción de solo comprobación

sudo do-release-upgrade -c
echo $?

-c solo comprueba. Lee los metadatos de versiones de Canonical mediante HTTPS (hypertext transfer protocol secure) y muestra el resultado. No descarga ninguna herramienta de actualización ni reescribe ningún archivo de fuentes. Hay dos resultados importantes:

Checking for a new Ubuntu release
No new release found.

Checking for a new Ubuntu release
New release '26.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

El código de salida transmite el mismo resultado para los scripts. Es 0 cuando hay una versión disponible y 1 cuando no hay ninguna. Esto invierte la convención habitual del shell, así que léalo con atención antes de crear una comprobación basada en él.

Si el banner de inicio de sesión todavía muestra el resultado anterior, está almacenado en caché. Esa línea procede de /etc/update-motd.d/91-release-upgrade, que muestra un resultado guardado en lugar de consultar la red. Actualícelo con sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd o confíe directamente en -c. El banner sólo repite el resultado de la última comprobación ejecutada.

La comprobación también necesita acceder a changelogs.ubuntu.com. En un servidor protegido por un firewall de salida estricto o por un proxy, la herramienta no puede realizar la consulta, por lo que no puede encontrar ninguna versión.

curl -sI https://changelogs.ubuntu.com/meta-release-lts | head -n 1

Una línea HTTP/2 200 indica que el servidor puede consultar los metadatos. Una línea curl: (28) Connection timed out indica que las reglas de salida son la causa real. Editar archivos de APT (advanced package tool) no cambiará el resultado.

Si el comando no existe, se encuentra en ubuntu-release-upgrader-core. Algunas imágenes mínimas de servidores cloud no incluyen ese paquete.

sudo apt install ubuntu-release-upgrader-core

Lea /etc/update-manager/release-upgrades antes de cambiar nada

cat /etc/update-manager/release-upgrades

[DEFAULT]
Prompt=lts

El archivo incluye su propia documentación en los comentarios. Hay tres valores válidos:

• never: nunca busca ni permite actualizar a una versión nueva.
• normal: ofrece la versión compatible que sigue inmediatamente a la que está en ejecución.
• lts: ofrece la primera versión LTS posterior a la que está en ejecución.

Prompt=never es el más fácil de diagnosticar de los tres, porque la herramienta indica tanto el archivo como la configuración en su salida:

Checking for a new Ubuntu release
In /etc/update-manager/release-upgrades Prompt is set to never so upgrading is not possible.

Los proveedores de alojamiento y las herramientas de gestión de configuración establecen never deliberadamente para evitar que una flota se desvíe entre versiones. Si lo encuentra ahí, alguien lo eligió. Cámbielo a lts en un servidor que deba seguir el ciclo de soporte a largo plazo y restáurelo después si su automatización espera el valor anterior.

Hay un detalle en esos comentarios que suele causar errores. Cuando se establece Prompt=lts y la versión en ejecución no es una versión LTS, el actualizador interpreta la configuración como normal. En una máquina con 25.10, ambos valores se comportan igual. En una máquina con 24.04 no lo hacen, y esa diferencia es el contenido de toda la sección siguiente.

Por qué una actualización de LTS a LTS espera a la primera versión de mantenimiento

Prompt determina qué archivo de metadatos lee el actualizador. Las direcciones se encuentran en /etc/update-manager/meta-release:

[METARELEASE]
URI = https://changelogs.ubuntu.com/meta-release
URI_LTS = https://changelogs.ubuntu.com/meta-release-lts
URI_UNSTABLE_POSTFIX = -development
URI_PROPOSED_POSTFIX = -proposed

Prompt=lts lee meta-release-lts. Prompt=normal lee meta-release. Ambos archivos describen cada versión en un bloque pequeño de claves, y el actualizador ofrece una versión sólo cuando su indicador Supported: está establecido en 1. Puede leerlos directamente desde el mismo servidor:

curl -s https://changelogs.ubuntu.com/meta-release-lts | grep -A 4 resolute
curl -s https://changelogs.ubuntu.com/meta-release | grep -A 4 resolute

Comprobado el 13 de agosto de 2026, los dos archivos no coinciden sobre Ubuntu 26.04. El archivo de LTS indica:

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 0

El archivo normal indica:

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 1

Ese Supported: 0 del archivo de LTS es el mecanismo de control. Un servidor 24.04 que usa el Prompt=lts predeterminado lee ese archivo, no encuentra ninguna versión LTS más reciente marcada como disponible y muestra No new release found.. No hay ningún problema en su equipo. Canonical todavía no ha abierto la ruta de actualización.

El indicador cambia a 1 cuando se publica la primera versión de mantenimiento. Ubuntu 26.04.1 está programado para el 27 de agosto de 2026, pero los calendarios de publicación pueden cambiar, así que debe comprobar los metadatos en lugar de basarse en una fecha. El retraso es deliberado: quienes actualizan pronto detectan los problemas, que se corrigen antes de que les siga la población mucho mayor de servidores LTS.

Hay dos opciones razonables. Esperar a la versión de mantenimiento, que es la decisión adecuada para cualquier servidor que prefiera no supervisar durante la actualización. O establecer Prompt=normal, que dirige la misma herramienta a meta-release, donde 26.04 ya figura como compatible. La segunda opción actualiza el sistema a la versión publicada 26.04, no a una compilación de desarrollo, por lo que es defendible en una máquina que pueda restaurar desde una instantánea. Cuando termine, vuelva a establecer el valor en lts. El procedimiento completo, paso a paso, se encuentra en la guía completa para actualizar un servidor de 24.04 a 26.04.

Repositorios de terceros y PPAs que bloquean la actualización

El actualizador reescribe las fuentes de APT para que apunten a la nueva versión. Sólo puede hacerlo con un repositorio que publique paquetes para la nueva versión, por lo que cualquier otra fuente se comenta. Los motivos se muestran en una línea por entrada y son específicos: was disabled (unknown mirror), was disabled (unknown dist) y was disabled (no Release file).

Un PPA (archivo personal de paquetes) creado para noble no tiene un directorio para resolute en el servidor. Por eso, el actualizador no puede obtener un archivo Release para la nueva serie y deshabilita la entrada. Normalmente, esto es una advertencia que puede aceptar. Se convierte en un bloqueo cuando un repositorio de terceros proporciona un paquete que también incluye la nueva versión, porque el cálculo de la actualización tiene entonces dos candidatos y no puede satisfacer ambas fuentes.

Decida esto antes de empezar, en lugar de dejar que la herramienta lo decida durante una ejecución desatendida prolongada.

ls /etc/apt/sources.list.d/
apt policy nginx
sudo add-apt-repository --remove ppa:example/ppa

apt policy sobre un nombre de paquete muestra de qué repositorio procede cada versión instalada. Así puede ver exactamente qué paquetes dependen de la fuente que está a punto de deshabilitar. Eliminar la fuente no degrada ningún paquete, por lo que un paquete instalado desde un PPA conserva su versión del PPA y puede ser más reciente que la disponible en la nueva versión. Cuando esto sea relevante, elimine también el paquete y vuelva a instalarlo desde el archivo después de la actualización. Si piensa volver a habilitar un repositorio, como el de Tailscale, debe actualizar su nombre de versión a la nueva versión antes de que el paquete vuelva a instalarse. De ahí proceden la mayoría de los errores de instalación de Tailscale en Ubuntu.

Existe un indicador para elegir lo contrario. La página del manual describe --allow-third-party como «Intentar la actualización con los mirrors y repositorios de terceros habilitados en lugar de comentarlos». Úselo sólo después de confirmar que el repositorio ya publica paquetes para la versión de destino. Si no lo hace, estará pidiendo a APT que resuelva un grafo de dependencias para una serie para la que ese repositorio nunca ha creado paquetes.

En Ubuntu 24.04 y versiones posteriores, la mayoría de las fuentes se encuentran en /etc/apt/sources.list.d/ubuntu.sources con el formato deb822. El mismo repositorio escrito en los formatos antiguo y nuevo constituye un error independiente, con su propio mensaje, que se explica en el error de entrada de fuente duplicada en formato deb822.

Paquetes retenidos y parcialmente configurados detienen la actualización

Una actualización de versión tiene que actualizar casi todos los paquetes del sistema. Si un paquete no se puede actualizar, el cálculo falla. El actualizador prefiere detenerse pronto antes que dejar el sistema a medias. Dos comandos permiten encontrar la causa.

apt-mark showhold
sudo dpkg --audit

apt-mark showhold muestra los paquetes retenidos, uno por línea. En un sistema sin problemas no muestra nada. Una retención es una instrucción manual para no cambiar nunca ese paquete. Alguien fijó un kernel o una versión de una base de datos y después lo olvidó. Libere los que ya no necesite con sudo apt-mark unhold seguido del nombre del paquete.

dpkg --audit muestra los paquetes que se desempaquetaron pero nunca se configuraron. Este estado se produce cuando una instalación se interrumpe, normalmente porque se perdió una sesión. El actualizador intenta repararlo y muestra dpkg interrupted, calling dpkg --configure -a, pero si ejecuta primero la reparación usted mismo podrá leer el error en lugar de verlo desplazarse por la pantalla. Si la herramienta no puede reparar un paquete, muestra el mensaje Package in inconsistent state. Ese paquete necesita atención antes de volver a intentarlo.

Deje la versión en ejecución completamente actualizada antes de actualizarla.

sudo apt update
sudo apt full-upgrade -o APT::Get::Always-Include-Phased-Updates=true
sudo apt --fix-broken install
sudo dpkg --configure -a
sudo reboot

La opción de actualizaciones escalonadas es más importante de lo que parece. Ubuntu distribuye algunas actualizaciones entre un porcentaje de máquinas cada vez. Por eso, un apt upgrade normal puede dejar paquetes pendientes correctamente, y el servidor queda menos actualizado de lo que cree. Esa opción instala todas las actualizaciones. Reinicie después si incluyen un kernel, para realizar la actualización desde el kernel que realmente está ejecutando. Un servidor que ya se mantiene actualizado mediante actualizaciones de seguridad desatendidas tiene menos trabajo pendiente aquí, aunque ese mecanismo nunca cruza un límite entre versiones por diseño.

Cuando la versión ya ha superado el soporte estándar

Una versión intermedia de Ubuntu recibe soporte durante nueve meses. Cuando ese soporte termina, su indicador Supported: pasa a 0 y la ruta normal no ofrece ninguna actualización desde ella. Comprobado el 13 de agosto de 2026, meta-release indica lo siguiente sobre 25.10:

Dist: questing
Name: Questing Quokka
Version: 25.10
Date: Thu, 09 October 2025 00:25:10 UTC
Supported: 0

El archivo también cambia al mismo tiempo. Los paquetes de una versión cuyo ciclo de vida ha terminado se eliminan de archive.ubuntu.com y se conservan en old-releases.ubuntu.com. Por eso apt update empieza a devolver 404 Not Found, el sistema ya no se puede actualizar y, como el actualizador exige que el sistema esté al día, el proceso no continúa. Corrija primero las fuentes.

lsb_release -cs
grep -rn ubuntu.com /etc/apt/sources.list /etc/apt/sources.list.d/

Apunte archive.ubuntu.com y security.ubuntu.com a old-releases.ubuntu.com, y mantenga el mismo nombre en clave. Sólo cambia el nombre del host.

sudo sed -i.bak -e 's/archive.ubuntu.com/old-releases.ubuntu.com/g' \
                -e 's/security.ubuntu.com/old-releases.ubuntu.com/g' \
                /etc/apt/sources.list.d/ubuntu.sources
sudo apt update

Ejecute el mismo comando contra /etc/apt/sources.list si el servidor todavía mantiene las fuentes en ese único archivo. La opción -i.bak escribe una copia de seguridad junto al original, para que pueda restaurarlo si la edición se aplicó al archivo equivocado. Un apt update limpio después indica que el archivo vuelve a estar accesible y do-release-upgrade podrá comunicarse con él.

Sea realista sobre el alcance de este procedimiento. Ubuntu admite un solo salto de versión cada vez. Por tanto, un servidor que esté dos o tres versiones obsoletas por detrás necesita completar cada paso en orden. Cada paso puede fallar por su propio repositorio de terceros o por su propio paquete retenido. En un VPS, a menudo es más rápido crear un servidor nuevo con la LTS actual, migrar el servicio y conservar el servidor antiguo hasta tenerlo confirmado. Esto también proporciona una reversión, algo que una actualización en el mismo sistema nunca ofrece. Si después debe elegir qué rama utilizar, conviene leer la diferencia entre las versiones LTS e intermedias en un servidor antes de decidir.

Qué hace realmente el indicador de la versión de desarrollo

-d o --devel-release hace que el actualizador lea meta-release-development en lugar del archivo que seleccionó Prompt. La página del manual lo describe así: "Si se usa la versión compatible más reciente, actualizar a la versión de desarrollo".

Comprobado el 13 de agosto de 2026, la entrada más reciente de ese archivo no es 26.04:

Dist: stonking
Name: Stonking Stingray
Version: 26.10
Date: Thu, 15 October 2026 00:26:10 UTC
Supported: 0

Por tanto, -d no entrega 26.04, ya publicada, a un servidor 24.04. Apunta a 26.10, una versión que todavía está en desarrollo. Las recomendaciones antiguas de "añadir simplemente -d" correspondían al periodo anterior a la publicación de una LTS. Repetirlas ahora dirige el servidor a una versión distinta de la que pretendía usar. Si Prompt=lts sigue configurado, el indicador se detiene con un mensaje propio:

There is no development version of an LTS available.

La documentación de Ubuntu Server es clara sobre este indicador: "no se recomienda usar la versión de desarrollo (o el indicador -d) en entornos de producción". Una versión de desarrollo cambia a diario y no incluye un compromiso de soporte de seguridad. Por eso, un paquete que funciona por la mañana puede romper un servicio por la tarde. Úselo en una máquina virtual temporal creada para probar su propia configuración. No lo use en un servidor del que dependa alguien. Si necesita una versión 26.04 publicada antes de que se abra la ventana de la LTS, Prompt=normal es la vía correcta.

Ejecute la actualización en un entorno donde una sesión SSH desconectada no pueda interrumpirla

Una actualización de versión sustituye la mayor parte del sistema, incluidos openssh-server y systemd. Si la sesión SSH (secure shell) se cierra mientras dpkg está trabajando, el proceso termina con paquetes desempaquetados y sin configurar. Ese estado impide exactamente el siguiente intento. Inicie siempre la actualización dentro de un multiplexor de terminal.

sudo apt install -y tmux
tmux new -s upgrade
sudo do-release-upgrade

Si se pierde la conexión, vuelva a iniciar sesión y ejecute tmux attach -t upgrade. La actualización continúa ejecutándose porque es un proceso hijo del servidor tmux, no de la sesión SSH. screen -S upgrade y screen -r upgrade hacen lo mismo si prefiere screen.

El actualizador incluye una medida de seguridad para quienes no usan un multiplexor. Cuando detecta que se ejecuta mediante SSH, ofrece iniciar un segundo sshd en el puerto 1022. Así, una sesión principal interrumpida todavía deja una vía de acceso. Para decidirlo, recorre sus propios procesos padre en busca de uno llamado sshd. Dentro de tmux o screen, ese recorrido encuentra en su lugar el servidor del multiplexor. Por eso la oferta no aparece, y el archivo PID /var/run/release-upgrader-sshd.pid sólo se escribe cuando el daemon adicional se inicia realmente. No hay ningún problema si no ve el aviso. Ya cuenta con una protección mejor.

Si acepta la oferta, el puerto no se abre automáticamente. La herramienta lo indica claramente porque abrir un puerto es una decisión de seguridad que no puede tomar en su nombre. Ábralo durante la actualización y ciérrelo de nuevo después.

sudo ufw allow 1022/tcp
sudo ufw delete allow 1022/tcp

La mayoría de los proveedores de VPS ejecutan un segundo firewall en su panel de control, fuera del sistema operativo. El puerto 1022 también debe estar abierto allí. De lo contrario, el listener de respaldo estará activo pero será inaccesible, que es la peor de las dos situaciones.

Antes de escribir el comando, deje preparados estos cuatro elementos:

• Tome una snapshot o una copia de seguridad completa. Una actualización de versión in situ no se puede deshacer, y ésta es la única copia que tendrá.
• Confirme que puede abrir la consola del proveedor antes de necesitarla. Si el servidor no vuelve después de reiniciarse, SSH será precisamente lo que no tendrá. Un kernel que no arranca es un problema independiente con sus propios pasos de recuperación, descritos en un VPS que no arranca después de una actualización del kernel.
• Compruebe el espacio libre con df -h / /boot. La actualización descarga un conjunto completo de paquetes, y una partición /boot que contiene varios kernels antiguos es un lugar habitual donde el proceso se detiene.
• Lea las notas de la versión de los servicios que ejecuta. Con la versión nueva llega un salto de versión importante de PostgreSQL o PHP, tanto si lo había previsto como si no.

FAQ

¿Por qué do-release-upgrade indica que no se encontró ninguna versión nueva en Ubuntu 24.04?

El valor predeterminado de Prompt=lts en /etc/update-manager/release-upgrades hace que la herramienta lea https://changelogs.ubuntu.com/meta-release-lts, y Ubuntu 26.04 mantiene Supported: 0 en ese archivo hasta su primera versión de mantenimiento. El actualizador no encuentra ninguna versión LTS más reciente marcada como disponible y se detiene. Compruebe el archivo con curl -s https://changelogs.ubuntu.com/meta-release-lts y lea el último bloque. El 13 August 2026, el indicador seguía establecido en 0 y Ubuntu 26.04.1 estaba programado para el 27 August 2026.

¿Es seguro establecer Prompt=normal en lugar de esperar a la versión de mantenimiento?

La actualización se realiza a la versión publicada 26.04, no a una compilación de desarrollo, porque Prompt=normal lee meta-release, donde 26.04 ya tiene Supported: 1. El riesgo está en el momento de la actualización. La realiza antes de que se corrijan los problemas detectados por los primeros usuarios. Hágalo en un servidor que pueda restaurar desde una instantánea y al que pueda acceder mediante la consola del proveedor si el reinicio falla. Después, vuelva a establecer el valor en lts.

¿La opción -d actualiza el sistema a 26.04?

No. -d lee meta-release-development, cuya entrada más reciente el 13 August 2026 era Ubuntu 26.10, una versión que todavía estaba en desarrollo. En un equipo LTS con Prompt=lts, la opción muestra There is no development version of an LTS available. y se detiene. La documentación oficial de Ubuntu para servidores indica que la versión de desarrollo no se recomienda para producción. Use Prompt=normal cuando quiera instalar 26.04 antes de tiempo, pero ya publicada.

apt update devuelve errores 404 en una versión antigua. ¿Cómo la actualizo?

Esa versión llegó al final de su ciclo de vida, por lo que sus paquetes se trasladaron de archive.ubuntu.com a old-releases.ubuntu.com. Cambie sólo los nombres de host en /etc/apt/sources.list.d/ubuntu.sources o en /etc/apt/sources.list en diseños más antiguos, y conserve el nombre en clave tal como está. Después, ejecute sudo apt update y sudo apt full-upgrade. Cuando el sistema vuelva a estar actualizado, do-release-upgrade podrá actualizarlo una versión cada vez.

¿Tengo que eliminar mis PPA antes de ejecutar do-release-upgrade?

No es obligatorio, porque el actualizador comenta cualquier fuente que no publique paquetes para la nueva versión y muestra una línea como was disabled (no Release file) para cada una. Es mejor hacerlo antes manualmente, porque así puede elegir el orden y comprobar el resultado. Ejecute apt policy sobre los paquetes que le interesen para identificar cuáles proceden de cada PPA. Después, vuelva a instalar esos paquetes desde el archivo si la versión del PPA es más reciente que la disponible en la nueva versión.