Ubuntu 26.04 elimina cgroup v1 y obliga a revisar scripts antes de actualizar

Ubuntu 26.04 LTS, con nombre en clave Resolute Raccoon, introduce cambios de base que pueden afectar a servidores, contenedores y automatizaciones heredadas. El abandono definitivo de cgroup v1 es el riesgo más claro, mientras que la adopción de sudo-rs y las utilidades GNU reescritas en Rust exige revisar configuraciones, integraciones de auditoría y scripts que dependan de comportamientos muy concretos. Sin embargo, parte de estas novedades ya debutó en Ubuntu 25.10, por lo que no todas son rupturas exclusivas de esta versión LTS.

Las claves de Ubuntu 26.04 LTS en 20 segundos

• Ubuntu 26.04 elimina el soporte para cgroup v1 y utiliza exclusivamente cgroup v2.
• sudo-rs y rust-coreutils ya eran predeterminados desde Ubuntu 25.10.
• El sudo clásico y las utilidades GNU continúan disponibles como alternativa.
• Scripts, contenedores antiguos e integraciones LDAP o de auditoría requieren pruebas.
• El escritorio depende de Wayland, sin una sesión completa de Ubuntu sobre Xorg.

La actualización no debe entenderse como una decisión de Canonical de romper sistemas de forma arbitraria. Responde a una limpieza de tecnologías antiguas, a la incorporación de componentes con mayor seguridad de memoria y a cambios que ya se venían preparando en versiones anteriores. Aun así, el impacto puede ser importante en infraestructuras que llevan años funcionando sin revisar sus dependencias.

Ubuntu 26.04 fue publicada el 23 de abril de 2026 y tendrá cinco años de mantenimiento estándar, hasta abril de 2031. Las organizaciones que adopten Ubuntu Pro podrán ampliar ese periodo, de modo que las decisiones técnicas de esta LTS condicionarán servidores y puestos de trabajo durante muchos años.

cgroup v1 desaparece y puede bloquear la actualización

El cambio más relevante para administradores de sistemas es la eliminación de cgroup v1, incluida la configuración híbrida que combinaba las dos generaciones del sistema.

Los grupos de control, o cgroups, permiten al kernel de Linux organizar procesos y limitar recursos como CPU, memoria y entrada o salida. Son esenciales para systemd, Docker, Kubernetes, LXC y muchas plataformas de contenedores.

Ubuntu 26.04 incorpora systemd 259. Esta versión hereda la decisión tomada por systemd 258 de eliminar las jerarquías legacy e hybrid, por lo que el sistema utiliza siempre cgroup v2. La documentación de Ubuntu advierte además de que el actualizador comprobará la configuración y no permitirá continuar desde Ubuntu 24.04 si detecta que el equipo depende de cgroup v1.

Esta comprobación previa evita que el servidor termine actualizado pero sin capacidad para arrancar correctamente sus cargas. El inconveniente es que obliga a resolver la migración antes de iniciar el proceso.

Los sistemas con más riesgo son aquellos que utilizan:

• versiones antiguas de Docker o containerd;
• clústeres Kubernetes configurados antes de la adopción general de cgroup v2;
• contenedores LXC con montajes específicos de cgroup v1;
• parámetros del kernel que fuerzan la jerarquía heredada;
• software propio que accede directamente a rutas de /sys/fs/cgroup.

Para comprobar la versión activa resulta más fiable consultar el tipo de sistema de archivos montado:

stat -fc %T /sys/fs/cgroup

Si la respuesta es cgroup2fs, el sistema utiliza cgroup v2. También puede revisarse mediante:

mount | grep cgroup

Consultar únicamente /proc/cgroups no basta para determinar qué jerarquía se está utilizando, ya que ese archivo muestra los controladores soportados por el kernel, no necesariamente el modo activo.

La migración puede ser sencilla en un servidor actualizado, pero exige más trabajo en un clúster. No basta con cambiar el arranque del sistema: es necesario validar el runtime de contenedores, el kubelet, las políticas de recursos, la monitorización y cualquier agente que lea métricas desde la jerarquía antigua.

sudo-rs sustituye al sudo tradicional, pero existe una vía de retorno

Ubuntu utiliza ahora sudo-rs como proveedor predeterminado del comando sudo. Se trata de una reescritura en Rust desarrollada por Trifecta Tech Foundation con el objetivo de reducir la exposición a vulnerabilidades de seguridad de memoria.

