Hay cambios en una distribución que pasan sin pena ni gloria y otros que pueden dejarte mirando una pantalla negra tras reiniciar. El que Canonical ha metido en Ubuntu 26.10 se parece más a los segundos, aunque con una condición importante: afecta al arranque con Secure Boot activado. En ese escenario, la versión firmada de GRUB ya no sabe leer Btrfs, XFS ni ZFS, de modo que si tu directorio /boot vive en alguno de ellos, el gestor de arranque no encuentra el kernel y Ubuntu simplemente no arranca. Antes de que cunda el pánico conviene mirar con calma a quién afecta de verdad, porque la respuesta es bastante menos dramática que el titular.
Qué elimina Ubuntu 26.10 del GRUB con Secure Boot activado
Empecemos por el matiz que lo cambia todo: Ubuntu mantiene dos comportamientos distintos según el estado de Secure Boot. La versión recortada solo se usa cuando esa protección está activa, y es la que ha perdido soporte para Btrfs, XFS, ZFS, LVM, el cifrado LUKS y el RAID por software, con la excepción del RAID1. La lista de bajas continúa con HFS+, las tablas de particiones de Apple y la carga de imágenes JPEG y PNG, que importa sobre todo a quien personaliza el menú de arranque con fondos. Lo que sigue en pie es lo básico: ext4, FAT, ISO9660, el formato de los CD y DVD, y squashfs, imprescindible para los snaps. La razón por la que esto es tan binario es sencilla. GRUB necesita leer /boot para localizar y cargar el kernel, así que si esos archivos están en un sistema de ficheros que ya no entiende, se acabó la conversación. Con Secure Boot desactivado, en cambio, se carga el GRUB completo y todo funciona como siempre, incluidas las configuraciones más exóticas y los ajustes de personalización.
Que Btrfs y ZFS aparezcan en la lista puede sorprender, porque son sistemas muy ligados a quienes les gusta trastear con instantáneas y configuraciones avanzadas. Y justo ahí está el riesgo real: quien instala Ubuntu sin tocar nada ni se enterará de que esto ha pasado, pero quien ha montado su propio esquema de particiones sí debería tenerlo en el radar.
Por qué menos analizadores en el arranque es un arranque más seguro
Para entender el movimiento hay que mirar la cadena de arranque. Con Secure Boot, el firmware del equipo carga primero un programa llamado shim, que verifica y carga GRUB. Después GRUB recurre a una serie de analizadores, es decir, pequeños módulos de código que interpretan sistemas de archivos y esquemas de particiones para llegar hasta el kernel. Cada uno de ellos es código que se ejecuta antes de que el sistema operativo tenga nada que decir, y varios han acabado siendo la grieta por la que se saltaba Secure Boot en los últimos años. Según recoge la fuente, además, los modelos de lenguaje están acelerando tanto el hallazgo de fallos como su posible explotación, lo que no ayuda a la hora de mantener una lista larga de analizadores. La lógica de Canonical es difícil de rebatir sobre el papel: el código que no se ejecuta no se puede explotar. Menos analizadores antes del kernel son menos oportunidades de romper la cadena de confianza que garantiza que lo que arranca es lo que debe arrancar. Otra cosa es cómo se ha recibido. Canonical adelantó el plan a principios de este año y la reacción fue, por decirlo suavemente, incómoda, sobre todo entre quienes tienen configuraciones de arranque a medida, algunas montadas con funciones experimentales del propio instalador. De ahí que el cambio llegue justo después de una versión LTS: quien necesite Secure Boot y el GRUB completo puede quedarse en Ubuntu 26.04 LTS, con soporte hasta 2036 mediante Ubuntu Pro o hasta 2041 si se suma el complemento Legacy.
Cómo comprobar si tu /boot está en un sistema de archivos que ya no arranca
La buena noticia es que la mayoría de usuarios no notará nada. El instalador estándar de Ubuntu deja todo en una disposición convencional, pensada para ser segura y amigable, y el cambio solo toca a la ruta de arranque en sí. Es decir, LVM, LUKS, RAID, Btrfs y ZFS siguen estando disponibles en Ubuntu 26.10 con Secure Boot activado, solo que el propio proceso de arranque ya no puede depender de ellos. Una vez que el sistema ha arrancado, puedes usarlos con normalidad. Si tu configuración es poco habitual, tiene sentido revisar antes de actualizar. Un findmnt -T /boot te dice en qué sistema de archivos está el directorio, y mokutil --sb-state te indica si Secure Boot está activado. Si el primero devuelve algo fuera de la lista de soportados y el segundo confirma que está activo, estás en la franja de riesgo. Entonces tienes tres salidas razonables: plantearte un /boot en ext4, mantener Secure Boot desactivado o quedarte en la 26.04 LTS. Lo importante es decidirlo antes de actualizar y no después de ver que el equipo no arranca.
Lo curioso de este recorte es lo que cuenta del propio arranque, esa fase en la que un sistema es más vulnerable y menos capaz de defenderse. Durante años se valoró que GRUB entendiera de todo, que cualquier disco, cualquier capa de cifrado y cualquier rareza pudiera levantar un Linux. Ahora la prioridad se invierte y el gestor pasa de ser una navaja suiza a un portero que solo conoce unas pocas caras. Queda por ver si esa estrechez se queda en Ubuntu como excepción justificada o se contagia a otras distribuciones, y si la libertad de arrancar desde donde uno quiera era, en el fondo, un lujo que la seguridad ya no se puede permitir.
Fuente: OMGUbuntu
Añadir comentario
Comentarios