EFI system partition (Português)

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Status de tradução: Esse artigo é uma tradução de EFI system partition. Data da última tradução: 2020-03-07. Você pode ajudar a sincronizar a tradução, se houver alterações na versão em inglês.

A partição de sistema EFI (em inglês EFI system partition, abreviado como ESP) é uma partição independente do sistema operacional que atua como o local de armazenamento para os gerenciadores de boot, aplicativos e drivers EFI a serem lançados pelo firmware UEFI. É obrigatório para a inicialização do UEFI.

A especificação UEFI determina o suporte para os sistemas de arquivos FAT12, FAT16 e FAT32 (consulte a especificação UEFI versão 2.7, seção 13.3.1.1), mas qualquer fornecedor em conformidade pode, opcionalmente, adicionar suporte para sistemas de arquivos adicionais; por exemplo, o firmware em Macs da Apple possui suporte ao sistema de arquivos HFS+.

Verificar uma partição existente

Se você estiver instalando o Arch Linux em um computador compatível com UEFI com um sistema operacional instalado, como Windows 10 por exemplo, é muito provável que você já tenha uma partição do sistema EFI.

Para descobrir o esquema de partição de disco e a partição do sistema, use fdisk como root no disco que você quer inicializar:

# fdisk -l /dev/sdx

O comando retorna:

A tabela de partições do disco: indica Tipo de rótulo do disco: gpt se a tabela de partições for GPT ou Tipo de rótulo do disco: dos se for MBR.
A lista de partições no disco: Procure a partição do sistema EFI na lista, é uma partição pequena (normalmente cerca de 100–550 MiB) com um tipo Sistema EFI ou EFI (FAT-12/16/32). Para confirmar isso é a ESP, monte e verifique se ela contém um diretório chamado EFI, se contiver é definitivamente a ESP.

Dica: Para descobrir se é um sistema de arquivos FAT12, FAT16 ou FAT32, use minfo a partir de mtools.

# minfo -i /dev/sdxY :: | grep 'disk type'

Atenção: Ao usar dual-boot, evite reformatar a ESP, pois ela pode conter arquivos necessários para inicializar outros sistemas operacionais.

Se você encontrou uma partição do sistema EFI existente, simplesmente prossiga para #Montar a partição. Se você não encontrou uma, você precisará criá-la, vá para #Criar a partição.

Criar a partição

As duas seções a seguir mostram como criar uma partição do sistema EFI (ESP).

Atenção: 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 software RAID, etc.

Nota: Recomenda-se o uso de GPT, pois alguns firmwares podem não suportar a inicialização via UEFI/MBR por não serem suportados pelo Windows Setup. Veja também Particionamento#Escolhendo entre MBR e GPT para as vantagens da GPT em geral.

Para fornecer espaço adequado para armazenar gerenciadores de boot e outros arquivos necessários para inicialização e para evitar problemas de interoperabilidade com outros sistemas operacionais[1][2] a partição deve ter pelo menos 260 MiB. Para implementações de UEFI precoces e/ou com bugs, o tamanho de pelo menos 512 MiB pode ser necessário.[3]

Discos particionados em GPT

Partição de sistema EFI em uma Tabela de Partição GUID é identificada pelo GUID de tipo de partição C12A7328-F81F-11D2-BA4B-00A0C93EC93B.

Escolha um dos métodos a seguir para criar uma ESP para um disco particionado em GPT:

fdisk: Crie uma partição com o tipo de partição EFI System.
gdisk: Crie uma partição com o tipo de partição EF00.
GNU Parted: Crie uma partição com fat32 como o tipo de sistema de arquivos e defina a opção esp nela.

Continue com a seção #Formatar a partição abaixo.

Discos particionados em MBR

A partição do sistema EFI em uma tabela de partição Master Boot Record é identificada pelo ID de tipo de partição EF.

Escolha um dos métodos a seguir para criar uma ESP para um disco particionado em MBR:

fdisk: Crie uma partição primária com o tipo de partição EFI (FAT-12/16/32).
GNU Parted: Crie uma partição primária com fat32 como o tipo de sistema de arquivos e defina a opção esp nela.

