Ubuntu 26.04.1: qué es y por qué no descarga nada

Qué es una versión de mantenimiento de Ubuntu

Una versión de mantenimiento de Ubuntu, como 26.04.1, es la versión que ya tiene instalada con todas las actualizaciones publicadas desde su lanzamiento integradas en unos medios de instalación nuevos. No es una versión nueva. El archivo desde el que se instala no cambia, ni tampoco cambia el nombre de la suite en las fuentes de apt. Por tanto, un servidor instalado y actualizado no tiene nada que descargar cuando aparece una versión de mantenimiento.

El día de su publicación se actualizan dos elementos. Se vuelven a generar los medios: nuevos archivos ISO y nuevas imágenes para la nube, creados a partir del estado que tenía el archivo esa semana. También cambia la cadena de versión: lsb_release -a empieza a mostrar 26.04.1 LTS donde antes mostraba 26.04 LTS.

Todo lo demás ya estaba disponible en el sistema. Ubuntu publica correcciones continuamente en los pockets -security y -updates de una misma suite: resolute para 26.04 y noble para 24.04. Una versión de mantenimiento es una instantánea de ese flujo. No existe un destino independiente al que haya que migrar.

Por qué su servidor actualizado no tiene nada que descargar

El número de punto se encuentra en un paquete pequeño. Ejecute lo siguiente:

lsb_release -a
dpkg -S /etc/lsb-release

dpkg -S responde base-files: /etc/lsb-release. El paquete base-files contiene los archivos que almacenan la cadena de versión. Por eso, cuando se publica una versión de punto, un nuevo base-files llega al repositorio -updates y su siguiente sudo apt upgrade lo instala. Ese paquete es todo el efecto visible de una versión de punto en un equipo en ejecución. Todo lo demás que contiene se instaló semanas atrás como actualizaciones normales.

Hay una forma habitual de quedarse atrás. El /etc/apt/apt.conf.d/50unattended-upgrades predeterminado habilita el origen -security en su bloque Allowed-Origins y deja comentada la línea -updates. Por eso, un equipo que sólo usa actualizaciones automáticas instala las correcciones de seguridad y omite el resto. Ese equipo sigue mostrando un número de punto antiguo durante meses. Es correcto que lo haga porque realmente no tiene esos paquetes. Abra el archivo y compruebe qué líneas están comentadas: cómo se configuran las actualizaciones desatendidas en Ubuntu revisa ese bloque línea por línea.

Cuando llegue la siguiente versión de mantenimiento

Aprenda la cadencia, no la fecha. La primera versión de mantenimiento de una LTS aparece unos meses después de la versión original de abril. Las siguientes suelen publicarse con intervalos aproximados de seis meses y coinciden con cada versión intermedia. Las fechas cambian. Canonical anunció inicialmente la primera versión de mantenimiento de 26.04 para principios de agosto de 2026 y después la retrasó. Esto es habitual y no indica ningún problema. Consulte la fecha en la página del ciclo de versiones de Ubuntu o en las notas de la versión de 26.04 LTS, no en ningún artículo, incluido este.

Por qué 24.04 no ofrece 26.04 hasta la primera versión de mantenimiento

El aviso de actualización está configurado para esperar. Puede consultar esa configuración en su propio sistema.

cat /etc/update-manager/release-upgrades

[DEFAULT]
# never  - Never check for, or allow upgrading to, a new release.
# normal - Check to see if a new release is available.
# lts    - Check to see if a new LTS release is available.
Prompt=lts

Los comentarios del archivo incluido son más extensos que ese fragmento y conviene leerlos completos. Prompt=lts es el valor predeterminado en una instalación LTS y cumple dos funciones: limita la oferta a versiones LTS y envía la comprobación a otra lista.

Esa lista se define en un segundo archivo:

cat /etc/update-manager/meta-release

URI apunta a https://changelogs.ubuntu.com/meta-release y URI_LTS apunta a https://changelogs.ubuntu.com/meta-release-lts. Con Prompt=lts, el actualizador lee la lista LTS. La nueva versión LTS no aparece allí como destino de actualización hasta que existe su primera versión de mantenimiento. Descargue la lista y compruébelo:

curl -s https://changelogs.ubuntu.com/meta-release-lts | tail -40

Cada versión es un bloque de líneas Dist:, Version:, Supported: y UpgradeTool:. El actualizador necesita ese bloque antes de poder ofrecer una actualización. Canonical indica la misma regla en términos claros en el anuncio de lanzamiento de 26.04 LTS: los usuarios de 24.04 LTS reciben la actualización automática cuando se publica 26.04.1.

Por tanto, en un servidor 24.04 antes de esa versión:

sudo do-release-upgrade -c

Checking for a new Ubuntu release
No new release found.

