EFI system partition (Português)

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.
Artigos relacionados
Unified Extensible Firmware Interface
Gerenciador de boot
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/sd
x
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/sd
xY
:: | 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/sd
xY
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/sda
X
/dev/sdb
Y
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