EFI system partition (Español) - ArchWiki

Jump to content

# EFI system partition (Español)

6 languages

- English
- Français
- 日本語
- Português
- Русский
- 中文（简体）

From ArchWiki
Esta traducción de EFI system partition fue revisada el 2018-12-14. Si existen cambios puede actualizarla o avisar al equipo de traducción.

Artículos relacionados

- Interfaz de firmware extensible unificada (UEFI)
- Gestores de arranque

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 o `Disklabel 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` o `EFI (FAT-12/16/32)`. Para confirmar que esta es la ESP, móntela y verifique si contiene un directorio llamado `EFI`, si es así, definitivamente es la ESP.

Advertencia: Al realizar un arranque dual, evite volver a formatear la ESP, ya que puede contener los archivos necesarios para iniciar otros sistemas operativos.

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).

Nota: Es recomendable utilizar GPT para el arranque UEFI, porque algunos firmwares UEFI no permiten el arranque UEFI/MBR.

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 indicador `esp` 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 indicador `esp` 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.

Nota: La ESP generalmente contendrá un directorio llamado `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/

Nota: Es posible que deba copiar el Microcódigo en la línea de la entrada de arranque.

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.

Nota: Si la ESP no está montada en `/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.

Nota:

- 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`.

Sugerencia: Para permitir Secure Boot con sus propias claves, puede configurar el servicio para que también firme la imagen utilizando sbsigntools:

    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/

Nota: El primer parámetro `/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.

## Véase también

- La partición del sistema EFI y el comportamiento de arranque predeterminado

Category:

- Boot process (Español)