Es un resultado normal, no un fallo. Cuando se abre la ruta de actualización, el mismo comando muestra la versión y el mismo mensaje aparece en el banner de inicio de sesión:

New release '26.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

Observe qué versión indica. No se actualiza primero a 26.04 y después a 26.04.1. Se actualiza una sola vez y se llega al estado actual de 26.04.

Hay otras dos causas por las que esa comprobación no devuelve resultados: Prompt=never, que algunos proveedores establecen en sus imágenes, y un proxy o mirror que no puede acceder a changelogs.ubuntu.com. Un mensaje diferente, Please install all available updates for your release before upgrading, significa que la comprobación se completó correctamente y que el actualizador necesita un punto de partida completamente actualizado. do-release-upgrade indica que no se encontró ninguna versión nueva explica las causas restantes. Cuando la ruta está abierta y usted está preparado, la actualización de 24.04 a 26.04 es una tarea independiente con su propia preparación.

El indicador -d dirige la misma comprobación a la lista de desarrollo. Así es como algunas personas avanzan antes de que se abra la ruta de actualización. La espera existe por un motivo: es el periodo en el que se corrigen los bloqueos de actualización que detectan los primeros usuarios. En un servidor que alquila y del que depende, conviene dejar que la espera cumpla su función.

Qué significa el kernel de habilitación de hardware en un VPS

Una versión LTS incluye un kernel durante todo su ciclo de vida: el kernel GA (disponibilidad general). También ofrece un segundo canal con actualizaciones periódicas, llamado HWE (habilitación de hardware). El canal HWE se distribuye mediante versiones de mantenimiento, y es la única parte de una versión de mantenimiento que incluye código realmente nuevo en lugar de volver a empaquetar lo que ya tiene instalado.

24.04 es el ejemplo utilizado. Se publicó con el kernel 6.8 y mantiene 6.8 en el canal GA durante sus cinco años completos de soporte estándar. El canal HWE comenzó con la segunda versión de mantenimiento: 24.04.2 incorporó el kernel 6.11 de Ubuntu 24.10, y 24.04.3 incorporó 6.14 de Ubuntu 25.04. En agosto de 2026, este es el patrón establecido, y 26.04 sigue la misma estructura.

El canal que usa se identifica por el nombre de un paquete:

uname -r
apt list --installed 2>/dev/null | grep -E '^linux-(generic|virtual|image|kvm)'

linux-generic es el canal GA. linux-generic-hwe-24.04 es el canal con actualizaciones periódicas. Las instalaciones de escritorio usan HWE de forma predeterminada y las instalaciones de servidor usan GA. Sin embargo, las imágenes de proveedor para un VPS suelen usar una variante aún más específica, como linux-virtual o linux-kvm para la nube. Compruébelo en lugar de asumirlo, porque el valor predeterminado depende de quién haya creado la imagen.

En un servidor virtual alquilado, la habilitación de hardware casi nunca le afecta. El servidor ve dispositivos virtio y las interfaces de red y disco paravirtualizadas que presenta el hipervisor. Estos controladores llevan más de una década siendo estables en el kernel. Un portátil nuevo necesita HWE. Un VPS casi nunca lo necesita. En este caso, un kernel más reciente le proporciona principalmente funciones del kernel: mejoras más recientes en io_uring y eBPF, o una corrección del sistema de archivos que tenga un motivo concreto para necesitar. novedades del kernel 7.1 de Linux le permite decidir si alguna de estas mejoras compensa los cambios.

El coste son los reinicios y el riesgo. El metapaquete HWE instala un kernel nuevo de upstream aproximadamente cada seis meses, por lo que acepta un cambio de kernel y un reinicio con esa frecuencia. Los módulos externos compilados con DKMS, especialmente ZFS, pueden no compilarse con la nueva versión, y lo descubrirá durante el arranque. Cada kernel también conserva la versión anterior, y así es como se llena un /boot pequeño. Lea cómo eliminar kernels antiguos de un /boot lleno y cómo elegir el kernel con el que arranca su VPS antes de necesitarlos, no después.

Cambiar al canal HWE requiere un comando y un reinicio:

sudo apt install --install-recommends linux-generic-hwe-24.04
sudo reboot

uname -r después del reinicio debería mostrar la versión más reciente. Mantenga instalado el kernel anterior hasta que haya arrancado con el nuevo y comprobado sus servicios. Si el kernel no arranca, la recuperación consiste en seleccionar la entrada anterior en el menú de arranque, y esa entrada debe seguir existiendo. Si ya no existe, deberá recuperar un VPS que no arranca después de una actualización del kernel.

También existe una variante -edge del paquete HWE que incorpora el siguiente kernel antes de la versión de mantenimiento. Está destinada a pruebas. No la use en un servidor.

