do-release-upgrade: no se encontró ninguna versión

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

do-release-upgrade que termina en No new release found. casi nunca indica que la herramienta esté dañada. La ruta que solicitó está cerrada en ese momento, y la herramienta lo informa de la forma más breve posible. Hay cinco causas que pueden cerrarla: el ajuste Prompt en /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 ha finalizado.

Revise estas causas en ese orden. Cada una tiene un comando que demuestra si se aplica a su servidor, por lo que no tendrá que adivinar cuál de las cinco afecta a su sistema.

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

sudo do-release-upgrade -c
echo $?

-c realiza únicamente la comprobación. Lee los metadatos de versiones de Canonical mediante HTTPS (protocolo seguro de transferencia de hipertexto) e imprime el resultado. No descarga ninguna herramienta de actualización ni reescribe archivos 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 contiene la misma respuesta 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 revíselo antes de crear una comprobación basada en él.

Si el mensaje 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 mensaje 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 situado detrás de un firewall saliente estricto o de 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 (herramienta avanzada de paquetes) no cambiará el resultado.

Si el comando no existe, se encuentra en ubuntu-release-upgrader-core. Algunas imágenes de nube mínimas 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: no busca ni permite actualizar a una versión nueva.
• normal: ofrece la versión compatible que sigue inmediatamente a la versión en ejecución.
• lts: ofrece la primera versión LTS posterior a la versión en ejecución.

Prompt=never es el más fácil de diagnosticar de los tres, porque la herramienta identifica tanto el archivo como el valor 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 hosting y las herramientas de gestión de configuración establecen never deliberadamente para evitar que una flota quede repartida entre varias versiones. Si aparece ese valor, 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 problemas. Cuando se establece Prompt=lts y la versión en ejecución no es una versión LTS, el actualizador trata ese valor como normal. En una máquina con 25.10, ambos valores se comportan igual. En una máquina con 24.04, no. Esa diferencia es el tema 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 están 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: es 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 bloqueo. Un servidor 24.04 que usa el valor predeterminado Prompt=lts 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 máquina. Canonical todavía no ha abierto la ruta.

El indicador cambia a 1 cuando se publica la primera actualización puntual. Ubuntu 26.04.1 está programado para el 27 August 2026, pero las fechas de publicación pueden cambiar, así que compruebe los metadatos en lugar de basarse en un calendario. Una actualización puntual no es una versión nueva de Ubuntu, sino la misma versión con todas las actualizaciones publicadas desde su lanzamiento integradas en un medio de instalación nuevo, por lo que, para un servidor en ejecución, lo importante es la condición que habilita y no el medio en sí. El retraso es deliberado: quienes actualizan pronto detectan los bloqueos, que se corrigen antes de que siga la población mucho mayor de servidores LTS. Si esa fecha ya ha pasado cuando lea esto, lo que incluía 26.04.1 al publicarse y lo que significa para un servidor 24.04 continúa la explicación.

Eso deja dos opciones razonables. Espere a la actualización de mantenimiento, que es la decisión adecuada para cualquier servidor que prefiera no supervisar. O establezca Prompt=normal, que indica a la misma herramienta que use meta-release, donde 26.04 ya aparece como compatible. Esta segunda opción actualiza el sistema a la versión publicada 26.04, no a una versión de desarrollo, por lo que resulta defendible en una máquina que pueda restaurar desde una instantánea. Cuando termine, vuelva a establecer el valor lts. El procedimiento completo, paso a paso, se encuentra en la guía completa para actualizar un servidor de 24.04 a 26.04. Un servidor que todavía use 22.04 debe realizar un salto adicional, porque Prompt=lts sólo ofrece la siguiente versión LTS; por eso, la ruta de 22.04 a 26.04 pasa primero por 24.04.

Repositorios de terceros y PPA 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 esa 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 un aviso que puede aceptar. Se convierte en un bloqueo cuando un repositorio de terceros proporciona un paquete que la nueva versión también incluye, porque el cálculo de la actualización tiene entonces dos candidatos y no puede satisfacer ambas dependencias.

Decida esto antes de iniciar la actualización, 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 aplicado a 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 incluida en la nueva versión. Si esto es relevante, elimine también el paquete y vuelva a instalarlo desde el archivo después de la actualización. Si planea volver a habilitar un repositorio, como el de Tailscale, debe actualizar su nombre de versión a la nueva versión antes de poder instalar de nuevo el paquete. Esta es la causa de la mayoría de los errores de instalación de Tailscale en Ubuntu.

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

En Ubuntu 24.04 y 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 produce un error independiente con su propio mensaje. Este caso se explica en el error de entrada de fuente duplicada en formato deb822.

Paquetes retenidos y configurados a medias detienen el cálculo

