Ubuntu LTS o provisional para un servidor

Ubuntu LTS frente a versiones provisionales: respuesta breve

Elegir entre una versión LTS y una versión provisional de Ubuntu para un servidor depende de un único dato: durante cuánto tiempo recibe actualizaciones de seguridad esa versión. Una LTS recibe cinco años de mantenimiento de seguridad estándar. Una versión provisional recibe nueve meses; después, las actualizaciones se detienen y es necesario actualizarla o reconstruirla. Use una LTS en cualquier sistema del que dependan otras personas. Use una versión provisional sólo cuando pueda reconstruirla sin tener que pedir autorización.

LTS significa soporte a largo plazo. Canonical publica una LTS cada dos años, en abril de los años pares, y una versión provisional cada seis meses entre ellas. 26.04 LTS se publicó el 23 de abril de 2026 y su mantenimiento de seguridad estándar se prolonga hasta 2031. 26.10 está prevista para el 15 de octubre de 2026 y es una versión provisional, por lo que su ciclo termina en julio de 2027.

Cuánto tiempo recibe soporte cada versión de Ubuntu

[
  {
    "label": "LTS, standard support",
    "support_months": 60,
    "upgrades_over_5_years": 1
  },
  {
    "label": "LTS with Ubuntu Pro",
    "support_months": 120,
    "upgrades_over_5_years": 0
  },
  {
    "label": "Interim release",
    "support_months": 9,
    "upgrades_over_5_years": 10
  }
]

Esas son las cifras de la política publicada por Canonical en agosto de 2026, no mediciones realizadas en un servidor de prueba. Una versión LTS recibe 60 meses de mantenimiento de seguridad estándar, lo que equivale a 1 actualización de versión planificada en cinco años. Una versión intermedia recibe 9 meses. Mantenerse en el ciclo de versiones intermedias durante esos mismos cinco años requiere 10 actualizaciones de versión, porque no se puede omitir una versión y cinco años contienen diez.

Una suscripción a Ubuntu Pro eleva la cifra de las versiones LTS a 120 meses, es decir, diez años, y amplía la cobertura del componente main a todo el archivo. En agosto de 2026, Pro es gratuito para uso personal en un máximo de cinco máquinas, lo que cubre la mayoría de las flotas pequeñas de VPS. No existe una opción equivalente para una versión intermedia. Nueve meses es toda la cobertura disponible y ninguna suscripción la amplía.

Qué cuesta nueve meses en un servidor real

Tomemos 26.10 como ejemplo. Se publica el 15 de octubre de 2026 y su mantenimiento de seguridad termina en julio de 2027, el mismo ciclo de nueve meses que terminó para 25.10 en julio de 2026. Si se interpreta como un calendario, parece que hay una ventana de mantenimiento cada tres trimestres. Esa interpretación es incorrecta y lo es en el sentido más costoso.

Una actualización de versión sustituye el sistema operativo en el mismo lugar. do-release-upgrade reescribe las fuentes de apt, desactiva los repositorios de terceros, cambia la versión de casi todos los paquetes instalados, se detiene para preguntar por los archivos de configuración que has editado y reinicia al final. Por eso es una ventana planificada y no una tarea en segundo plano.

Si la ejecutas mediante ssh, la herramienta te protege si se interrumpe tu conexión. Inicia su propia sesión screen y abre un segundo sshd, algo que te indica antes:

To make recovery in case of failure easier, an additional sshd will
be started on port '1022'. If anything goes wrong with the running ssh
you can still connect to the additional one.

Déjala hacerlo. Si tu firewall o el firewall de red independiente de tu proveedor bloquea 1022, esa alternativa no existe y una conexión interrumpida deja entonces un conjunto de paquetes actualizado sólo parcialmente. Ejecutar tú mismo la actualización dentro de tmux o screen proporciona la misma protección en cualquier equipo.

Las solicitudes sobre archivos de configuración son las que convierten una actualización de quince minutos en una hora:

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?