No es, en realidad, una novedad estrenada por Ubuntu 26.04. Canonical ya adoptó sudo-rs como opción predeterminada en Ubuntu 25.10. La versión incluida en Resolute Raccoon se basa en sudo-rs 0.2.13 con correcciones adicionales.

Para el usuario habitual la transición debería resultar casi invisible. El comando mantiene el mismo nombre, trabaja con /etc/sudoers y admite funciones comunes como NOPASSWD, sudoedit, perfiles de AppArmor y autenticación mediante PAM.

Sí existe una diferencia visible: pwfeedback está habilitado de forma predeterminada, por lo que aparecen asteriscos mientras se escribe la contraseña. Puede desactivarse en la configuración:

Defaults !pwfeedback

Las diferencias importantes aparecen en entornos empresariales. El proyecto reconoce que todavía ofrece menos funciones que el sudo original. No admite, entre otras capacidades, el almacenamiento de reglas mediante sudoers.ldap, algunos plugins, INTERCEPT, el parámetro logfile ni todas las variantes de timestamp_type. También fuerza determinados comportamientos relacionados con PAM y las variables de entorno.

Esto puede afectar a organizaciones con:

• reglas de autorización almacenadas en LDAP;
• plugins propios para sudo;
• grabación o análisis avanzado de sesiones;
• herramientas que esperan formatos de log concretos;
• políticas que dependen de opciones poco habituales de sudoers;
• scripts que utilizan argumentos todavía no implementados.

Canonical no ha eliminado completamente la implementación histórica. El sudo desarrollado por Todd C. Miller permanece disponible con los binarios terminados en .ws, y el administrador puede cambiar el proveedor mediante:

sudo update-alternatives --config sudo

Por tanto, no existe una ausencia total de alternativa. La cuestión es que nuevas instalaciones, imágenes cloud y sistemas actualizados utilizarán sudo-rs salvo que el administrador decida lo contrario.

Rust coreutils puede descubrir supuestos ocultos en los scripts

Ubuntu también utiliza por defecto uutils coreutils, una reimplementación en Rust de herramientas tan habituales como ls, cp, mv, cat, date, sort, head o tail.

Este cambio tampoco nació en Ubuntu 26.04. Las utilidades Rust pasaron a ser predeterminadas en Ubuntu 25.10, mientras Canonical mantuvo las versiones GNU instalables en paralelo debido a que la compatibilidad todavía no era completa.

Para un uso interactivo normal las diferencias suelen ser pequeñas. El mayor riesgo aparece en automatizaciones que no utilizan estos comandos como herramientas, sino como interfaces de datos cuya salida debe tener un formato exacto.

Un script puede fallar si depende de:

• espacios o columnas concretas en la salida de ls;
• formatos particulares de date;
• ordenaciones condicionadas por la configuración regional;
• mensajes de error exactos;
• códigos de salida en casos límite;
• opciones poco utilizadas de cp, stat, sort o tail;
• comportamiento no documentado de GNU coreutils.

La recomendación habitual de no analizar la salida de ls adquiere aquí todavía más sentido. Para trabajar con archivos es preferible utilizar find, globbing del shell, salidas delimitadas por caracteres nulos o APIs propias del lenguaje empleado.

Que uutils supere la mayoría de las pruebas de compatibilidad de GNU no garantiza que cada script existente se comporte igual. Las suites incluyen miles de casos y las divergencias suelen concentrarse precisamente en opciones avanzadas, locales, errores y combinaciones poco frecuentes.

Canonical mantiene las utilidades GNU como alternativa. Esto reduce el riesgo inmediato, pero no elimina la necesidad de probar las automatizaciones porque los binarios predeterminados del sistema son los escritos en Rust.

Un método práctico consiste en ejecutar la misma batería de pruebas sobre Ubuntu 24.04 y 26.04, guardar las salidas y compararlas. Deben incluirse tanto los resultados correctos como los mensajes de error, códigos de retorno y comportamiento con nombres de archivo poco habituales.

APT, Xorg y los servicios SysV también requieren atención

El texto original atribuye a Ubuntu 26.04 otros cambios que, en algunos casos, se produjeron antes.

La desaparición de apt-key lleva años preparándose. Las configuraciones modernas deben utilizar repositorios con una clave específica mediante la opción Signed-By, preferiblemente en archivos con formato Deb822 dentro de /etc/apt/sources.list.d/.

