EFI system partition (Español)
La partición del sistema EFI (también llamada, por sus siglas en inglés, ESP) es una partición independiente del sistema operativo, que actúa como el lugar de almacenamiento para los cargadores de arranque EFI, las aplicaciones y los controladores que serán lanzados por el firmware UEFI. Es obligatoria para el arranque UEFI.
La especificación UEFI exige soporte para los sistemas de archivos FAT12, FAT16 y FAT32 (vea UEFI specification version 2.7, section 13.3.1.1), pero cualquier proveedor puede opcionalmente agregar soporte para otros sistemas de archivos adicionales; por ejemplo, algunos proveedores añaden soporte de Apple Macs (y de forma predeterminada) para sus propios controladores del sistema de archivos HFS +.
Comprobar la existencia de una partición
Si está instalando Arch Linux en un equipo compatible con UEFI que ya tiene un sistema operativo instalado, como Windows 10, por ejemplo, es muy probable que ya tenga una partición del sistema EFI.
Para conocer el esquema de particionado del disco y la «system partition», utilice fdisk como root sobre el disco desde el que desea iniciar:
# fdisk -l /dev/sdx
Esta orden devolverá:
- La tabla de particionado del disco: si indica
Disklabel type: gpt
la tabla de particionado es GPT oDisklabel type: dos
si es MBR. - La lista de particiones en el disco: busque la partición del sistema EFI en la lista, es una partición pequeña (generalmente alrededor de 100–550 MiB) con un tipo
EFI System
oEFI (FAT-12/16/32)
. Para confirmar que esta es la ESP, móntela y verifique si contiene un directorio llamadoEFI
, si es así, definitivamente es la ESP.
Si encontró una partición del sistema EFI existente, solo tiene que #Montar la partición. Si no encontró una, deberá crearla, proceda con #Crear la partición.
Crear la partición
Las siguientes dos secciones muestran cómo crear una partición del sistema EFI (ESP).
Para evitar posibles problemas con algunas implementaciones de UEFI, la ESP debería estar formateada con FAT32 y con un tamaño de, al menos, 512 MiB. Se recomienda 550 MiB para evitar la confusión entre MiB/MB y la creación accidental de FAT16 [1], aunque tamaños más grandes también están de más.
De acuerdo con una nota de Microsoft [2], el tamaño mínimo para la partición del sistema EFI sería de 100 MiB, aunque esto no se recoge en las especificaciones UEFI. Téngase en cuenta que para formatos avanzados de unidades con 4K nativo (4-KiB-por-sector), el tamaño mínimo requerido será de, al menos, 256 MiB, porque es el tamaño mínimo de la partición de las unidades FAT32 (calculado del siguiente modo: tamaño de sector (4KiB) x 65527 = 256 MiB), y ello debido a una limitación presente en el formato del sistema de archivos FAT32.
Discos particionados con GPT
La partición del sistema EFI en una tabla de particionado GUID Partition Table está identificada por la GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B
.
Elija uno de los siguientes métodos para crear una ESP para un disco particionado con GPT:
- fdisk: cree una partición con el tipo de partición
EFI System
. - gdisk: cree una partición con el tipo de partición
EF00
. - GNU Parted: cree una partición con
fat32
como tipo de sistema de archivos y establezca/active el indicadoresp
en él.
Continúe en la sección #Formatear la partición a continuación.
Discos particionados con MBR
La partición del sistema EFI en una tabla de particionado Master Boot Record está identificada por el ID EF
.
Elija uno de los siguientes métodos para crear un ESP para un disco particionado MBR:
- fdisk: crre una partición primaria con el tipo de partición
EFI (FAT-12/16/32)
. - GNU Parted: cree una partición primaria con
fat32
como el tipo de sistema de archivos y establezca/active el indicadoresp
en ella.
Continúe en la sección #Formatear la partición a continuación.
Formatear la partición
Después de crear la ESP, debe formatearla con el sistema de archivos FAT32:
# 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 no ser legible por UEFI. Consulte mkfs.fat(8) para conocer los tamaños de clúster admitidos.
Montar la partición
El kernel y los archivos initramfs deben ser accesibles por el gestor de arranque o el propio UEFI para poder arrancar correctamente el sistema. Por lo tanto, si desea mantener una configuración simple, la elección del cargador de arranque limitará los puntos de montaje disponibles para la partición del sistema EFI.
Los escenarios más simples para montar la partición del sistema EFI son:
- montar ESP en
/efi
y utilizar un gestor de arranque que sea capaz de dirigirle a su sistema de archivos raíz (por ejemplo, GRUB (Español), rEFInd). - montar ESP en
/boot
. Este es el método preferido cuando se arranca directamente un kernel EFISTUB desde UEFI.
EFI
en su raíz, por lo tanto, al montar ESP en /boot
puede encontrar una ruta de directorio como /boot/EFI
. No confunda esta ruta con el punto de montaje ESP /boot/efi
popularmente usado (y posiblemente aún utilizado por otras distribuciones de Linux).Puntos de montaje alternativos
Si no utiliza uno de los métodos simples para #Montar la partición, tendrá que copiar los archivos de arranque a la ESP (en adelante 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, deberá mantener actualizados los archivos en el ESP con las últimas actualizaciones del kernel. De lo contrario, podría producirse un sistema no arrancable. Las siguientes secciones muestran varios mecanismos para automatizarlo.
/boot
, no se fie del mecanismo de montaje automático de systemd (que se incluye en systemd-gpt-auto-generator(8)). Monte siempre manualmente la partición de arranque antes de cualquier actualización del sistema o del kernel, de lo contrario puede que no pueda montarla después de la actualización, ya que el nuevo kernel en ejecución, bloqueará la partición de arranque, imposibilitando la actualización de la copia del kernel presente en la ESP.
También es posible precargar los módulos requeridos por el kernel en el arranque, por ejemplo:
/etc/modules-load.d/vfat.conf
vfat nls_cp437 nls_iso8859-1
Utilizar el montaje con bind
En lugar de montar la ESP en el mismo punto de montaje que /boot
, puede montar un directorio de la ESP en /boot
, montándola con bind (vea mount(8)). Esto permite a pacman (Español) actualizar el kernel directamente, mientras mantiene organizada a su gusto la ESP.
- Este método requiere un kernel y un gestor de arranque compatible con FAT32. Esto no es un problema para una instalación normal de Arch, pero podría ser problemático para otras distribuciones (esto es, aquellas que requieren enlaces simbólicos en
/boot/
). Consulte la publicación del foro aquí. - Debe utilizar el parámetro del kernel
root=
para poder arrancar con este método.
Al igual que se hizo en #Puntos de montaje alternativos, debemos copiar todos los archivos de arranque en un directorio de su ESP, pero monte la ESP fuera de /boot
. A continuación, monte el directorio con la opción bind:
# mount --bind esp/EFI/arch /boot
Después de verificar el éxito de la operación, edite fstab para hacer estos cambios persistentes:
/etc/fstab
esp/EFI/arch /boot none defaults,bind 0 0
Utilizar systemd
Systemd (Español) tiene la capacidad de programar tareas que se desencadenarán cuando se produzca un evento. En este caso particular, la capacidad de detectar un cambio en una ruta determinada es usada para sincronizar los archivos del kernel de EFISTUB e initramfs cuando se actualizan en /boot/
. El archivo observado en busca de cambios es initramfs-linux-fallback.img
, ya que este es el último archivo creado por mkinitcpio, para asegurarse de que todos los archivos han sido correctamente compilados antes de iniciar la copia. Los archivos de ruta y servicio de system que se crearán son:
/etc/systemd/system/efistub-update.path
[Unit] Description=Copiar el kernel EFISTUB en la partición del sistema EFI [Path] PathChanged=/boot/initramfs-linux-fallback.img [Install] WantedBy=multi-user.target WantedBy=system-update.target
/etc/systemd/system/efistub-update.service
[Unit] Description=Copiar el kernel EFISTUB en la partición del sistema EFI [Service] Type=oneshot ExecStart=/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/
Después, active 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
Utilizar eventos del sistema de archivos
Los eventos del sistema de archivos se pueden usar para ejecutar un script que sincronice el kernel EFISTUB después actualizar el kernel. He aquí un ejemplo con incron a continuación.
/usr/local/bin/efistub-update
#!/bin/sh cp -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/
/boot/initramfs-linux-fallback.img
es el archivo objeto de seguimiento. El segundo parámetro IN_CLOSE_WRITE
es la acción a tener en cuenta. El tercer parámetro /usr/local/bin/efistub-update
es el script que se ejecutará./etc/incron.d/efistub-update.conf
/boot/initramfs-linux-fallback.img IN_CLOSE_WRITE /usr/local/bin/efistub-update
Con el fin de utilizar este método, active el servicio incrond.service
.
Utilizar un hook de mkinitcpio
Mkinitcpio puede generar un hook que no necesita un demonio de nivel de sistema para funcionar. Mantiene un proceso en segundo plano a la espera de que se genere vmlinuz
, initramfs-linux.img
y initramfs-linux-fallback.img
antes de copiar los archivos.
Añada efistub-update
a la lista de hooks en /etc/mkinitcpio.conf
.
/etc/initcpio/install/efistub-update
#!/usr/bin/env bash build() { /usr/local/bin/efistub-copy $$ & } help() { cat <<HELPEOF Este hook espera a que mkinitcpio termine y luego copia el ramdisk y el kernel terminados a la ESP HELPEOF }
/usr/local/bin/efistub-copy
#!/usr/bin/env bash if [[ $1 -gt 0 ]] then while [ -e /proc/$1 ] do sleep .5 done fi rsync -a /boot/ esp/ echo "Sincronizado /boot con ESP"
Utilizar un hook de mkinitcpio (2)
Esta es otra alternativa a las soluciones anteriores, que es potencialmente más limpia porque hay menos copias y no necesita tampoco un demonio de nivel de sistema para funcionar. La lógica se invierte en este caso, initramfs se almacena directamente en la partición EFI, no se copia en /boot/
. Luego, el kernel y cualquier otro archivo adicional se copian en la partición ESP, gracias a un hook mkinitcpio.
Edite el archivo /etc/mkinitcpio.d/linux.preset
:
/etc/mkinitcpio.d/linux.preset
# archivo predeterminado de mkinitcpio para el paquete 'linux' # Directorio donde copiar el kernel, initramfs... ESP_DIR="esp/EFI/arch" ALL_config="/etc/mkinitcpio.conf" ALL_kver="/boot/vmlinuz-linux" PRESETS=('default' 'fallback') #default_config="/etc/mkinitcpio.conf" default_image="${ESP_DIR}/initramfs-linux.img" default_options="-A esp-update-linux" #fallback_config="/etc/mkinitcpio.conf" fallback_image="${ESP_DIR}/initramfs-linux-fallback.img" fallback_options="-S autodetect"
A continuación, cree el archivo /etc/initcpio/install/esp-update-linux
y hágalo ejecutable:
/etc/initcpio/install/esp-update-linux
# Directorio donde copiar el kernel, initramfs... build() { cp -af /boot/vmlinuz-linux "${ESP_DIR}/" [[ -e /boot/intel-ucode.img ]] && cp -af /boot/intel-ucode.img "${ESP_DIR}/" [[ -e /boot/amd-ucode.img ]] && cp -af /boot/amd-ucode.img "${ESP_DIR}/" } help() { cat <<HELPEOF Este hook copia el kernel a la partición ESP HELPEOF }
Para probarlo, basta ejecutar:
# rm /boot/initramfs-linux-fallback.img # rm /boot/initramfs-linux.img # mkinitcpio -p linux
Utilizar un hook de pacman
Una última opción depende de los hooks de pacman que se ejecutan al final de la instalación.
El primer archivo es un hook que supervisa los archivos relevantes, y se ejecuta si los mismos se modifican en la preinstalación.
/etc/pacman.d/hooks/999-kernel-efi-copy.hook
[Trigger] Type = File Operation = Install Operation = Upgrade Target = boot/vmlinuz* Target = usr/lib/initcpio/* Target = boot/*-ucode.img [Action] Description = Copiando linux y initramfs al directorio EFI... When = PostTransaction Exec = /usr/local/bin/kernel-efi-copy.sh
El segundo archivo es el script en sí. Cree el archivo y hágalo ejecutable:
/usr/local/bin/kernel-efi-copy.sh
#!/usr/bin/env bash # # Copiar las imágenes kernel e initramfs al directorio EFI # ESP_DIR="esp/EFI/arch" for file in /boot/vmlinuz* do cp -af "$file" "$ESP_DIR/$(basename "$file").efi" [[ $? -ne 0 ]] && exit 1 done for file in /boot/initramfs* do cp -af "$file" "$ESP_DIR/" [[ $? -ne 0 ]] && exit 1 done [[ -e /boot/intel-ucode.img ]] && cp -af /boot/intel-ucode.img "$ESP_DIR/" [[ -e /boot/amd-ucode.img ]] && cp -af /boot/amd-ucode.img "$ESP_DIR/" exit 0
Problemas conocidos
Partición ESP sobre RAID
Es posible hacer que la partición ESP sea parte de una matriz RAID1, pero al hacerlo se corre el riesgo de dañar los datos, y se deben tomar más consideraciones al crear la ESP. Consulte [3] y [4] para conocer más detalles.