Si conservas tu archivo, no incorporas los cambios del nuevo valor predeterminado. Si aceptas el archivo del mantenedor, pierdes el hardening hasta que lo vuelves a aplicar. Ninguna respuesta es segura sin saber qué ha cambiado en esa versión, por lo que leer las notas de la versión forma parte de la ventana y no es una tarea opcional.

Después hay que multiplicar por el número de equipos. Un VPS en el ciclo intermedio requiere diez ventanas de actualización en cinco años. Cinco VPS requieren cincuenta, salvo que cada equipo sea desechable y se reconstruya desde una imagen. Cinco equipos en el ciclo LTS requieren cinco actualizaciones en el mismo periodo, y puedes elegir el mes en que se realiza cada una.

Por qué no se puede omitir una versión de Ubuntu

Las rutas de actualización son fijas. Una versión intermedia se actualiza a la siguiente versión, sea cual sea. Una LTS se actualiza directamente a la siguiente LTS o a la siguiente versión intermedia si se solicita. Ninguna actualización salta dos versiones de una vez. Pasar de 26.10 a 28.04 LTS implica hacerlo a través de 27.04 y 27.10, o reinstalar el equipo.

Conviene conocer el mecanismo porque demuestra que esta regla no se puede eludir. do-release-upgrade obtiene un archivo meta-release de changelogs.ubuntu.com y después descarga una herramienta de actualización creada para una transición específica. Canonical crea y prueba una transición cada vez, por lo que un salto que omita una versión no tiene ninguna herramienta ni pruebas que lo respalden. El actualizador no lo rechaza por precaución. No existe ninguna opción que pueda ofrecer.

La versión que se ofrece se determina mediante una línea de configuración:

grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

Prompt=lts ofrece sólo la siguiente LTS. Prompt=normal ofrece la siguiente versión, sea LTS o no. Prompt=never no ofrece ninguna, lo que permite impedir que un compañero bienintencionado inicie una actualización que no se había planificado. En una versión que no es LTS, lts se comporta exactamente igual que normal, porque la siguiente versión después de 26.10 es 27.04 con cualquiera de los dos valores. La comprobación muestra Checking for a new Ubuntu release y después una línea New release ... available. o No new release found.

Hay otra regla de planificación que suele causar confusión. La actualización de una LTS a otra LTS no se ofrece el día que se publica la nueva LTS. Se habilita con la primera actualización de punto, y 26.04.1 está prevista para el 27 de agosto de 2026. Una actualización de punto no es una versión nueva de Ubuntu, sino la misma versión con cuatro meses de correcciones acumuladas integradas en nuevos medios de instalación, y la espera permite que la ruta de actualización acumule esos cuatro meses de pruebas antes de ofrecérsela a los usuarios. Un equipo con 24.04 y Prompt=lts que respondía No new release found. durante el verano de 2026 no estaba averiado. Seguía la política establecida. Cuando se abra la ruta, la actualización de 24.04 a 26.04 LTS será la operación que se debe planificar y ensayar.

Cuándo elegir una versión intermedia

Hay cuatro casos en los que realmente ofrece ventajas:

• Necesita ahora, en este equipo, una versión del kernel o del espacio de usuario que el archivo de la versión LTS no incluye.
• El equipo es un host de compilación, un ejecutor de CI o un sistema de pruebas que se reconstruye desde una imagen. En ese caso, la actualización consiste en crear una instancia nueva en lugar de abrir una ventana de mantenimiento.
• Una función del hardware o del hipervisor apareció después de que se congelara la versión LTS y no existe ningún backport.
• Está comprobando qué incluirá la próxima versión LTS. 28.04 se construye a partir de 26.10, 27.04 y 27.10, y detectar un cambio incompatible en un VPS de pruebas cuesta menos que detectarlo en el equipo importante.

La mayoría de las personas que eligen una versión intermedia necesitan un paquete más reciente, no una distribución más reciente. Hay dos alternativas más económicas. La pila de habilitación de hardware incorpora kernels de versiones posteriores en una versión LTS. En 24.04 es sudo apt install linux-generic-hwe-24.04 y avanza con cada actualización puntual, a partir de la segunda. Para una sola aplicación, una imagen de contenedor o el repositorio del propio proveedor actualiza un componente en lugar de todo el sistema operativo.

