Que executáveis UEFI são detectados automaticamente?

Question

De acordo com esta visão geral fenomenal da UEFI , existem 3 tipos de entradas de UEFI:

• Compatibility-boot inicializa o que estiver no início do disco, como o BIOS fez
• Inicialização nativa inicializa um executável EFI a partir de um caminho explícito
• O bootbackback inicializará um executável EFI de vários locais padrão (com base na arquitetura, /EFI/BOOT/BOOTx64.efi , /EFI/BOOT/BOOTaa64.efi , etc.)

Tudo isso faz sentido, mas quando eu olho para uma partição do sistema EFI de um sistema operacional (CentOS, neste caso), existem muito mais arquivos .efi .

+--EFI
|  +--boot
|  |  +--BOOTAA64.EFI
|  |  \--fallback.efi
|  +--centos
|  |  +--gcdaa64.efi
|  |  +--grubaa64.efi
|  |  +--MokManager.efi
|  |  +--shim-centos.efi
|  |  \--shim.efi

Além disso, o gerenciador de inicialização lista apenas uma opção para inicializar /EFI/centos/shim.efi . Este disco do CentOS veio de outro computador, então o firmware nesta máquina nunca teve uma entrada explícita adicionada para shim.efi .

Por que existem tantos arquivos .efi ?

Como o gerenciador de inicialização encontrou shim.efi ?

Por que o gerenciador de inicialização não encontrou todos os outros arquivos .efi ?

Esta questão é semelhante , mas é mais sobre a distinção entre o fallback e o boot nativo.

    

Answer 1

Why are there so many .efi files?

A maioria desses arquivos são arquivos de suporte. Por exemplo, o MokManager é uma ferramenta para gerenciar MOKs (Machine Owner Keys), que são usadas pelo Shim para expandir o número de chaves de inicialização segura que o computador reconhece. O MokManager é normalmente chamado se o Shim não puder iniciar seu gerenciador de inicialização padrão (normalmente o GRUB). Parece que você tem pelo menos duas cópias do Shim em EFI/centos ( shim.efi e shim-centos.efi ), e EFI/boot/BOOTAA64.EFI é provavelmente uma terceira cópia do Shim. As chances são de que uma delas em EFI/centos seja redundante - talvez tenha sido deixada de uma instalação anterior que usou um nome diferente ou foi criada por acidente.

Os desenvolvedores de Linux também criaram o hábito de criar novos arquivos de programa EFI para solucionar problemas ou problemas de casos especiais. Por exemplo, sua instalação mostra duas cópias do GRUB no diretório EFI/centos - grubaa64.efi e gcdaa64.efi são idênticas, exceto para onde eles procuram por seus arquivos de configuração e suporte. (Veja esta pergunta e resposta do Stack Exchange por um pouco mais sobre esta questão.)

How did the boot manager find shim.efi?

Você já respondeu (parcialmente) a essa pergunta - no que você chamou de "inicialização nativa", o computador armazena um caminho para o carregador de inicialização em uma variável NVRAM. A maioria das distribuições Linux atualmente usa o Shim por padrão, então a variável NVRAM apontará para um binário Shim. Quando Shim for lançado, ele se registrará com o firmware e, em seguida, iniciará um carregador de inicialização (normalmente GRUB).

Why didn't the boot manager find all the other .efi files?

Um gerenciador de boot EFI padrão não verifica ativamente arquivos .efi , exceto o nome do arquivo de fallback e, em alguns EFIs, o carregador de inicialização da Microsoft. (Há outros que podem ser adicionados à lista de inicialização em alguns casos, como entradas de inicialização de rede e entradas para um shell EFI interno.)

Em vez disso, a maioria das EFIs confia no instalador do sistema operacional para registrar um carregador de boot como parte do processo de instalação do carregador de boot. Assim, o CentOS gravará Shim, GRUB e os binários .efi relacionados ao ESP e, em seguida, incluirá uma ou mais entradas NVRAM para apontar para elas. Em teoria, um sistema operacional poderia armazenar dez, cem, mil ou mais arquivos .efi no ESP e registrar apenas um deles. Quando você reiniciar e acertar qualquer tecla que seja necessária para entrar no gerenciador de inicialização EFI, você verá apenas a entrada que o instalador do sistema operacional adicionou. Você pode adicionar, excluir ou editar essas entradas com a ferramenta efibootmgr na maioria das distribuições do Linux.

AFAIK, as únicas ferramentas que procuram ativamente por carregadores de inicialização EFI são:

• rEFIt - Esse gerenciador de inicialização antigo era usado principalmente em Macs, mas pode ser usado em sistemas baseados em UEFI. PCs. Ele procura ativamente por carregadores de inicialização na maioria dos subdiretórios de EFI (ou seja, EFI/centos/ , EFI/BOOT/ , etc.), sendo EFI/tools/ uma exceção notável. Observe que o rEFIt não está mais sendo mantido.
• rEFInd - Esta é a minha bifurcação atualizada do rEFIt, e herda o algoritmo de varredura ativa do rEFIt, com alguns ajustes para que funcione melhor com o Linux e para editar explicitamente entradas de inicialização redundantes ou desnecessárias. Assim, o rEFInd mostra os dois .efi binários e os kernels do Linux (que na maioria dos casos são arquivos de programa EFI, graças ao Carregador de topo EFI ).
• Scripts de configuração do GRUB 2 - As distribuições que dependem do GRUB 2 geralmente são fornecidas com scripts que varrem por .efi arquivos e os adicionam ao menu GRUB. Ao contrário de rEFIt e rEFInd, no entanto, essas verificações ocorrem quando o Linux (ou algum outro sistema operacional host) está em execução, não no momento da inicialização.

Observe que nenhuma dessas ferramentas afeta o que aparece no próprio menu do gerenciador de inicialização da EFI; todos eles afetam o que aparece em seus próprios menus, nada mais. Em teoria, outras ferramentas podem realizar essas varreduras. Um EFI poderia fazer tais varreduras, seja em cada inicialização ou após o comando do usuário, mas na prática eu não sei de nenhum que faça isso; AFAIK, todas as EFIs dependem de seus próprios gerenciadores de inicialização com entradas NVRAM associadas. (Alguns têm bugs, o que faz com que essas entradas na NVRAM não sejam confiáveis, fazendo com que o nome do arquivo de retorno seja uma necessidade prática.)