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.

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

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

Discos particionados em GPT

Partição de sistema EFI em uma Tabela de Partição GUID é identificada pelo GUID de tipo de partição .

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 como o tipo de sistema de arquivos e defina a opção 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 .

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 como o tipo de sistema de arquivos e defina a opção 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. 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, recomenda-se usar o FAT32.

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

# mkfs.fat -F32 /dev/sdxY

Se você receber a mensagem , reduza o tamanho do cluster com ou ; caso contrário, a partição pode ser ilegível pelo UEFI. Veja 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:

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

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

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 ). Isto permite que pacman atualize o kernel diretamente enquanto mantém a ESP organizada ao seu gosto.

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:

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

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

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:

Para usar este método, habilite o .

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 , initramfs-linux.img e initramfs-linux-fallback.img antes de copiar os arquivos.

Adicione à lista de hooks em .

Usando predefinição de mkinitcpio

Como as predefinições em 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
# 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/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.

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

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 e 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 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 ), 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

gollark: A PCIe 4 SSD is probably overkill.
gollark: There are simple programming languages where you can at least learn the syntax pretty trivially. But *natural* spoken languages are all horrible deranged messes which make no sense.
gollark: Did you check what the BIOS says about boot options or whatever?
gollark: That gets the last one.
gollark: That's slicing. The first thing is the place in the list to start, the second one is where to end, and the third one is the "step" or something.
This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.