La opción predeterminada para un servidor alquilado es el kernel GA: una versión del kernel durante cinco años, con correcciones de seguridad adaptadas durante todo ese periodo y sin cambios de versión programados. Cambie a HWE cuando pueda identificar la función que necesita.

Por qué una instalación nueva de hoy difiere de la del mes pasado

Las imágenes se reconstruyen con más frecuencia que las versiones menores. Ubuntu publica imágenes para la nube identificadas con un número de serie, y cada proveedor actualiza sus plantillas de Ubuntu según su propio calendario. Por eso, dos servidores creados con seis meses de diferencia desde la misma opción del menú pueden arrancar con versiones distintas del kernel y con versiones iniciales diferentes de los paquetes. Ninguno de los dos está mal.

Esto importa más de lo que parece. Un procedimiento operativo que indica ejecutar cinco comandos después de la instalación presupone en silencio un estado inicial que ya no se cumple. Compruebe lsb_release -a y uname -r en cada servidor en lugar de confiar en la etiqueta que seleccionó. Después, defina el estado final mediante código para que el estado inicial deje de importar. un primer playbook de Ansible para un VPS es la versión útil más pequeña de ese enfoque.

¿Conviene actualizar en la primera versión de mantenimiento o esperar?

• Si ya usa 26.04, no hay ninguna versión posterior a la que actualizar. Siga instalando las actualizaciones y el número de versión de mantenimiento avanzará por sí solo.
• Si usa 24.04, el soporte estándar continúa hasta abril de 2029, por lo que esperar no supone un coste importante. La primera versión de mantenimiento es una oportunidad, no una fecha límite.
• Actualice primero una copia. Cree una instantánea del servidor o reconstruya la misma pila en una VPS desechable, ejecute allí la actualización y mida cuánto tarda.
• Si necesita un kernel más reciente y no una versión más reciente, el canal HWE se lo proporciona en 24.04 sin actualizar a otra versión LTS.

La cuestión más amplia de qué versión debe usar se trata en Versiones LTS frente a versiones provisionales para un servidor.

Qué comprobar en su propio servidor

lsb_release -a
uname -r
grep -v '^#' /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

Un resultado correcto tiene este aspecto: lsb_release -a muestra su release con el número de revisión actual, uname -r coincide con la rama del kernel que debía utilizar, Prompt=lts está presente y la comprobación no encuentra nada o indica el release que ofrecerá. Cualquier otro resultado debe analizarse antes de una actualización, no durante ella.

FAQ

¿Tengo que hacer algo cuando sale una versión de mantenimiento como 26.04.1?

No, siempre que el servidor ya use esa versión y reciba actualizaciones. Una versión de mantenimiento incorpora las actualizaciones ya publicadas en nuevos medios de instalación. Un equipo en ejecución recibe el mismo contenido mediante apt upgrade cuando se publica, y la cadena de versión de lsb_release -a cambia cuando se actualiza el paquete base-files. No hay que cambiar a otra versión ni reinstalar.

¿Por qué mi servidor sigue mostrando un número de versión de mantenimiento anterior después de ejecutar apt upgrade?

Normalmente, porque las actualizaciones automáticas están limitadas a las correcciones de seguridad. El /etc/apt/apt.conf.d/50unattended-upgrades predeterminado habilita el origen -security y deja comentada la línea -updates, mientras que el paquete base-files, que contiene la cadena de versión, llega mediante -updates. Ejecute sudo apt update && sudo apt full-upgrade manualmente y compruebe si base-files aparece en la lista. Si figura como retenido, alguna configuración de prioridades o algún bloqueo impide su actualización.

¿Por qué no se ofrece 26.04 a mi servidor con 24.04?

Porque Prompt=lts en /etc/update-manager/release-upgrades es la opción predeterminada en una versión LTS, y comprueba la lista de versiones LTS en https://changelogs.ubuntu.com/meta-release-lts. La nueva versión LTS no se ofrece como destino de actualización hasta que aparece su primera versión de mantenimiento. Hasta entonces, sudo do-release-upgrade -c muestra No new release found., y ese comportamiento es correcto. La espera es deliberada: permite corregir los problemas de actualización que detectan los primeros usuarios.

¿Debo instalar el kernel HWE en mi VPS?

Normalmente, no. HWE existe para admitir hardware más nuevo que la versión instalada, y un VPS presenta dispositivos virtio cuyos controladores llevan años incluidos en el kernel. El kernel GA permanece en una misma versión durante todo el ciclo de vida de la versión LTS, con las correcciones adaptadas y retroportadas. Use el kernel HWE sólo si puede indicar qué función del kernel necesita, y tenga en cuenta que después deberá aceptar un cambio de kernel y un reinicio aproximadamente cada seis meses.