Una actualización de versión tiene que mover casi todos los paquetes del sistema. Si un paquete no puede actualizarse, el cálculo falla y 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, y no muestra nada en un sistema sin problemas. Una retención es una instrucción manual para no cambiar nunca ese paquete. Alguien fijó una versión del kernel o de una base de datos y después lo olvidó. Libere los paquetes 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ó la sesión. El actualizador intenta repararlo y muestra dpkg interrupted, calling dpkg --configure -a, pero ejecutar primero la reparación permite leer el error en lugar de verlo pasar por la pantalla. Si la herramienta no puede reparar un paquete, muestra el mensaje Package in inconsistent state. Ese paquete requiere 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 gradualmente entre un porcentaje de máquinas, por lo que un apt upgrade normal puede dejar paquetes pendientes correctamente. En ese caso, el servidor está 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á en ejecución. Un equipo que ya se mantiene actualizado mediante actualizaciones de seguridad desatendidas tiene menos trabajo pendiente, aunque ese mecanismo nunca cruza un límite de versión por diseño.

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

Una versión interina de Ubuntu recibe soporte durante nueve meses. Cuando termina ese soporte, 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 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 puede ponerse al día y, como el actualizador exige un sistema actualizado, el proceso no avanza. 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 nombre en clave sin cambios. 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 su servidor todavía mantiene las fuentes en ese único archivo. La opción -i.bak crea una copia de seguridad junto al archivo original, de modo que puede restaurarlo si la edición se aplicó al archivo equivocado. Un apt update limpio después confirma que el archivo vuelve a ser accesible y do-release-upgrade ya podrá comunicarse con él.

Sea realista sobre lo que puede conseguir con esto. Ubuntu admite un único salto de versión cada vez, por lo que un servidor que esté dos o tres versiones obsoletas por detrás necesita completar cada salto en orden. Además, cada salto 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. Así también obtiene una reversión, algo que una actualización en el mismo sistema nunca ofrece. Si después debe elegir qué línea mantener, conviene leer la diferencia entre las versiones LTS e interinas 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 instrucciones antiguas de «añadir -d» se escribieron para el periodo anterior a la publicación de una LTS. Repetirlas ahora dirige el servidor a una versión que no pretendía instalar. Si Prompt=lts sigue presente, el indicador se detiene y muestra su propio mensaje:

There is no development version of an LTS available.

La documentación de Ubuntu para servidores 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 interrumpir un servicio por la tarde. Úsela en una máquina virtual temporal creada para probar su propia configuración. No la use en un servidor del que dependa alguien. Si necesita una versión 26.04 publicada antes de que se abra el periodo de actualización de la LTS, Prompt=normal es la opción correcta.

Ejecute la actualización en un entorno donde una sesión SSH interrumpida no pueda detenerla

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 interrumpe mientras dpkg está trabajando, el proceso termina con paquetes desempaquetados y sin configurar. Ese estado impide exactamente el siguiente intento. Si ya le ha ocurrido, recuperar una actualización interrumpida a mitad del proceso es una tarea independiente y debe completarse antes de volver a intentarlo. 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 interrumpe la conexión, vuelva a iniciar sesión y ejecute tmux attach -t upgrade. La actualización siguió ejecutándose porque es un proceso hijo del servidor tmux y no de la sesión SSH. screen -S upgrade y screen -r upgrade hacen lo mismo si prefiere screen.

El actualizador incluye su propio mecanismo de protección 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. Lo determina recorriendo sus propios procesos padre en busca de uno llamado sshd. Dentro de tmux o screen, ese recorrido encuentra el servidor del multiplexor en su lugar. 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 dispone de 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 combinación.

Antes de escribir el comando, deje preparadas estas cuatro cosas:

• Cree una snapshot o una copia de seguridad completa. Una actualización de versión in situ no se puede deshacer y esta es la única oportunidad que tendrá.
• Confirme que puede abrir la consola del proveedor antes de necesitarla. Si el servidor no vuelve a iniciarse después del reinicio, 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 actualizar el 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 llega un salto de versión principal de PostgreSQL o PHP, aunque no lo hubiera previsto.

FAQ

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

La configuración predeterminada 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 primer lanzamiento de punto. El actualizador no encuentra ninguna versión LTS más reciente marcada como disponible, por lo que se detiene. Compruebe el archivo directamente con curl -s https://changelogs.ubuntu.com/meta-release-lts y lea el último bloque. El 13 de agosto de 2026, el indicador seguía siendo 0, y Ubuntu 26.04.1 estaba programado para el 27 de agosto de 2026.

¿Es seguro establecer Prompt=normal en lugar de esperar al lanzamiento de punto?

Actualiza el sistema 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. Se 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 de agosto de 2026 era Ubuntu 26.10, una versión que todavía estaba en desarrollo. En un sistema 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 servidores de Ubuntu indica que la versión de desarrollo no se recomienda para producción. Por tanto, use Prompt=normal si quiere instalar antes una versión publicada de 26.04.

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

Esa versión llegó al final de su vida útil, 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 diseños más antiguos, en /etc/apt/sources.list, y mantenga el mismo nombre en clave. Después, ejecute sudo apt update y sudo apt full-upgrade. Cuando el sistema vuelva a estar actualizado, do-release-upgrade puede avanzar una versión cada vez.

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

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