Continue com a seção #Formatar a partição abaixo.

Formatar a partição

A especificação UEFI determina o suporte para os sistemas de arquivos FAT12, FAT16 e FAT32[4]. Para evitar possíveis problemas com outros sistemas operacionais e também porque a especificação UEFI apenas exige suporte a FAT16 e FAT12 em mídia removível[5], recomenda-se usar o FAT32.

Após criar a partição, formate-a como FAT32. Para usar o utilitário mkfs.fat, instale dosfstools.

# mkfs.fat -F32 /dev/sdxY

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

Montar a partição

Os kernels, os arquivos initramfs e, na maioria dos casos, o microcódigo do processador, precisam ser acessados pelo gerenciador de boot ou pelo próprio UEFI para inicializar com sucesso o sistema. Portanto, se você quiser manter a configuração simples, sua opção de gerenciador de boot limita os pontos de montagem disponíveis para a partição do sistema EFI.

Pontos de montagem comuns

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

montar a ESP em /efi e usar um gerenciador de boot que é capaz de acessar as imagens do kernel e initramfs que são armazenadas em outro local (normalmente /boot). Consulte Processo de inicialização do Arch#Gerenciador de boot para obter mais informações sobre os requisitos e recursos do gerenciador de boot.
montar a ESP em /boot. Esse é o método preferível ao inicializar diretamente um kernel de EFISTUB do UEFI.

Dica:

/efi é um substituto[6] para o anterior e popular (e possivelmente ainda usado por outras distribuições) ponto de montagem ESP /boot/efi.
O diretório /efi não está disponível por padrão, de forma que você precisará primeiro criá-lo com mkdir(1) antes de montar a ESP nele.

Pontos de montagem alternativos

Se você não usar um dos métodos simples de #Montar a partição, você precisará copiar seus arquivos de inicialização para a ESP (referida daqui em diante 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: Você também pode precisar copiar o microcódigo para o local da entrada de inicialização.

Além disso, você precisará manter os arquivos na ESP em dia com as atualizações posteriores do kernel. Não fazer isso pode resultar em um sistema não inicializável. As seções a seguir discutem vários mecanismos para automatizá-la.

Nota: Se a ESP não estiver montada em /boot, certifique-se de não confiar no mecanismo de automontagem do systemd (incluindo o de systemd-gpt-auto-generator(8)). Sempre monte-a manualmente antes de atualizar o sistema ou o kernel, caso contrário você pode não conseguir montá-la após a atualização, lhe travando no kernel em execução no momento sem a capacidade de atualizar a cópia do kernel na ESP.

Alternativamente, carregue antecipadamente os módulos de kernel necessários na inicialização, p.ex.:

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

vfat
nls_cp437
nls_iso8859-1

Usando montagem com bind

Em vez de montar o próprio ESP para /boot, você pode montar um diretório do ESP para /boot usando uma montagem "bind" (consulte mount(8)). Isto permite que pacman atualize o kernel diretamente enquanto mantém a ESP organizada ao seu gosto.

Nota:

Isso requer um kernel e gerenciador de boot compatível com o FAT32. Este não é um problema para uma instalação comum do Arch, mas pode ser problemático para outras distribuições (ou seja, aquelas que exigem links simbólicos em /boot/). Veja a postagem no fórum arquivo.
Você deve usar o parâmetro do kernel root= para inicializar usando este método.

Assim como em #Pontos de montagem alternativos, copie todos os arquivos de inicialização para um diretório em sua ESP, mas monte a ESP fora do /boot. Em seguida, associe o diretório:

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

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

/etc/fstab

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

Usando systemd

O systemd apresenta tarefas acionadas por eventos. Nesse caso específico, a capacidade de detectar uma alteração no caminho é usada para sincronizar os arquivos kernel EFISTUB e initramfs quando eles são atualizados em /boot/. O arquivo assistido por alterações é o initramfs-linux-fallback.img, pois este é o último arquivo construído pelo mkinitcpio, para garantir que todos os arquivos tenham sido construídos antes de iniciar a cópia. Os arquivos de caminho e serviço systemd a serem criados são:

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

