Ubuntu LTS o provisional para un servidor: diferencias

Ubuntu LTS frente a versiones provisionales: respuesta breve

Elegir entre una versión Ubuntu LTS y una versión provisional para un servidor depende de un solo 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 debe 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 a nadie.

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. Está previsto que 26.10 se publique el 15 de octubre de 2026. Es una versión provisional, por lo que su periodo de soporte termina en julio de 2027.

Duración del soporte de 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 tiene 60 meses de mantenimiento de seguridad estándar. Esto equivale a 1 actualización planificada de versión en cinco años. Una versión provisional tiene 9 meses. Mantenerse en el ciclo de versiones provisionales durante esos mismos cinco años requiere 10 actualizaciones de versión, porque no se puede omitir ninguna versión y en cinco años se publican diez.

Una suscripción a Ubuntu Pro aumenta 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 equipos, lo que cubre la mayoría de las flotas pequeñas de VPS. No existe una opción equivalente para una versión provisional. La oferta completa son nueve meses 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 el error aumenta los costes.

Una actualización de versión sustituye el sistema operativo en el mismo equipo. do-release-upgrade reescribe las fuentes de apt, deshabilita 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 haya editado y reinicia al final. Por eso debe planificarse como una ventana de mantenimiento y no ejecutarse como una tarea en segundo plano.

Si la ejecuta mediante ssh, la herramienta le protege si se interrumpe su conexión. Inicia su propia sesión de screen y abre un segundo sshd. Primero se lo notifica:

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éjelo así. Si el firewall o el firewall de red independiente de su proveedor bloquea 1022, esa alternativa no estará disponible. Una conexión interrumpida dejará entonces un conjunto de paquetes actualizado sólo parcialmente. Si ejecuta la actualización dentro de tmux o screen, obtendrá la misma protección en cualquier servidor.

Las preguntas sobre los 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 conserva su archivo, puede perder los cambios introducidos en el nuevo valor predeterminado. Si acepta el archivo del mantenedor, perderá el refuerzo de seguridad hasta volver a aplicarlo. Ninguna respuesta es segura sin saber qué ha cambiado en esa versión. Por eso 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 servidores. Un VPS en el ciclo intermedio requiere diez ventanas de actualización en cinco años. Cinco VPS requieren cincuenta, salvo que todos sean desechables y se reconstruyan desde una imagen. Cinco servidores en el ciclo LTS requieren cinco actualizaciones en el mismo periodo, y usted elige 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. Para pasar de 26.10 a 28.04 LTS hay que pasar por 27.04 y 27.10, o reinstalar la máquina.

Conviene conocer el mecanismo porque muestra que esta regla no se puede eludir. do-release-upgrade obtiene un archivo de metaversión de changelogs.ubuntu.com y luego descarga una herramienta de actualización creada para una transición concreta. 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 hay ninguna actualización disponible que pueda ofrecer.

La versión que se ofrece depende de 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 colega 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 las dos opciones. 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 en que se publica la nueva LTS. Se habilita con la primera actualización puntual, y 26.04.1 está programada para el 27 de agosto de 2026. Un equipo con 24.04 y Prompt=lts que respondía No new release found. durante el verano de 2026 no tenía ningún problema. Seguía la política establecida. Cuando se abra la ruta, la actualización de 24.04 a 26.04 LTS será la que haya que planificar y ensayar.

Cuándo conviene 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.
• La máquina es un host de compilación, un runner de CI o un equipo de pruebas que se reconstruye desde una imagen. En ese caso, una actualización crea una instancia nueva en lugar de requerir una ventana de mantenimiento.
• Una función del hardware o del hipervisor se incorporó después de que se congelara la LTS y no existe ningún backport.
• Está comprobando qué incluirá la próxima LTS. 28.04 se construye a partir de 26.10, 27.04 y 27.10, y detectar un cambio incompatible en un VPS de reserva 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. Existen dos alternativas más económicas. La pila de habilitación de hardware incorpora kernels de versiones posteriores en una 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 servicio 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 en el que 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 el 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

La 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 las dos situaciones se está produciendo.

El tipo de cambio que llega primero al canal intermedio

