EFI system partition (Portuguê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: gptse a tabela de partições for GPT ouTipo de rótulo do disco: dosse 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 EFIouEFI (FAT-12/16/32). Para confirmar isso é a ESP, monte e verifique se ela contém um diretório chamadoEFI, se contiver é definitivamente a ESP.
minfo a partir de mtools.
# minfo -i /dev/sdxY :: | grep 'disk type'
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).
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
fat32como o tipo de sistema de arquivos e defina a opçãoespnela.
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
fat32como o tipo de sistema de arquivos e defina a opçãoespnela.
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
/efie 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.
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/
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.
/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.
- 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.
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/
/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.