El 27 de agosto de 2026 Canonical publicó Ubuntu 26.04.1 LTS "Resolute Raccoon", el primer point release de la LTS que había salido en abril. Para quien maneja servidores, la fecha no es un detalle de calendario: es el momento en que el sistema deja de ofrecerte quedarte en 24.04 y empieza a proponerte el salto. Hasta ayer, actualizar era forzar la mano; desde hoy, es la ruta soportada. Vale la pena entender por qué el diseño funciona así y qué te vas a encontrar del otro lado.
Ubuntu 26.04.1 LTS "Resolute Raccoon" es el primer point release de la versión LTS de Ubuntu lanzada en abril de 2026, publicado por Canonical el 27 de agosto de 2026. Para administradores de servidores importa porque es la versión que habilita el upgrade automático LTS→LTS desde 24.04 vía do-release-upgrade. Trae el kernel Linux 7.0, systemd 259, Python 3.14 y, por defecto, sudo-rs y las coreutils reescritas en Rust.
¿Por qué el salto desde 24.04 se habilita recién con la 26.04.1?
Porque Canonical retiene a propósito la ruta de upgrade LTS→LTS hasta el primer point release. Un usuario de 24.04 no recibe el aviso de do-release-upgrade cuando sale la 26.04 en abril: lo recibe con la 26.04.1. La idea es dar unos meses de rodaje para que la .1 acumule los parches de estabilidad, las correcciones de instalador y los backports que no llegaron al día del lanzamiento.
Esto es política deliberada, no una casualidad. Según el schedule oficial de la versión, la 26.04.1 estaba agendada para esta semana de agosto. Hasta antes de la .1, la única forma de saltar desde 24.04 era pasarle el flag de desarrollo (do-release-upgrade -d), que funciona pero te mete en una versión que todavía no completó su ciclo de estabilización. Si venías esperando para actualizar servidores de producción, esta es la señal que estabas esperando.
¿Qué cambia a nivel de kernel y systemd en Ubuntu 26.04 LTS?
Es el salto de plataforma más grande en años: el kernel pasa de la serie 6.8 de 24.04 a Linux 7.0, y systemd sube de la 255 a la 259. De acuerdo con el anuncio de Canonical, la 26.04 "se construye sobre Linux 7.0, continuando el compromiso de enviar los kernels upstream más recientes al momento del lanzamiento". No es un bump cosmético; arrastra cambios que tocan cómo corren tus contenedores y tus servicios.
- cgroup v1 quedó afuera. Según las notas de la versión, se removió el soporte para la jerarquía
legacyehybridde cgroups. Si tenés runtimes de contenedores viejos o configuraciones que todavía dependen de cgroup v1, revisalos antes de actualizar. - Es la última release con compatibilidad System V. Las notas avisan que 26.04 LTS es la última que soporta los scripts de servicio SysV. Si arrastrás init scripts legacy, este es el momento de migrarlos a units de systemd.
- Python salta a 3.14. Desde 3.12. Tus virtualenvs y scripts del sistema que asumen una versión concreta pueden necesitar ajuste.
- Livepatch llega a Arm64. El parcheo de kernel sin reboot se extiende por primera vez a servidores Arm64, según Canonical.
¿Es cierto que sudo y ls ahora corren en Rust? ¿Se rompe algo?
Sí: en 26.04 el sudo por defecto es sudo-rs, una reimplementación en Rust, y varias coreutils (ls, cp, mv y compañía) pasan a la implementación de uutils. El objetivo es memory safety: eliminar clases enteras de bugs de corrupción de memoria en utilidades que corren con privilegios.
Sobre el sudo, las notas de la versión son explícitas: "la herramienta sudo (la original mantenida por Todd C. Miller) fue renombrada a sudo.ws". Es decir, el binario clásico sigue disponible con otro nombre por si necesitás volver a él.
La pregunta importante para producción es la compatibilidad. Las notas para usuarios LTS lo dicen sin vueltas: "como las rust-coreutils todavía no son totalmente compatibles, seguimos proveyendo también las utilidades GNU clásicas". En la práctica: si un script tuyo depende de un flag o de un comportamiento específico de GNU coreutils que la versión Rust todavía no replica, tenés las GNU accesibles con el prefijo gnu. La recomendación es probar tus scripts de automatización en un entorno de staging antes de tocar el servidor real.
¿Qué otros cambios de servidor te pueden morder al actualizar?
Los que rompen silenciosamente son los cambios de defaults y las remociones, no las features nuevas. Estos son los que conviene tener en el radar antes de correr el upgrade:
apt-keyfue eliminado por completo. Si tu provisioning todavía usaapt-key addpara claves de repos de terceros, va a fallar. Migrá a claves en/etc/apt/keyrings/referenciadas consigned-by.- SSSD ya no corre como root. Ahora corre como usuario
sssd. Si tenés permisos o hooks que asumían el usuarioroot, revisalos. - Postfix deja de instalarse en chroot por defecto. Un cambio de default que afecta rutas y permisos si administrás correo en el server.
- OpenSSL suma criptografía post-cuántica y QUIC. Incluye ML-KEM, ML-DSA y SLH-DSA. No rompe nada, pero abre la puerta a endurecer TLS de cara a la era post-cuántica.
- Cifrado de disco respaldado por TPM, ya general. El instalador ofrece full-disk encryption atado al chip TPM, lo que sube el listón frente a ataques de acceso físico al hardware.
authdpara identidad en la nube. Un servicio de autenticación open source que integra proveedores OIDC estándar, disponible desde los repos oficiales.
¿Cómo actualizar de 24.04 a 26.04 sin sorpresas?
El camino soportado ahora que salió la .1 es sudo do-release-upgrade, pero recién después de dejar tu 24.04 completamente al día y con un respaldo real. Una actualización LTS→LTS reemplaza cientos de paquetes y toca el kernel: no es reversible con un simple downgrade. El orden que conviene:
- Snapshot o backup completo primero. Si tu servidor corre como VM, sacá un snapshot; si es bare metal, respaldá datos y configs. Esta es tu única red de contención real.
- Actualizá 24.04 a fondo. Corré
sudo apt update && sudo apt full-upgradey reiniciá antes de empezar. El upgrade parte de un sistema limpio y parcheado. - Auditá tus dependencias frágiles. Init scripts SysV, uso de
apt-key, runtimes atados a cgroup v1, scripts que dependen de flags de GNUcoreutils. Corregilos en 24.04 antes del salto. - Corré
sudo do-release-upgrade. Sobre una sesión estable (idealmente por consola otmux, no por una SSH que se pueda cortar), y leé cada prompt de conflicto de configuración en vez de aceptar a ciegas. - Validá servicios post-reboot. Revisá
systemctl --failed, tus servicios críticos, el correo y la autenticación antes de dar el server por migrado.
Si administrás varios servidores, la jugada sensata es actualizar uno de staging primero, documentar qué rompió, y recién después ir a producción. La 26.04 tiene 5 años de soporte estándar, así que no hay apuro: mejor un salto ordenado que un rollback de madrugada.
Preguntas frecuentes
¿Cuándo salió Ubuntu 26.04.1 LTS?
El 27 de agosto de 2026, según el schedule oficial de la versión. La 26.04 inicial había salido el 23 de abril de 2026; la .1 es el primer point release, que acumula parches de estabilidad y correcciones del instalador.
¿Por qué mi 24.04 no me ofrecía actualizar hasta ahora?
Porque Canonical retiene la ruta de upgrade LTS→LTS hasta el primer point release. Antes de la 26.04.1, do-release-upgrade no ofrecía el salto salvo que lo forzaras con el flag de desarrollo (-d), que te llevaba a una versión aún no estabilizada del todo.
¿Qué versión de kernel trae Ubuntu 26.04 LTS?
Linux 7.0, según el anuncio de Canonical, frente a la serie 6.8 de 24.04. Es un salto de versión mayor que arrastra cambios de subsistemas, además de la remoción del soporte de cgroup v1.
¿El sudo-rs en Rust puede romper mis scripts?
Puede, si dependen de comportamientos muy específicos. sudo-rs es el sudo por defecto y el clásico quedó renombrado como sudo.ws. Para las coreutils, las GNU siguen disponibles con el prefijo gnu porque las versiones Rust todavía no son 100% compatibles. Probá tu automatización en staging.
¿Conviene actualizar servidores de producción hoy mismo?
No hay que apurarse. Que la ruta esté habilitada no obliga a saltar ya: 24.04 sigue con soporte por años. Lo prudente es actualizar primero un servidor de staging, validar tus servicios contra los cambios de defaults (apt-key, cgroup v1, SysV) y recién después ir a producción con backup previo.
Si venís de otra distro y estás repensando tu base LTS por estas semanas, tené presente que no es el único vencimiento en agenda: en otra nota del blog cubrimos el fin de LTS de Debian 11 el 31 de agosto de 2026 y las opciones que quedan. Fuente oficial del anuncio: el post de release en el Ubuntu Community Hub y las notas de la versión 26.04 LTS.
Cloud Serversby Donweb
Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.
- Performance que te sorprenderá
- Rápida escalabilidad y sin limitaciones
- Arquitectura de alta disponibilidad
- Soporte experto y ejecutivos de cuenta
- Pagos en tu moneda y facturación local