Cuándo no conviene elegir una versión intermedia

• Cualquier sistema con usuarios de pago o un turno de guardia. Aceptaría una actualización obligatoria dos veces al año a cambio de versiones de paquetes que quizá nunca utilice.
• Cualquier equipo donde unattended-upgrades se encargue de aplicar los parches de seguridad. Esa automatización sólo es tan fiable como el repositorio de seguridad del que obtiene los paquetes.
• Una flota que actualiza manualmente, porque el coste real es una ventana de mantenimiento multiplicada por el número de equipos.
• Cualquier sistema que instale y después no revise durante un año. Una versión intermedia olvidada se convierte en un servidor expuesto a Internet y sin parches nueve meses después.

Este último fallo es silencioso, y por eso resulta peligroso. Cuando una versión llega al final de su vida útil, sus paquetes se trasladan a old-releases.ubuntu.com, por lo que sudo apt update empieza a fallar contra archive.ubuntu.com con errores 404. Las listas de paquetes almacenadas en disco quedan obsoletas. unattended-upgrades sigue ejecutándose según su temporizador y continúa escribiendo líneas como esta en /var/log/unattended-upgrades/unattended-upgrades.log:

No packages found that can be upgraded unattended and no pending auto-removals

Esa línea es igual en un servidor completamente actualizado y en un servidor cuya versión dejó de recibir soporte hace cuatro meses. Si nadie lee los errores de apt ni realiza un seguimiento de la fecha de final de vida útil, nada en el equipo indica cuál de los dos casos está observando.

El tipo de cambio que llega primero al canal intermedio

En marzo de 2026, un ingeniero de Canonical propuso en Ubuntu Discourse retirar el cargador de arranque GRUB firmado que se incluye para secure boot en 26.10. La propuesta elimina los controladores del sistema de archivos para btrfs, hfsplus, xfs y zfs, los analizadores de imágenes JPEG y PNG, las tablas de particiones de Apple, /boot en LVM, el RAID por software que no sea RAID 1 y un /boot cifrado con LUKS. El motivo indicado es que los analizadores dentro de un cargador de arranque son una fuente recurrente de errores de seguridad, y que la lógica de almacenamiento y cifrado debe estar en el initramfs, el pequeño sistema de archivos RAM inicial que el kernel monta antes de montar el root real. En agosto de 2026, esto sigue siendo una propuesta en discusión, no un cambio incluido en una versión publicada.

En la mayoría de las instancias VPS no cambiaría nada, porque arrancan sin secure boot desde un /boot ext4 simple ubicado en una tabla de particiones GPT. Compruébelo en su sistema en lugar de asumirlo. Si su root es ZFS, o /boot está en btrfs o dentro de LUKS, este es exactamente el tipo de cambio que le afecta primero en el canal intermedio, y el propio hilo recomienda a los usuarios afectados mantener una versión LTS. Ese consejo resume todo el argumento en una sola frase. Las versiones intermedias son el lugar donde se prueban los cambios. Una LTS es donde llegan después de que dos años de versiones intermedias hayan mostrado qué cosas rompen.

El mismo patrón aparece de formas menores en cada versión intermedia. Las versiones predeterminadas de la base de datos, el runtime del lenguaje y la configuración de init avanzan, por lo que los archivos de configuración que funcionaban pueden dejar de hacerlo. Avanzar las versiones predeterminadas es la función de una versión intermedia, así que leer las notas de la versión antes de cada una de esas diez actualizaciones forma parte del coste que aceptó pagar.

Elegir la versión al preparar el servidor

Elija la versión durante la instalación. Cambiarla después requiere reinstalar el sistema o encadenar varias actualizaciones. En un servidor nuevo, cuatro comandos muestran la situación:

lsb_release -a
grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c
pro security-status

