Partición del sistema EFI

Este artículo o sección es candidato a ser movido a Unified Extensible Firmware Interface#UEFI drivers.

La especificación UEFI obliga a soportar los sistemas de archivos FAT12, FAT16 y FAT32 (ver la especificación UEFI versión 2.8, sección 13.3.1.1), pero cualquier proveedor conforme puede añadir opcionalmente soporte para sistemas de archivos adicionales; por ejemplo, el firmware de los Macs de Apple soporta el sistema de archivos HFS+.

Comprobar si hay una partición existente

Si estás instalando Arch Linux en un equipo con capacidad UEFI con un sistema operativo instalado, como Windows 10 por ejemplo, es muy probable que ya tengas una partición del sistema EFI.

Para conocer el esquema de particiones del disco y la partición del sistema, utiliza fdisk como root en el disco desde el que quieres arrancar:

# fdisk -l /dev/sdx

El comando devuelve:

• La tabla de particiones del disco: indica Disklabel type: gpt si la tabla de particiones es GPT o Disklabel type: dos si es MBR.
• La lista de particiones del disco: Busca la partición del sistema EFI en la lista, suele tener un tamaño mínimo de 100 MiB y tiene el tipo EFI System o EFI (FAT-12/16/32). Para confirmar que se trata del PES, móntalo y comprueba si contiene un directorio llamado EFI, si lo contiene este es definitivamente el PES.

Si encontró una partición del sistema EFI existente, simplemente proceda a #Montar la partición. Si no encontró una, deberá crearla, proceda a #Crear la partición.

Crear la partición

Las siguientes dos secciones muestran cómo crear una partición del sistema EFI (ESP).

Para proporcionar un espacio adecuado para almacenar los cargadores de arranque y otros archivos necesarios para el arranque, y para evitar problemas de interoperabilidad con otros sistemas operativos, la partición debe ser de al menos 260 MiB. Para las implementaciones tempranas y/o con errores de UEFI el tamaño de al menos 512 MiB podría ser necesario.

Discos con partición GPT

La partición del sistema UEFI en una Tabla de Partición GUID se identifica por el tipo de partición GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B.

Elija uno de los siguientes métodos para crear un ESP para un disco con partición GPT:

• fdisk: Crea una partición con el tipo de partición EFI System.
• gdisk: Crea una partición con tipo de partición EF00.
• GNU Parted: Crea una partición con fat32 como tipo de sistema de archivos y establece la bandera esp en ella.

Procede a la sección #Formatear la partición a continuación.

Discos con particiones MBR

La partición del sistema EFI en una tabla de particiones Master Boot Record se identifica con el ID del tipo de partición EF.

Elija uno de los siguientes métodos para crear un ESP para un disco con particiones MBR:

• fdisk: Crea una partición primaria con tipo de partición EFI (FAT-12/16/32).
• GNU Parted: Crea una partición primaria con fat32 como tipo de sistema de archivos y establece la bandera esp en ella.

Proceda a la sección #Formatear la partición a continuación.

Formatear la partición

La especificación UEFI obliga a soportar los sistemas de archivos FAT12, FAT16 y FAT32. Para evitar posibles problemas con otros sistemas operativos y también ya que la especificación UEFI sólo obliga a soportar FAT16 y FAT12 en medios extraíbles, se recomienda utilizar FAT32.

Después de crear la partición, formatéela como FAT32. Para utilizar la utilidad mkfs.fat, instale dosfstools.

# mkfs.fat -F32 /dev/sdxY

Si obtiene el mensaje WARNING: Not enough clusters for a 32 bit FAT!, reduzca el tamaño del clúster con mkfs.fat -s2 -F32 ... o -s1; de lo contrario, la partición puede ser ilegible por UEFI. Consulte mkfs.fat(8) para conocer los tamaños de clúster soportados.

Monte la partición

Los kernels, los archivos initramfs y, en la mayoría de los casos, el microcódigo del procesador, necesitan ser accesibles por el cargador de arranque o la propia UEFI para arrancar con éxito el sistema. Por lo tanto, si desea mantener la configuración simple, su elección del gestor de arranque limita los puntos de montaje disponibles para la partición del sistema EFI.

Puntos de montaje típicos

Los escenarios más sencillos para montar la partición del sistema EFI son:

