Ubuntu 26.04 LTS Resolute Raccoon: qué cambia en tu servidor y cuándo migrar (o no)

Lo importante en una frase

Ubuntu 26.04 LTS "Resolute Raccoon" salió el 23 de abril de 2026. Trae kernel Linux 7.0, systemd 259, soporte oficial hasta abril de 2031 y, si activas Ubuntu Pro, hasta abril de 2036. Es la base que usaremos en los servidores nuevos durante los próximos cinco años, así que merece la pena entender qué cambia antes de pulsar do-release-upgrade.

Qué te traes de nuevo si vienes de 24.04

Las versiones que vienen en el repositorio oficial de la 26.04 son las siguientes. Las he comprobado en packages.ubuntu.com/resolute/:

Tres cosas tienen impacto real en operaciones:

• Kernel 7.0 (publicado el 12 de abril, once días antes que Ubuntu). Aporta mejoras en io_uring, gestión de memoria y soporte hardware más reciente (Intel Xe3, NPUs, redes 200/400 GbE). Para la mayoría de servidores web no notarás diferencia, pero si trabajas con I/O intenso (bases de datos grandes, colas) sí.
• systemd 259. La novedad más relevante: el soporte de cgroup v1 está fuera (se eliminó en systemd 258). Si tu servidor depende de configuraciones antiguas que aún usan la "legacy hierarchy", revisa la sección de "Lo que rompe" más abajo.
• OpenSSH 10. Cambios en algoritmos por defecto, eliminación definitiva de DSA, refuerzo de la post-quantum key exchange. Si tienes clientes muy viejos conectándose por SSH, valida antes.

Canonical también ha integrado de serie soporte para NVIDIA CUDA y AMD ROCm, NVIDIA DOCA-OFED y TPM-backed full-disk encryption, además de Livepatch para servidores ARM. Si tu cliente es un VPS modesto, te dará igual; si gestionas servidores con GPU para IA, es una mejora gorda.

Lo que rompe (y a quién afecta)

Migrar una LTS de Ubuntu nunca es "le doy a actualizar y a otra cosa". Estos son los puntos donde solemos ver fricción real:

1. cgroup v1 fuera → Docker antiguo y LXC mal configurado

systemd 259 ya no monta la jerarquía legacy de cgroups. Esto afecta a:

• Docker anterior a 20.10 (julio 2020). En la práctica, cualquier instalación que lleve años sin actualizar el daemon.
• LXC/LXD muy antiguos configurados con lxc.cgroup.* en lugar de lxc.cgroup2.*.
• Scripts personalizados que escriben en /sys/fs/cgroup/memory/, /sys/fs/cgroup/cpu/, etc. (paths de v1) en lugar de /sys/fs/cgroup/<unit> (path unificado de v2).

Si no estás seguro, en el servidor actual:

mount | grep cgroup
# Si ves "cgroup2 on /sys/fs/cgroup", ya estás en v2.
# Si ves muchas líneas con "cgroup on /sys/fs/cgroup/...", sigues en v1.

Hay una vía de escape temporal (SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 en la línea de comando del kernel), pero es una solución para salir del paso, no para quedarse.

2. Python 3.14 por defecto

Python 3.14 trae cambios reales: el GIL opcional (modo "no-GIL" experimental), mejoras de rendimiento del intérprete y deprecaciones que ya tocaba retirar. Si tu aplicación arrastra dependencias atascadas en Python 3.10 u 11, vas a tener que probarla bien antes de actualizar.

3. OpenSSL 3.5 y OpenSSH 10

Cualquier librería compilada contra OpenSSL 1.1 lleva años sin soporte, pero a veces aparece. OpenSSH 10 también ha endurecido los algoritmos por defecto: si dependes de máquinas muy viejas conectándose, comprueba antes que sus clientes negocian algo aceptable en 2026.

4. Paquetes legacy retirados

Cada LTS deja por el camino paquetes que ya no se mantienen. Lo más práctico es ejecutar do-release-upgrade -d en una copia del servidor y leer el resumen de "obsolete packages" antes de hacerlo en producción.

Cuándo migrar ya

• Tu servidor está en 22.04 LTS y se acerca al final del soporte estándar (abril 2027). Saltar a 26.04 te da otros 5 años de tranquilidad sin pasar por 24.04.
• Vas a estrenar VPS o reinstalar uno comprometido. No hay razón para empezar con 24.04 a estas alturas.
• Necesitas hardware reciente (GPUs nuevas, NPUs, redes 200 GbE) que en versiones anteriores requiere repos externos.
• Quieres aprovechar el Pro hasta 2036 desde el principio del ciclo, no a mitad.
• Te interesan las mejoras de io_uring y memoria del kernel 7.0 para bases de datos exigentes.

Cuándo esperar

• Tu proyecto está congelado en producción y solo recibe parches críticos. Si la 24.04 te aguanta hasta 2029, no hay urgencia.
• Tienes Docker antiguo (< 20.10) o scripts dependientes de cgroup v1 y no puedes refactorizarlos a corto plazo.
• Tu aplicación arrastra dependencias bloqueadas en Python 3.11 o anterior sin alternativa actualizada.
• Confías en PPAs de terceros que aún no han publicado paquetes para 26.04. Los grandes (Ondrej PHP, MariaDB oficial, Postgres APT) suelen tardar unas semanas en estar disponibles.
• El servidor factura todos los días y prefieres esperar a la 26.04.1 (suele salir en julio/agosto y resuelve los flecos de la X.04 inicial).