lsb_release -a debe indicar la versión que pretendía instalar. En una versión LTS, la línea de descripción termina con LTS. La línea Prompt debe coincidir con la versión que eligió, no con la que incluía la imagen del proveedor. do-release-upgrade -c en una LTS actual debe devolver No new release found.. Si ofrece una versión intermedia, Prompt está establecido en normal y alguien debe determinar si fue una decisión intencionada. pro security-status indica cuántos paquetes instalados están cubiertos por cada flujo de actualizaciones y muestra claramente si el equipo no está asociado a una suscripción.

Anote después la fecha de fin de vida en un lugar donde vuelva a verla, junto con el resto de las notas de instalación de ese servidor. Esto forma parte de las tareas de los primeros diez minutos en un VPS nuevo, porque una fecha de soporte que sólo está en la memoria de alguien es la que caduca sin que nadie lo advierta. Si quiere evitar por completo el ciclo de seis meses, el modelo de versiones de FreeBSD comparado con Linux merece una hora de lectura antes de comprometer una flota con cualquiera de los dos.

FAQ

¿Debo ejecutar una versión provisional de Ubuntu en un servidor de producción?

En casi todos los casos, no. Una versión provisional deja de recibir actualizaciones de seguridad nueve meses después de su lanzamiento. Por tanto, usarla en producción implica una ventana de actualización obligatoria aproximadamente dos veces al año, de forma indefinida. Las excepciones reales son las máquinas que se reconstruyen a partir de una imagen de todos modos, como los ejecutores de CI y los hosts de compilación, donde una actualización crea una instancia nueva en lugar de abrir una ventana de mantenimiento. Si hay usuarios reales que dependen del servidor, instale la LTS y use esas ventanas ahorradas para otra tarea.

¿Durante cuánto tiempo recibe soporte una versión provisional de Ubuntu?

Nueve meses. 26.10 se publica el 15 de octubre de 2026 y su mantenimiento de seguridad termina en julio de 2027, igual que 25.10 terminó en julio de 2026. Todas las versiones provisionales siguen este ciclo: se publican en abril u octubre y finalizan nueve meses después. Una LTS recibe cinco años de mantenimiento de seguridad estándar, ampliables a diez años con Ubuntu Pro, que en agosto de 2026 es gratuito para uso personal en hasta cinco máquinas.

¿Puedo omitir versiones de Ubuntu al actualizar?

No. do-release-upgrade avanza de una versión cada vez: una versión provisional pasa a la siguiente versión, y una LTS puede pasar directamente a la siguiente LTS. Para pasar de 26.10 a 28.04 LTS, primero debe ejecutar la actualización a través de 27.04 y 27.10, o reinstalar la máquina. Canonical crea y prueba una transición cada vez, y el actualizador descarga una herramienta específica para ese salto. Por tanto, no existe ninguna herramienta para un salto de dos versiones y nunca se ofrece.

¿Qué ocurre cuando mi versión de Ubuntu llega al final de su vida útil?

Sus paquetes pasan a old-releases.ubuntu.com. Por eso, sudo apt update empieza a fallar contra archive.ubuntu.com con errores 404, y no se publican más actualizaciones de seguridad para esa versión. La máquina no muestra ningún aviso. El servidor sigue funcionando y atendiendo tráfico, mientras cada vulnerabilidad nueva que se publica en él permanece sin corregir. La recuperación consiste en ejecutar una actualización de versión bajo presión de tiempo o reconstruir el sistema. Por tanto, supervise la fecha y no espere a que aparezcan síntomas.

¿El kernel de la LTS es demasiado antiguo para el hardware nuevo?

Normalmente no, porque una LTS no conserva su kernel original durante cinco años. La pila de habilitación de hardware, HWE, incorpora kernels de versiones posteriores en la LTS mediante las actualizaciones de punto. Una instalación de servidor puede habilitarla con un paquete como linux-generic-hwe-24.04. Compruebe qué kernel está ejecutando con uname -r antes de asumir que el kernel es el bloqueo. Si falta una versión de espacio de usuario y no una versión del kernel, un contenedor o un repositorio del proveedor supone un cambio mucho menor que trasladar toda la máquina al ciclo de versiones provisionales.