Partição do sistema EFI

A partição do sistema EFI (também chamada ESP) é uma partição independente do SO que actua como local de armazenamento para os carregadores de arranque, aplicações e controladores EFI a serem lançados pelo firmware UEFI. É obrigatória para o arranque UEFI.

Este artigo ou secção é um candidato para a mudança para o Unified Extensible Firmware Interface#UEFI drivers.

Notas: Os controladores para sistemas de ficheiros não-FAT estão fora do âmbito deste artigo. (Discutir em Talk:EFI system partition#)

A especificação UEFI mandata o suporte para os sistemas de ficheiros FAT12, FAT16, e FAT32 (ver especificação UEFI versão 2.8, secção 13.3.1.1), mas qualquer fornecedor conforme pode opcionalmente adicionar suporte para sistemas de ficheiros adicionais; por exemplo, o firmware em Apple Macs suporta o sistema de ficheiros HFS+.

Cheque para uma partição existente

Se estiver a instalar Arch Linux num computador com capacidade UEFI com um sistema operativo instalado, como o Windows 10 por exemplo, é muito provável que já tenha uma partição do sistema EFI.

Para descobrir o esquema de partição do disco e a partição do sistema, utilize o fdisk como raiz no disco de onde pretende arrancar:

# fdisk -l /dev/sdx

O comando retorna:

A tabela de partição do disco: indica Disklabel type: gpt se a tabela de partição for GPT ou Disklabel type: dos se for MBR.
A lista de partições no disco: Procure a partição do sistema EFI na lista, normalmente tem pelo menos 100 MiB de tamanho e tem o tipo EFI System ou EFI (FAT-12/16/32). Para confirmar que este é o ESP, monte-o e verifique se contém um directório chamado EFI, se o fizer é definitivamente o ESP.

Tip: Para saber se é um sistema de ficheiros FAT12, FAT16 ou FAT32, siga FAT#Detecting FAT type.

Aviso: Ao iniciar em duplo boot, evite reformatar o ESP, pois pode conter ficheiros necessários para iniciar outros sistemas operativos.

Se encontrou uma partição do sistema EFI existente, basta proceder a #Montagem da partição. Se não encontrou uma, terá de a criar, proceder a #Criar a partição.

Criar a partição

As duas secções seguintes mostram como criar uma partição do sistema EFI (ESP).

Aviso: A partição do sistema EFI deve ser uma partição física na tabela de partição principal do disco, não sob LVM ou RAID de software etc.

Nota: Recomenda-se a utilização de GPT uma vez que alguns firmwares podem não suportar o arranque UEFI/MBR devido ao facto de não ser suportado pelo Windows Setup. Ver também Particionamento#Fechar entre GPT e MBR para as vantagens do GPT em geral.

Para fornecer espaço adequado para armazenar carregadores de arranque e outros ficheiros necessários para o arranque, e para evitar problemas de interoperabilidade com outros sistemas operativos, a partição deve ter pelo menos 260 MiB. Para implementações iniciais e/ou buggy UEFI o tamanho de pelo menos 512 MiB poderá ser necessário.

discos particionados GPT

partição do sistema UEFI numa Tabela de Partição GUID é identificada pelo tipo de partição GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B.

Escolha um dos seguintes métodos para criar um ESP para um disco particionado GPT:

fdisk: Criar uma partição com tipo de partição EFI System.
gdisk: Criar uma partição com o tipo de partição EF00.
GNU Parted: Criar uma partição com fat32 como o tipo de sistema de ficheiros e definir o esp bandeira sobre ele.

Proceder a #Formatar a secção de partição abaixo.

Discos particionados MBR

partição do sistema EFI numa tabela de partição do Registo de Arranque Principal é identificada pelo tipo de partição ID EF.

p>Escolha um dos seguintes métodos para criar um ESP para um disco particionado MBR:

fdisk: Criar uma partição primária com o tipo de partição EFI (FAT-12/16/32).
GNU Parted: Criar uma partição primária com fat32 como o tipo de sistema de ficheiros e definir o esp bandeira sobre ele.

P>Prossiga para #Formatar a secção da partição abaixo.

Formatar a partição

A especificação UEFI mandata o suporte para os sistemas de ficheiros FAT12, FAT16, e FAT32. Para prevenir potenciais problemas com outros sistemas operativos e também uma vez que a especificação UEFI apenas mandata o suporte de FAT16 e FAT12 em suportes amovíveis, recomenda-se a utilização de FAT32.

Depois de criar a partição, formatá-la como FAT32. Para utilizar o utilitário mkfs.fat, instalar os dosfstools.

# mkfs.fat -F32 /dev/sdxY

Se receber a mensagem WARNING: Not enough clusters for a 32 bit FAT!, reduza o tamanho da partição com mkfs.fat -s2 -F32 ... ou -s1; caso contrário, a partição pode não ser legível pela UEFI. Ver mkfs.fat(8) para tamanhos de cluster suportados.

Montar a partição

Os kernels, ficheiros initramfs, e, na maioria dos casos, o microcódigo do processador, precisam de ser acessíveis pelo carregador de arranque ou pela própria UEFI para arrancar o sistema com sucesso. Assim, se quiser manter a configuração simples, a sua escolha do carregador de arranque limita os pontos de montagem disponíveis para a partição do sistema EFI.

Pontos de montagem típicos

Os cenários mais simples para montar a partição do sistema EFI são:

montar ESP para /efi e utilizar um carregador de arranque capaz de aceder ao(s) núcleo(s) e à(s) imagem(ões) initramfs que são armazenadas noutro local (tipicamente /boot). Ver Arch boot process#Boot loader para mais informações sobre requisitos e capacidades do boot loader.
mount ESP to /boot. Este é o método preferido quando se arranca directamente um kernel EFISTUB da UEFI ou se arranca através de um gestor de arranque como systemd-boot.
mount ESP to /efi e adicionalmente montar uma “Extended Boot Loader Partition” (XBOOTLDR) para /boot. Isto pode ser útil quando um ESP previamente criado é demasiado pequeno para suportar vários carregadores de arranque e/ou kernels, mas o ESP não pode ser facilmente redimensionado (tal como na instalação de Linux após Windows para arranque duplo). Este método é suportado por pelo menos systemd-boot.

Tip:

/efi é um substituto para o anteriormente popular (e possivelmente ainda utilizado por outras distribuições Linux) ponto de montagem ESP /boot/efi.
O directório /efi não está disponível por defeito, será necessário primeiro criá-lo com mkdir(1) antes de montar o ESP no mesmo.

Pontos de montagem alternativos

Se não utilizar um dos métodos simples de #Pontos de montagem típicos, terá de copiar os seus ficheiros de arranque para o ESP (doravante referido 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/

Nota: Poderá também precisar de copiar o Microcódigo para o local de entrada de arranque.

Furthermore, terá de manter os ficheiros no ESP actualizados com actualizações posteriores do kernel. Se não o fizer, poderá resultar num sistema não inicializável. As secções seguintes discutem vários mecanismos de automatização.

Nota: Se o ESP não estiver montado em /boot, certifique-se de não confiar no mecanismo de automatização do sistema (incluindo o do sistema-gpt-auto-gerador(8)). Tenha-o sempre montado manualmente antes de qualquer actualização do sistema ou do kernel, caso contrário poderá não ser capaz de o montar após a actualização, bloqueando-o no kernel actualmente em execução, sem capacidade de actualizar a cópia do kernel no ESP.

Alternatively preload the required kernel modules on boot, e.g.:

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

vfatnls_cp437nls_ascii

Using bind mount

em vez de montar o próprio ESP em /boot, pode montar um directório do ESP para /boot usando uma montagem de encadernação (ver mount(8)). Isto permite ao pacman actualizar directamente o kernel enquanto mantém o ESP organizado ao seu gosto.

Nota: Isto requer um kernel e um bootloader compatível com FAT32. Isto não é um problema para uma instalação regular do Arch, mas pode ser problemático para outras distribuições (nomeadamente aquelas que requerem symlinks em /boot/). Ver o post do fórum .

Apenas como em #Alternative mount points, copie todos os ficheiros de boot para um directório no seu ESP, mas monte o ESP fora de /boot. Depois monte o directório:

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

Após verificar o sucesso, edite o seu Fstab para tornar as alterações persistentes:

/etc/fstab

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

Using systemd

Systemd features event triggered tasks. Neste caso particular, a capacidade de detectar uma alteração no caminho é utilizada para sincronizar o kernel EFISTUB e ficheiros initramfs quando são actualizados em /boot/. O ficheiro observado para alterações é initramfs-linux-fallback.img uma vez que este é o último ficheiro construído por mkinitcpio, para se certificar de que todos os ficheiros foram construídos antes de iniciar a cópia. O caminho do sistema e ficheiros de serviço a serem criados são:

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

Description=Copy EFISTUB Kernel to EFI system partitionPathChanged=/boot/initramfs-linux-fallback.imgWantedBy=multi-user.targetWantedBy=system-update.target

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

Description=Copy EFISTUB Kernel to EFI system partitionType=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/

p>Então activar e iniciarefistub-update.path.

Tip: Para arranque seguro com as suas próprias chaves, pode configurar o serviço para também assinar a imagem usando 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 do sistema de ficheiros

Eventos do sistema de ficheiros podem ser usados para executar um script de sincronização do Kernel EFISTUB após actualizações do kernel. Um exemplo com incron segue.

/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/

Nota: O primeiro parâmetro /boot/initramfs-linux-fallback.img é o ficheiro a observar. O segundo parâmetro IN_CLOSE_WRITE é a acção a ter em conta. O terceiro parâmetro /usr/local/bin/efistub-update é o script a executar.

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

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

Para utilizar este método, activar o incrond.service.

Utilizar mkinitcpio hook

Mkinitcpio pode gerar um gancho que não necessita de um daemon de nível de sistema para funcionar. Ele gera um processo de fundo que espera pela geração de vmlinuzinitramfs-linux.img, e initramfs-linux-fallback.img antes de copiar os ficheiros.

p>Adicionarefistub-updateà lista de ganchos em/etc/mkinitcpio.conf.

/etc/initcpio/install/efistub-update

#!/usr/bin/env bashbuild() {/usr/local/bin/efistub-copy $ &}help() {cat <<HELPEOF Este gancho espera por mkinitcpio para terminar e copia o ramdisk acabado e o kernel para o ESPHELPEOF}

/usr/local/bin/efistub-copy

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

Using mkinitcpio preset

As the presets in /etc/mkinitcpio.d/ support shell scripting, the kernel and initramfs can be copied by just editing the presets.

Substituindo o gancho mkinitcpio acima

Editar o ficheiro /etc/mkinitcpio.d/linux.preset:

/etc/mkinitcpio.d/linux.preset

# mkinitcpio preset file for the 'linux' package# Directory to copy the kernel, the 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 testar isso, basta correr:

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

Outro exemplo

/etc/mkinitcpio.d/linux.preset

ESP_DIR="esp/EFI/arch "cp -f "/boot/vmlinuz-linux$suffix" "$ESP_DIR/"ALL_config="/etc/mkinitcpio.d/linux.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

Using pacman hook

Uma última opção baseia-se nos ganchos do pacman que são executados no final da transacção.

O primeiro ficheiro é um gancho que monitoriza os ficheiros relevantes, e é executado se estes foram modificados na transacção anterior.

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

Type = PathOperation = InstallOperation = UpgradeTarget = usr/lib/modules/*/vmlinuzTarget = usr/lib/initcpio/*Target = boot/*-ucode.imgDescription = Copying linux and initramfs to EFI directory...When = PostTransactionExec = /usr/local/bin/kernel-efi-copy.sh

O segundo ficheiro é o próprio script. Cria o ficheiro e torna-o executável:

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

#!/usr/bin/env bash### Copiar imagens do kernel e initramfs para o directório EFI#ESP_DIR="esp/EFI/arch "para ficheiro em /boot/vmlinuz*do cp -af "$file" "$ESP_DIR/$(basename "$file").efi" ] && exit 1donefor file in /boot/initramfs*do cp -af "$file" "$ESP_DIR/" ] && saída 1done] && cp -af /boot/intel-ucode.img "$ESP_DIR/"] && cp -af /boot/amd-ucode.img "$ESP_DIR/"exit 0

Procura de problemas

ESP sobre software RAID1

É possível fazer o ESP parte de um conjunto RAID1, mas fazê-lo traz o risco de corrupção de dados, e outras considerações devem ser tidas em conta ao criar o ESP. Ver e para detalhes e inicialização UEFI e RAID1 para um guia detalhado com uma solução.

A parte chave é usar --metadata 1.0 para manter os metadados RAID no fim da partição, caso contrário o firmware não será capaz de aceder a ele:

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

Firmware não vê o directório EFI

Se der um nome de volume ao sistema de ficheiros (com a opção -n), não se esqueça de lhe dar um nome diferente de “EFI”. Isso pode provocar um bug em alguns firmwares (devido ao nome do volume corresponder ao nome do directório EFI) que fará com que o firmware actue como se o directório EFI não existisse.

Veja também

A partição do sistema EFI e o comportamento de arranque padrão
Multi Boot Linux With One Boot Partition | John Ramsden