# Linux 7.4 arregla el arranque directo EFI y systemd lo agradece > El stub EFI del kernel ya rellena LoaderDevicePartUUID al arrancar sin GRUB, y systemd puede montar /home, /var y la swap sin tocar el fstab. > Por José Maldonado · Tecnología · 2026-10-28 Arrancar Linux directamente desde el firmware, sin GRUB ni systemd-boot por medio, es una decisión más frecuente de lo que sugiere el escritorio: placas con coreboot, equipos embebidos y máquinas virtuales que se saltan el gestor de arranque. Hasta esta semana, ese atajo tenía un coste silencioso, porque las particiones que systemd montaba solas dejaban de aparecer. Los cambios de Linux 7.4 EFI, integrados este lunes 26 de octubre en la ventana de fusión, resuelven ese hueco con una variable de firmware que el stub del kernel empieza a escribir por su cuenta. Se llama LoaderDevicePartUUID y guarda el identificador de la partición desde la que se lanzó el sistema. Vincent Mailhol firma la serie, que entra en 7.4 dentro del soporte del Boot Loader Interface (BLI), el estándar con el que [systemd define qué debe contar un gestor de arranque](https://systemd.io/BOOT_LOADER_INTERFACE/). La consecuencia práctica es pequeña en líneas y grande en fricción diaria: quien arranca así recupera el automontaje de /home, /var, /srv y la swap que describe la Discoverable Partitions Specification, una idea que systemd arrastra desde la versión 211, de marzo de 2014. Doce años después, el eslabón que faltaba no estaba en el espacio de usuario sino en el propio kernel. systemd no cambia ni una línea, porque llevaba una década leyendo un dato que casi nadie escribía. ## El hueco que dejaba el arranque directo Cuando el firmware EFI carga la imagen del kernel, el stub asume el trabajo del gestor de arranque: reserva memoria, ordena los parámetros y salta al código compilado. Lo que no hacía era dejar constancia de la partición desde la que se lanzó. GRUB y systemd-boot sí lo publican desde hace años en la variable del BLI que consulta el resto del sistema. Esa información es la que permite a systemd-gpt-auto-generator identificar el disco de arranque y deducir qué hay en cada partición, sin tocar /etc/fstab ni añadir root= a la línea de comandos. En un equipo con gestor de arranque el fallo no se nota nunca. En una placa con coreboot y edk2 como carga útil, o en una imagen que arranca el kernel a pelo, el síntoma aparece a los pocos segundos: /home existe, está formateada y se queda vacía porque nadie le dijo al sistema dónde buscarla. El arranque directo tampoco es una rareza de laboratorio. Las imágenes de disco que se montan con systemd-nspawn, o que se inspeccionan desde un contenedor, se leen con la misma especificación de particiones, de modo que el dato que ahora escribe el stub también ayuda a mover una instalación entre una máquina física y un contenedor sin retocar el reparto. ## La variable que systemd ya sabía leer El trabajo de Linux 7.4 EFI no inventa nada: rellena un hueco que la especificación llevaba años describiendo. LoaderDevicePartUUID guarda el UUID de partición GPT del soporte donde vive el gestor de arranque, y se publica bajo el GUID de proveedor que systemd reserva para el cargador de Linux. La [Discoverable Partitions Specification](https://uapi-group.org/specifications/specs/discoverable_partitions_specification/) traduce esos UUID de tipo a puntos de montaje concretos. Estas son las entradas que más aparecen en un disco preparado para arrancar sin /etc/fstab y sin parámetros de raíz: Tipo de partición GUID de tipo Qué hace systemd al encontrarla Sistema EFI (ESP) c12a7328-f81f-11d2-ba4b-00a0c93ec93b Monta /boot o /efi en el disco desde el que se arrancó Arranque extendido bc13c2ff-59e6-4262-a352-b275fd6f7172 Monta /boot cuando convive con la partición EFI Raíz amd64 4f68bce3-e8cd-4db1-96e7-fbcaf984b709 Monta / y prepara dm-verity si el disco lo pide Datos de usuario 933ac7e1-2eb4-4f13-b844-0e14e2aef915 Monta /home desde la primera partición con ese tipo Datos genéricos Linux 0fc63daf-8483-4772-8e79-3d69d8477de4 No monta nada, exige una entrada manual en fstab La última fila explica por qué el arreglo no sirve de nada en un disco particionado a la antigua: la etiqueta de datos genérica no lleva a ningún punto de montaje y systemd seguirá pidiendo una línea escrita a mano en fstab. ## Doce años de especificación con medio camino hecho La idea viene de lejos. systemd 211, publicada en marzo de 2014, ya sabía descubrir /home y la swap por el tipo de partición, y la especificación amplió después el catálogo a la raíz, /usr, /srv y /var. Lo que nunca hubo fue un firmware que rellenara el dato cuando no había gestor de arranque de por medio. Conviene matizar que el automontaje tiene condiciones. /var solo se monta si el UUID de la partición coincide con los primeros 128 bits de un HMAC-SHA256 calculado sobre el machine-id del sistema, una precaución para que dos instalaciones en el mismo disco no compartan datos por accidente. ## El arreglo acabó en el kernel porque el firmware dijo que no Mailhol llegó al problema por su cuenta. Instaló coreboot con edk2 en su máquina, arrancó el kernel desde el stub y vio que varias particiones dejaban de montarse. El rastro lo llevó hasta una variable que GRUB escribía y su firmware no, y su primer intento fue un cambio en el propio edk2, rechazado por considerarse demasiado específico de Linux. La solución que sí pasó mueve el trabajo al sitio donde vale para cualquier firmware. El stub mira primero si LoaderInfo ya está puesta por una etapa anterior; si existe, se retira sin tocar nada, de modo que GRUB y systemd-boot conservan la prioridad. Si no existe, recorre el device path de la imagen, busca el nodo HD() del GPT y publica su GUID. El enganche vive en las dos rutas del stub, la genérica y la que solo compila x86, así que el arreglo vale igual para un servidor de 64 bits que para un portátil con el mismo firmware. El coste en tamaño es ridículo: el [bloat-o-meter que acompaña al parche](https://lore.kernel.org/all/20260906-efi_stub_bli-v3-1-e7dc0d6b8fcd@kernel.org/) mide 636 bytes para la función que hace el trabajo y un 2,6% más de libstub. La variable es volátil, con acceso de servicio de arranque y de ejecución, así que no sobrevive a un reinicio ni deja estado antiguo en la NVRAM de la placa. Ahí está la diferencia con una variable persistente: lo que se publica describe el arranque en curso, no una configuración llamada a durar meses. ## A quién le cambia el arranque y a quién no A quien tiene Ubuntu con GRUB no le cambia nada, y conviene decirlo antes de que alguien busque la mejora en su equipo. Tampoco notará nada quien use systemd-boot, que ya escribe la variable en cada arranque. El cambio está pensado para el arranque directo, el escenario que Mailhol encontró en una placa con coreboot y que aparece siempre que el firmware carga el kernel sin intermediarios. Hay una condición que el parche no salva: las particiones tienen que llevar los GUID de la especificación. Si el instalador repartió el disco con la etiqueta genérica de datos Linux, systemd no montará nada por su cuenta y el usuario seguirá necesitando fstab, con kernel nuevo o con el viejo. Comprobarlo cuesta un comando: si LoaderDevicePartUUID no aparece listada en efivarfs, el sistema de ficheros que expone las variables del firmware, ese equipo está montando su disco a ciegas y systemd lo resuelve con una línea escrita a mano en fstab. El resto de la ventana de fusión va en la misma dirección de quitar trabajo al arranque, como el caso de [Linux 7.4 memblock](https://observatorioblockchain.com/tecnologia/linux-7-4-memblock-arranque-50-ms/), donde el asignador de memoria física bajó de 268 segundos a 50 ms en máquinas grandes. Son mejoras que no se ven en el escritorio y sí en un servidor que reinicia a menudo. ## Un /etc/fstab menos en el camino Linux 7.4 no llegará estable hasta dentro de varias semanas, así que nadie va a notar el cambio en el próximo ciclo de actualizaciones. Lo notarán quienes montan imágenes con systemd-repart, quienes prueban kernels en placas con coreboot y quienes despliegan dispositivos donde el arranque es un detalle de firmware que nadie quiere tocar. En la misma ventana entraron las mejoras para portátiles y consolas portátiles que recoge [Linux 7.4 y los handhelds](https://observatorioblockchain.com/tecnologia/linux-74-soporte-portatiles-handhelds-juego/), y el patrón se repite: trabajo invisible que solo se echa de menos cuando falta. Ninguna de estas piezas vende un kernel, y todas juntas son las que hacen que un equipo arranque sin que nadie abra un editor de texto. La asimetría de fondo sigue ahí: el estándar que describe esas variables lo mantiene systemd, no el foro que escribe la especificación UEFI, y por eso el arreglo acabó donde acabó.