Un ejemplo sería:

Types: deb
URIs: https://packages.example.com/ubuntu
Suites: resolute
Components: main
Signed-By: /etc/apt/keyrings/example.gpgLenguaje del código: HTTP (http)

Asociar cada repositorio con su propia clave limita el alcance de confianza. El antiguo almacén global permitía que una clave añadida para un proveedor validara paquetes procedentes de otros repositorios configurados en el equipo.

En el escritorio, Ubuntu ya había retirado la sesión completa sobre Xorg en la versión 25.10. Las aplicaciones X11 todavía pueden ejecutarse mediante XWayland, pero el usuario no dispone de la opción tradicional “Ubuntu on Xorg” en el inicio de sesión.

Ubuntu 26.04 incorpora además systemd 259 y será la última versión que mantenga compatibilidad con scripts de inicio System V. Esto no significa que dejen de funcionar inmediatamente en Resolute Raccoon, pero sí convierte su migración a unidades nativas de systemd en una tarea necesaria antes de la siguiente LTS.

Para los equipos con GPU NVIDIA, la eliminación de la sesión Xorg no implica automáticamente que Wayland sea inutilizable. Los controladores propietarios han mejorado su soporte durante los últimos ciclos, aunque las estaciones con aplicaciones gráficas especializadas, escritorios remotos o configuraciones multimonitor complejas deberían validarse antes de migrar.

Qué revisar antes de actualizar desde Ubuntu 24.04

Una actualización LTS no debería comenzar directamente en producción. El primer paso es inventariar qué elementos dependen del comportamiento antiguo.

En servidores y plataformas cloud conviene revisar:

stat -fc %T /sys/fs/cgroup
systemd --version
docker info | grep -i cgroup
grep -R "apt-key" /etc /usr/local /opt 2>/dev/null
grep -R "sudoers.ldap\|INTERCEPT\|logfile" /etc/sudoers /etc/sudoers.d 2>/dev/nullLenguaje del código: JavaScript (javascript)

También resulta útil localizar scripts que analicen salidas de comandos:

grep -R -E "ls .*\|.*(awk|cut|sed)|date .*\+|sort " \
    /usr/local/bin /opt /etc/cron* 2>/dev/nullLenguaje del código: JavaScript (javascript)

La presencia de una coincidencia no significa que el código sea incompatible. Sirve para construir una lista inicial de elementos que requieren pruebas.

En un proceso ordenado deberían completarse cuatro fases:

1. Inventario: localizar cgroup v1, scripts SysV, repositorios antiguos, plugins de sudo y automatizaciones sensibles a coreutils.
2. Migración previa: pasar contenedores a cgroup v2, sustituir apt-key y convertir servicios heredados.
3. Pruebas: ejecutar aplicaciones, pipelines, copias de seguridad, monitorización y tareas programadas sobre Ubuntu 26.04.
4. Despliegue gradual: actualizar primero sistemas no críticos y mantener una ventana suficiente para detectar errores.

También conviene preparar un procedimiento de reversión. En una actualización de distribución, restaurar una instantánea o reconstruir el servidor suele ser más seguro que intentar degradar paquetes individualmente.

Ubuntu 26.04 no rompe toda la compatibilidad ni elimina cualquier ruta de retorno. sudo y GNU coreutils siguen disponibles, y algunas de las transiciones comenzaron en 25.10. Pero la eliminación de cgroup v1 sí establece una frontera clara: las configuraciones heredadas deben migrar antes de pasar a la nueva LTS.

Preguntas frecuentes

¿Ubuntu 26.04 bloquea la actualización si utiliza cgroup v1?

Sí. La documentación de Ubuntu indica que el actualizador comprueba la jerarquía de cgroups y bloquea el proceso cuando detecta una configuración incompatible con cgroup v2.

¿Se puede seguir utilizando el sudo original?

Sí. Ubuntu conserva la implementación tradicional como sudo.ws y permite seleccionar el proveedor mediante update-alternatives.

¿GNU coreutils ha desaparecido de Ubuntu?

No. Las herramientas escritas en Rust son las predeterminadas, pero GNU coreutils continúa disponible para sistemas que necesiten su comportamiento.

¿Las aplicaciones X11 dejan de funcionar?

No necesariamente. Pueden seguir ejecutándose mediante XWayland, aunque Ubuntu ya no ofrece una sesión completa de escritorio basada en Xorg.