• montar ESP en /efi y utilizar un cargador de arranque que sea capaz de acceder al núcleo(s) y a la(s) imagen(es) initramfs que se almacenan en otro lugar (normalmente /boot). Consulte Arch boot process#Boot loader para obtener más información sobre los requisitos y las capacidades del cargador de arranque.
• monte ESP en /boot. Este es el método preferido cuando se arranca directamente un kernel EFISTUB desde UEFI o se arranca a través de un gestor de arranque como systemd-boot.
• montar ESP en /efi y montar adicionalmente una «Partición de cargador de arranque extendido» (XBOOTLDR) en /boot. Esto puede ser útil cuando un ESP creado previamente es demasiado pequeño para albergar múltiples cargadores de arranque y/o kernels pero el ESP no puede ser fácilmente redimensionado (como cuando se instala Linux después de Windows para un arranque dual). Este método es soportado al menos por systemd-boot.
Consejo:
• /efi es un reemplazo para el anteriormente popular (y posiblemente todavía utilizado por otras distribuciones de Linux) punto de montaje ESP /boot/efi.
• El directorio /efi no está disponible por defecto, tendrá que crearlo primero con mkdir(1) antes de montar el ESP en él.

Puntos de montaje alternativos

Si no utilizas uno de los métodos sencillos de #Puntos de montaje típicos, tendrás que copiar tus archivos de arranque en el ESP (referido en adelante como esp).

# mkdir -p esp/EFI/arch# cp -a /boot/vmlinuz-linux esp/EFI/arch/# cp -a /boot/initramfs-linux.img esp/EFI/arch/# cp -a /boot/initramfs-linux-fallback.img esp/EFI/arch/

Además, tendrá que mantener los archivos en el ESP actualizados con las actualizaciones posteriores del kernel. Si no lo hace, podría resultar en un sistema que no arranca. Las siguientes secciones discuten varios mecanismos para automatizarlo.

/etc/modules-load.d/vfat.conf

vfatnls_cp437nls_ascii

Usando bind mount

En lugar de montar el propio ESP en /boot, puede montar un directorio del ESP en /boot utilizando un montaje bind (ver mount(8)). Esto permite a pacman actualizar el kernel directamente mientras mantiene el ESP organizado a su gusto.

Al igual que en #Puntos de montaje alternativos, copie todos los archivos de arranque a un directorio en su ESP, pero monte el ESP fuera de /boot. Luego bind monta el directorio:

# mount --bind esp/EFI/arch /boot

Después de verificar el éxito, edita tu Fstab para que los cambios sean persistentes:

/etc/fstab

esp/EFI/arch /boot none defaults,bind 0 0

Usando systemd

Systemd cuenta con tareas activadas por eventos. En este caso concreto, la capacidad de detectar un cambio de ruta se utiliza para sincronizar los archivos del kernel EFISTUB y del initramfs cuando se actualizan en /boot/. El archivo observado para los cambios es initramfs-linux-fallback.img ya que es el último archivo construido por mkinitcpio, para asegurarse de que todos los archivos se han construido antes de iniciar la copia. La ruta de systemd y los archivos de servicio a crear son:

/etc/systemd/system/efistub-update.path

Description=Copia del Kernel EFISTUB a la partición del sistema EFIPathChanged=/boot/initramfs-linux-fallback.imgWantedBy=multi-user.targetWantedBy=system-update.target

/etc/systemd/system/efistub-update.service

Description=Copiar el kernel EFISTUB a la partición del sistema EFIType=oneshotExecStart=/usr/bin/cp -af /boot/vmlinuz-linux esp/EFI/arch/ExecStart=/usr/bin/cp -af /boot/initramfs-linux.img esp/EFI/arch/ExecStart=/usr/bin/cp -af /boot/initramfs-linux-fallback.img esp/EFI/arch/

A continuación, habilite e inicie efistub-update.path.

ExecStart=/usr/bin/sbsign --key /path/to/db.key --cert /path/to/db.crt --output esp/EFI/arch/vmlinuz-linux /boot/vmlinuz-linux

Usando eventos del sistema de archivos

Los eventos del sistema de archivos pueden usarse para ejecutar un script que sincronice el Kernel EFISTUB después de las actualizaciones del kernel. Un ejemplo con incron es el siguiente.

/usr/local/bin/efistub-update

#!/bin/shcp -af /boot/vmlinuz-linux esp/EFI/arch/cp -af /boot/initramfs-linux.img esp/EFI/arch/cp -af /boot/initramfs-linux-fallback.img esp/EFI/arch/

/etc/incron.d/efistub-update.conf

/boot/initramfs-linux-fallback.img IN_CLOSE_WRITE /usr/local/bin/efistub-update

Para usar este método, habilita el incrond.service.

Usando mkinitcpio hook

Mkinitcpio puede generar un hook que no necesita un demonio a nivel de sistema para funcionar. Genera un proceso en segundo plano que espera la generación de vmlinuzinitramfs-linux.img, y initramfs-linux-fallback.img antes de copiar los archivos.¡

Add efistub-update a la lista de hooks en /etc/mkinitcpio.conf.

/etc/initcpio/install/efistub-update