En marzo de 2026, un ingeniero de Canonical propuso en Ubuntu Discourse eliminar el cargador de arranque GRUB firmado que se incluye para el arranque seguro en 26.10. La propuesta elimina los controladores de 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 distinto de RAID 1 y un /boot cifrado con LUKS. El motivo indicado es que los analizadores integrados en un cargador de arranque son una fuente recurrente de fallos de seguridad, y que la lógica de almacenamiento y cifrado debe estar en el initramfs, el sistema de archivos RAM inicial que el kernel monta antes de la raíz real. En agosto de 2026, esto sigue siendo una propuesta en discusión, no un cambio publicado.

En la mayoría de las instancias VPS no cambiaría nada, porque arrancan sin secure boot desde un /boot ext4 simple en una tabla de particiones GPT. Compruebe su configuración en lugar de darla por supuesta. Si su raíz 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. El propio hilo recomienda a los usuarios afectados permanecer en una versión LTS. Ese consejo resume todo el argumento en una 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é problemas causan.

El mismo patrón aparece de formas más pequeñas 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 precisamente la función de una versión intermedia. Por eso, leer las notas de la versión antes de cada una de esas diez actualizaciones forma parte del coste que aceptó asumir.

Elegir la variante al preparar el servidor

Elija la variante durante la instalación, porque cambiarla después requiere reinstalar el sistema o encadenar varias actualizaciones. En un servidor nuevo, cuatro comandos indican la situación actual:

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

lsb_release -a debe mostrar el nombre de la versión que quería instalar, y en una versión LTS la línea de descripción termina con LTS. La línea Prompt debe coincidir con la variante que eligió, no con la que incluyera la imagen del proveedor. En una LTS actual, do-release-upgrade -c debe devolver No new release found.. Si ofrece una versión intermedia en su lugar, Prompt está establecido en normal y alguien debe decidir si fue intencionado. pro security-status informa de cuántos paquetes instalados están cubiertos por cada flujo de actualizaciones y señala claramente cuándo el equipo no está asociado a una suscripción.

Después, anote la fecha de fin de vida en un lugar donde vuelva a verla, junto con el resto de las notas de preparación de ese servidor. Esto forma parte del trabajo de los primeros diez minutos en un VPS nuevo, porque una fecha de soporte que sólo existe 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 toda una flota con una de las dos opciones.

FAQ

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

En casi todos los casos, no. Una versión intermedia 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 permanente. Las excepciones reales son los equipos que se reconstruyen siempre a partir de una imagen, como los ejecutores de CI y los hosts de compilación. En esos casos, una actualización crea una instancia nueva en lugar de abrir una ventana de mantenimiento. Si hay usuarios reales que dependen del equipo, instale la LTS y use esas ventanas de mantenimiento ahorradas para otra tarea.

¿Durante cuánto tiempo recibe soporte una versión intermedia 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 intermedias siguen este ciclo: se publican en abril o en octubre y terminan 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 un máximo de cinco equipos.

¿Puedo omitir versiones de Ubuntu al actualizar?

No. do-release-upgrade avanza de una versión cada vez: una versión intermedia 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 el equipo. Canonical crea y prueba una transición cada vez, y el actualizador descarga una herramienta específica para ese salto. Por tanto, no existe una 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 se trasladan a old-releases.ubuntu.com. Por eso, sudo apt update empieza a fallar contra archive.ubuntu.com con errores 404, y no se publican nuevas actualizaciones de seguridad para esa versión. El equipo no muestra ningún aviso sobre esto. El servidor sigue funcionando y atendiendo tráfico mientras cada vulnerabilidad nueva que se publica permanece abierta. La recuperación consiste en ejecutar una actualización de versión bajo presión o reconstruir el equipo. Por tanto, supervise la fecha en lugar de esperar a que aparezcan los síntomas.

¿El kernel de la LTS es demasiado antiguo para 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 en la LTS kernels de versiones posteriores mediante las point releases. Una instalación de servidor puede activarla 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 problema. Si lo que falta es una versión de userspace y no del kernel, un contenedor o un repositorio del proveedor supone un cambio mucho menor que trasladar todo el equipo al ciclo de versiones intermedias.