efi mudanças na ordem de inicialização na atualização do pacote

Question

De vez em quando, depois de atualizar meu sistema, a ordem de inicialização do efi é alterada e o sistema não inicializa. Eu tenho que ir ao BIOS e selecionar novamente a entrada efi do ubuntu. Eu estou supondo que é um desses pacotes (pelo menos sempre acontece quando vejo um deles sendo atualizado):

grub-common grub-efi grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-
signed grub2-common shim shim-signed

Quando executo o efibootmgr, recebo isso:

efibootmgr
No BootOrder is set; firmware will attempt recovery

eu corri:

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
UEFI

Não consigo encontrar respostas para o efibootgmr que não esteja em execução. Por favor ajude. Obrigado!

Atualização:

Eu tentei adicionar uma variável de inicialização EFI com:

efibootmgr --create --disk /dev/sda --part 1 --label "Ubuntu" --loader
\EFI\ubuntu\grubx64.efi

Que retorna:

BootOrder: 0000
Boot0000* Ubuntu

Ao reiniciar, o sistema não inicializa.

Menu de inicialização

Agora, a entrada de trabalho é rotulada como Ubuntu. Quando eu seleciono o Ubuntu inicializa. Depois de executar novamente o efibootmgr, recebo o mesmo resultado de antes:

efibootmgr
No BootOrder is set; firmware will attempt recover

Caso seja relevante, shim e shim-signed também foram atualizados quando a ordem de inicialização foi alterada pela atualização.

Atualização:

O computador é um Gigabyte Brix GB-BXBT-1900 com a mais nova revisão da bios.

Acho que minha pergunta inicial foi por que o efigootmgr não está funcionando e que foi respondido. Obrigado pela sua contribuição.

    

Answer 1

Você está correndo para o que eu chamo de "golpe de inicialização". Eu escrevi uma página sobre este assunto; veja aqui para detalhes. Dito isso, seu problema parece um pouco incomum, mas provavelmente está relacionado a isso:

efibootmgr
No BootOrder is set; firmware will attempt recovery

Normalmente, um computador baseado em EFI possui um conjunto de variáveis BootOrder . Os casos em que eu pessoalmente vi onde não está definido foram por causa de um firmware defeituoso que simplesmente se recusa a aceitar essa variável. Nesses computadores, a única chance de inicialização é por meio de um nome de arquivo de fallback (normalmente EFI/BOOT/bootx64.efi no ESP, embora EFI/Microsoft/Boot/bootmgfw.efi às vezes funcione também). Dito isso, ouvi falar de casos em que a variável BootOrder está vazia, mas pode ser definida. Neste caso, adicionando uma variável de inicialização EFI, conforme descrito aqui, pode resolver o problema.

Se o seu computador estiver defeituoso e precisar inicializar por meio de um nome de arquivo de fallback, você deverá copiar ou mover / renomear o carregador de boot para o nome apropriado e possivelmente suportar arquivos como arquivos de configuração.

Dado que você se referiu à "entrada efi do ubuntu", acho que você tem variáveis de inicialização, mas a variável BootOrder está se perdendo. Este é provavelmente um erro de firmware, embora possa indicar um hardware NVRAM defeituoso. Atualizar o firmware pode resolver o problema, se for um erro. Verifique com o fabricante para ver se existe tal atualização. Se isso não ajudar, você poderá copiar o GRUB para o nome do arquivo de fallback, onde ele deverá ser chamado se / quando a variável BootOrder for perdida novamente. O ESP é normalmente montado em /boot/efi , e os comandos normais do sistema de arquivos Linux funcionam nele, então você pode fazer isso:

sudo cp -r /boot/efi/EFI/ubuntu /boot/efi/EFI/BOOT
sudo mv /boot/efi/EFI/BOOT/shimx64.efi /boot/efi/EFI/BOOT/bootx64.efi

Isso copia Shim para o nome do arquivo de fallback. Se tiver certeza de que seu computador não usa a Inicialização Segura, você poderá renomear grubx64.efi , em vez de shimx64.efi , para bootx64.efi .