#!/usr/bin/env bashbuild() {/usr/local/bin/efistub-copy $ &}help() {cat <<HELPEOFThis hook wait for mkinitcpio termine y copia el ramdisk terminado y el kernel al ESPHELPEOF}

/usr/local/bin/efistub-¡copy

#!/usr/bin/env bashif ]thenwhile dosleep .5donefirsync -a /boot/ esp/echo "Synced /boot with ESP"

Usando mkinitcpio preset

Como los presets en /etc/mkinitcpio.d/ soportan shell scripting, el kernel y el initramfs pueden copiarse con sólo editar los presets.

Reemplazando el hook mkinitcpio anterior

Edita el archivo /etc/mkinitcpio.d/linux.preset:

/etc/mkinitcpio.d/linux.preset

# archivo mkinitcpio preset para el paquete 'linux'# Directorio para copiar el kernel, el initramfs...ESP_DIR="''esp''/EFI/arch "ALL_config="/etc/mkinitcpio.conf "ALL_kver="${ESP_DIR}/vmlinuz-linux "cp -af /boot/vmlinuz-linux "${ESP_DIR}/"] && cp -af /boot/intel-ucode.img "${ESP_DIR}/"] && cp -af /boot/amd-ucode.img "${ESP_DIR}/"PRESETS=('default' 'fallback')#default_config="/etc/mkinitcpio.conf "default_image="${ESP_DIR}/initramfs-linux.img "default_options=""#fallback_config="/etc/mkinitcpio.conf "fallback_image="${ESP_DIR}/initramfs-linux-fallback.img "fallback_options="-S autodetect"

Para probarlo, basta con ejecutar:

# rm /boot/initramfs-linux-fallback.img# rm /boot/initramfs-linux.img# mkinitcpio -p linux

Otro ejemplo

/etc/mkinitcpio.d/linux.preset

ESP_DIR="esp/EFI/arch "cp -f "/boot/vmlinuz-linux$suffix" "$ESP_DIR/"ALL_config="/etc/mkinitcpio.conf "ALL_kver="$ESP_DIR/vmlinuz-linux$suffix "PRESETS=('default')default_config="/etc/mkinitcpio.conf "default_image="$ESP_DIR/initramfs-linux$suffix.img"

/etc/mkinitcpio.d/linux-zen.preset

suffix='-zen'source /etc/mkinitcpio.d/linux.preset

Usando pacman hook

Una última opción se basa en los pacman hooks que se ejecutan al final de la transacción.

El primer archivo es un hook que monitoriza los archivos relevantes, y se ejecuta si fueron modificados en la transacción anterior.

/etc/pacman.d/hooks/999-kernel-efi-copy.hook

Tipo = PathOperation = InstallOperation = UpgradeTarget = usr/lib/modules/*/vmlinuzTarget = usr/lib/initcpio/*Target = boot/*-ucode.imgDescription = Copiar linux e initramfs al directorio EFI...When = PostTransactionExec = /usr/local/bin/kernel-efi-copy.sh

El segundo archivo es el propio script. ¡Crea el archivo y hazlo ejecutable:

/usr/local/bin/kernel-efi-copy.sh

#!/usr/bin/env bash## Copiar las imágenes del kernel y del initramfs al directorio EFI#ESP_DIR="esp/EFI/arch "for file in /boot/vmlinuz*do cp -af "$file" "$ESP_DIR/$(basename "$file").efi" ] && exit 1donefor file in /boot/initramfs*do cp -af "$file" "$ESP_DIR/" ] && exit 1done] && cp -af /boot/intel-ucode.img "$ESP_DIR/"] && cp -af /boot/amd-ucode.img "$ESP_DIR/"exit 0

Solución de problemas

ESP en RAID1 por software

Es posible hacer que el ESP forme parte de una matriz RAID1, pero al hacerlo se corre el riesgo de que se corrompan los datos, y es necesario tener en cuenta otras consideraciones al crear el ESP. Ver y para más detalles y UEFI booting and RAID1 para una guía en profundidad con una solución.

La parte clave es utilizar --metadata 1.0 para mantener los metadatos del RAID al final de la partición, de lo contrario el firmware no podrá acceder a ellos:

# mdadm --create --verbose --level=1 --metadata=1.0 --raid-devices=2 /dev/md/ESP /dev/sdaX /dev/sdbY

El firmware no ve el directorio EFI

Si le das al sistema de archivos un nombre de volumen (con la opción -n), asegúrate de nombrarlo con algo distinto a «EFI». Eso puede desencadenar un error en algunos firmwares (debido a que el nombre del volumen coincide con el nombre del directorio EFI) que hará que el firmware actúe como si el directorio EFI no existiera.

Vea también

• La partición del sistema EFI y el comportamiento de arranque por defecto
• Multi Boot Linux With One Boot Partition | John Ramsden

.