Entradas de boot UEFI e estado do Secure Boot no Linux e no Windows

Objetivo

Inspecionar e, quando necessário, reparar a lista de entradas de boot do firmware UEFI e confirmar o estado do Secure Boot num sistema Linux ou Windows que não inicia a partir do disco ou do loader esperado.

Pré-requisitos

Firmware UEFI (não BIOS legado); root no Linux ou prompt com privilégios elevados no Windows, a partir do sistema em execução, de uma mídia de recuperação ou da tela de configuração do firmware; no Linux, efivarfs montado (o normal em sistemas iniciados por UEFI).

Passos

1. Listar as entradas no Linux: efibootmgr -v mostra o número, o rótulo e o caminho de dispositivo de cada entrada, a BootOrder seguida pelo firmware e o BootCurrent, a entrada usada neste boot. Crie uma entrada com efibootmgr -c -d <disk> -p <partition> -L "<label>" -l '\EFI\<dir>\shimx64.efi' (-c também adiciona a nova entrada à BootOrder, normalmente no início), apague uma com efibootmgr -b <bootnum> -B e reordene com -o <bootnum>,<bootnum>,.... Cada alteração grava as variáveis do firmware imediatamente; não existe uma etapa separada para aplicar. Guarde antes a saída de -v, para poder restaurar a ordem antiga com -o.
2. Para testar uma nova entrada uma única vez, sem alterar a ordem, defina efibootmgr -n <bootnum> (BootNext); o firmware a usa só no próximo boot e depois volta à BootOrder.
3. No Windows, bcdedit /enum firmware lista as entradas do gerenciador de boot do firmware (distintas das entradas de OS loader de um simples bcdedit /enum); no PowerShell, coloque entre aspas identificadores como '{fwbootmgr}'. Normalmente o Windows recria a própria entrada com bcdboot <drive>:\Windows (com privilégios elevados), e não por edição direta.
4. Se o sistema inicia na configuração do firmware ou no SO errado depois de reinstalar o boot loader, a causa habitual é uma entrada ausente ou que não está em primeiro lugar na ordem; corrija com efibootmgr -o ou com a configuração de ordem de boot do firmware.
5. Verifique o Secure Boot antes de culpá-lo por uma falha de "not trusted": mokutil --sb-state no Linux; no Windows, Confirm-SecureBootUEFI num PowerShell elevado retorna $True ou $False e exibe "Cmdlet not supported on this platform" em BIOS ou em firmware sem suporte.
6. Com o Secure Boot ativado, a cadeia no Linux é: o firmware confia num shim assinado e o shim também confia em Machine Owner Keys (MOK). mokutil --import <key.der> pede uma senha de uso único e apenas deixa a chave preparada; no boot seguinte, o MokManager do shim pede no console a confirmação da inscrição com essa senha, portanto alguém precisa estar presente no console. Este artigo não trata da geração nem da assinatura de chaves.
7. Depois de qualquer alteração, reinicie e confirme com efibootmgr -v ou bcdedit /enum firmware que a ordem entrou em vigor.

Resultado esperado

A entrada pretendida está presente e em primeiro lugar na BootOrder; o estado do Secure Boot reportado corresponde ao que a carga de trabalho exige, de preferência ativado, com a chave de um módulo de terceiros inscrita via MOK, em vez de desligar o Secure Boot.

Limites e base de verificação

O efibootmgr edita a NVRAM diretamente: apagar a entrada errada tem efeito imediato, por isso confira os números de boot na saída de -v antes de usar -B. As implementações de firmware diferem na forma como tratam entradas adicionadas ou malformadas (algumas as descartam ou reordenam), por isso confirme o comportamento no hardware real.