[Unit]
Description=Copy EFISTUB Kernel to EFI system partition

[Path]
PathChanged=/boot/initramfs-linux-fallback.img

[Install]
WantedBy=multi-user.target
WantedBy=system-update.target

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

[Unit]
Description=Copy EFISTUB Kernel to EFI system partition

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

Então, habilite e inicie efistub-update.path.

Dica: Para Secure Boot com suas próprias chaves, você pode configurar o serviço para também assinar a imagem usando sbsigntools:

ExecStart=/usr/bin/sbsign --key /caminho/para/bd.key --cert /caminho/para/bd.crt --output esp/EFI/arch/vmlinuz-linux /boot/vmlinuz-linux

Usando eventos do sistema de arquivos

Eventos de sistemas de arquivos podem ser usados para executar um script sincronizando o kernel EFISTUB após atualizações do kernel. Um exemplo com incron a seguir:

/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: O primeiro parâmetro /boot/initramfs-linux-fallback.img é o arquivo a ser observado. O segundo parâmetro IN_CLOSE_WRITE é a ação a ser observada. O terceiro parâmetro /usr/local/bin/efistub-update é o script a ser executado.

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

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

Para usar este método, habilite o incrond.service.

Usando hook do mkinitcpio

Mkinitcpio pode gerar um hook que não precisa de um daemon de nível de sistema para funcionar. Ele gera um processo de segundo plano que aguarda a geração de vmlinuz, initramfs-linux.img e initramfs-linux-fallback.img antes de copiar os arquivos.

Adicione efistub-update à lista de hooks em /etc/mkinitcpio.conf.

/etc/initcpio/install/efistub-update

#!/usr/bin/env bash
build() {
	/usr/local/bin/efistub-copy $$ &
}

help() {
	cat <<HELPEOF
This hook waits for mkinitcpio to finish and copies the finished ramdisk and kernel to the 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 "Synced /boot with ESP"

Usando predefinição de mkinitcpio

Como as predefinições em /etc/mkinitcpio.d/ possuem suporte a script shell, o kernel e initramfs podem ser copiados apenas editando as predefinições.

Substituindo o hook do mkinitcpio acima

Edite o arquivo /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}/"
[[ -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}/"

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"

Para testar isso, basta executar:

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

Outro exemplo

/etc/mkinitcpio.d/0.preset

ESP_DIR="esp/EFI/arch"
cp -af "/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.preset

source /etc/mkinitcpio.d/0.preset

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

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

Usando hook do pacman

Uma última opção depende dos hooks do pacman que são executados no final da transação.

O primeiro arquivo é um hook que monitora os arquivos relevantes e é executado se eles foram modificados na transação anterior.

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

[Trigger]
Type = Path
Operation = Install
Operation = Upgrade
Target = usr/lib/modules/*/vmlinuz
Target = usr/lib/initcpio/*
Target = boot/*-ucode.img

[Action]
Description = Copying linux and initramfs to EFI directory...
When = PostTransaction
Exec = /usr/local/bin/kernel-efi-copy.sh

O segundo arquivo é o próprio script. Crie o arquivo e torne-o executável:

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

#!/usr/bin/env bash
#
# Copy kernel and initramfs images to EFI directory
#

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 conhecidos

ESP no RAID

É possível tornar a ESP parte de uma matriz RAID1, mas isso traz o risco de corrupção de dados, e outras considerações precisam ser feitas ao criar a ESP. Veja [7] e [8] para detalhes e veja Inicialização com UEFI e RAID1 (em inglês) para um guia mais aprofundado com uma solução.

A parte principal é usar --metadata 1.0 para manter os metadados RAID no final da partição, caso contrário o firmware não poderá acessá-los:

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

Firmware não vê o diretório EFI

Se você der ao sistema de arquivos um nome de volume (com a opção -n), certifique-se de nomeá-lo como algo diferente de "EFI". Isso pode desencadear um bug em alguns firmwares (devido ao nome do volume que corresponde ao nome do diretório EFI) que fará com que o firmware atue como o diretório EFI não existe.

Veja também

A partição de sistema EFI e o comportamento de inicialização padrão