EFI system partition (Português) - ArchWiki

# EFI system partition (Português)

From ArchWiki
Jump to navigation Jump to search
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/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

Category:

- Boot process (Português)