Si dudas, espera al 26.04.1. Ese punto suele marcar el momento en que el resto del ecosistema (Docker oficial, Nginx PPA, PHP-FPM PPAs) ya está listo.

Checklist de migración sin sustos

Este es el procedimiento que aplicamos en Atenea cuando migramos un VPS de cliente a una nueva LTS. Funciona y se puede hacer en una jornada para un servidor estándar.

1. Inventario del servidor actual. dpkg -l, lista de servicios habilitados (systemctl list-unit-files --state=enabled), PPAs activos (ls /etc/apt/sources.list.d/), trabajos de cron, scripts en /usr/local/bin/.
2. Snapshot completo del VPS en el panel del proveedor antes de tocar nada. Esto es tu botón de "deshacer" si algo va mal.
3. Backup independiente (regla 3-2-1 — si te interesa, aquí va más en detalle). El snapshot del proveedor no cuenta como backup off-site.
4. Clonar el VPS en una máquina temporal y ejecutar ahí primero el do-release-upgrade. Es la única forma seria de saber qué se rompe antes de tocar producción.
5. Revisar journalctl -p err después del primer arranque en el clon. Cualquier servicio que escupa errores nuevos te lo va a hacer también en producción.
6. Validar los servicios críticos uno a uno: nginx/apache responden, PHP-FPM ejecuta una página, MariaDB acepta conexiones, OpenSSH negocia con tus claves habituales, certificados Let's Encrypt funcionan.
7. Revisar cgroup. mount | grep cgroup debe mostrar cgroup2. Si tu pila usa Docker, verificar que la versión instalada es ≥ 20.10.
8. Actualizar PPAs y repositorios externos a sus paquetes para resolute. Si alguno aún no tiene paquete, decidir si esperar o desactivarlo.
9. Ventana de mantenimiento anunciada al cliente. Migración real en producción con el método ya probado. Suele tardar 30-60 minutos en un VPS estándar.
10. Monitorización 24/48 horas después. La mayoría de problemas no aparecen en el arranque, sino la noche siguiente con el primer cron o el primer pico de tráfico.

Cómo comprobar si vas a 24.04 o a 26.04 (y por qué importa)

Por defecto, do-release-upgrade ofrece la última versión LTS estable, pero el comportamiento cambia entre versiones:

• Si estás en 22.04, te ofrecerá saltar a 24.04 primero. Para llegar a 26.04 tienes que pasar por la 24.04 o usar do-release-upgrade -d con la opción de desarrollo cuando 26.04 sea el target estable.
• Si estás en 24.04, podrás saltar directamente a 26.04 cuando Ubuntu marque el upgrade path como estable (normalmente con la 26.04.1).
• Si estás en una non-LTS (24.10, 25.04, 25.10), tendrás que ir actualizando linealmente.

No hay un atajo para saltar dos versiones LTS de una vez sin riesgo. Si te dicen lo contrario, desconfía.

Preguntas frecuentes

¿Es seguro hacer do-release-upgrade directamente en producción si todo va bien? Técnicamente sí; en la práctica, no recomendable. Cualquier proceso que dependa del servidor (clientes conectados, cron, colas, jobs largos) puede pillarse a mitad. Si la web es comercial, migra en una ventana anunciada, no de día.

¿Y si soy partidario de "esperar a la 26.04.1"? Es una postura perfectamente razonable. La 26.04.1 suele salir en julio/agosto y consolida los parches acumulados los tres primeros meses. Para servidores críticos donde no hay urgencia, esa espera es barata.

¿Ubuntu Pro hasta 2036 cuesta dinero? Es gratis para uso personal (hasta 5 máquinas) y de pago para empresas. Si gestionas servidores de producción para clientes, el coste por máquina compensa con creces el coste de un solo incidente de seguridad.

¿Me afecta lo del cgroup v1 si solo tengo nginx y PHP-FPM? Casi seguro que no. nginx, PHP-FPM, MariaDB, Postgres, Redis y todo el ecosistema típico de webs llevan años con cgroup v2 sin problemas. El riesgo está concentrado en Docker antiguo, contenedores LXC heredados y scripts personalizados que toquen /sys/fs/cgroup/ directamente.

¿Qué pasa con mi PPA favorito (Ondrej PHP, MariaDB oficial, etc.) si todavía no tiene paquete para 26.04? Lo habitual es que aparezca en semanas. Mientras tanto, dos opciones: usar los paquetes del repositorio oficial de Ubuntu (PHP 8.5 ya está, MariaDB 11.8 también) o esperar.

Conclusión

26.04 LTS no es una revolución, es una consolidación: kernel 7.0, systemd 259 sin lastre de cgroup v1, librerías criptográficas al día y soporte hasta 2036 con Pro. Para servidores nuevos, ya es la opción por defecto. Para servidores en producción, el camino sensato es: clonar, probar, validar, esperar a la 26.04.1 y migrar con ventana anunciada.

Si tienes un VPS en 20.04 o 22.04 que conviene migrar y prefieres no pelearte con el clon y la madrugada del corte, te lo hacemos sin downtime y con plan de marcha atrás claro. Cuéntanos qué tienes y te decimos por dónde empezar.