A solução simples é desativar a Inicialização Segura, conforme descrito em esta página minha. Para ter certeza, é melhor executar com o Secure Boot ativado, mas se o recurso não estiver funcionando como planejado, é uma responsabilidade.
Para diagnósticos mais completos, recomendo que você comece examinando as entradas de inicialização do EFI digitando sudo efibootmgr -v , como em:
$ sudo efibootmgr -v
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0003,0007,0001
Boot0000* rEFInd Boot Manager HD(2,1f4800,82000,5f6b4992-fcfe-4a2c-9e67-98b0a30dfe7d)File(\EFI\refind\refind_x64.efi)
Boot0001* Lenovo Recovery System HD(3,276800,1f4000,de3b7563-97f5-48c6-ab7f-2f5d6d57c644)File(\EFI\Microsoft\Boot\LrsBootMgr.efi)RC
Boot0003* ubuntu HD(2,1f4800,82000,5f6b4992-fcfe-4a2c-9e67-98b0a30dfe7d)File(\EFI\ubuntu\shimx64.efi)RC
Boot0007* Windows Boot Manager HD(2,1f4800,82000,5f6b4992-fcfe-4a2c-9e67-98b0a30dfe7d)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
Verifique a linha BootOrder e examine cada uma das entradas especificadas na ordem. Por exemplo, neste exemplo, 0000 é o primeiro e Boot0000 lança o rEFInd. O que você deve examinar com mais detalhes é o arquivo que é lançado, como \EFI\refind\refind_x64.efi para o Boot0000 deste exemplo. No caso de uma inicialização padrão do Ubuntu Secure Boot, o arquivo deve ser shimx64.efi , o que obviamente não é o caso do Boot0000 - mas é verdadeiro para o próximo boot deste exemplo entrada, Boot0003 .
Este exemplo provavelmente produziria um aviso de Inicialização Segura como você descreve na maioria dos computadores, mas após esse aviso, o GRUB e o Ubuntu podem ser iniciados, desde quando Boot0000 falhou, o sistema passaria para Boot0003 , que < em> deve ter sucesso. É possível que algo assim esteja acontecendo com você, mas provavelmente está iniciando grubx64.efi primeiro e, em seguida, não é possível continuar ou shimx64.efi pode não ter uma entrada. Se esse for o seu caso, você poderia ajustar a ordem de inicialização com a opção -o para efibootmgr ou criar uma nova entrada totalmente. Os detalhes dependem do que você vê de efibootmgr -v e do que está realmente instalado em seu disco rígido.
Se a sua saída efibootmgr -v mostrar que o computador deve iniciar shimx64.efi primeiro, então recomendo que você compare esse arquivo com o arquivo EFI/BOOT/bootx64.efi na mídia de instalação do Ubuntu que faz inicializar. Verifique os tamanhos dos arquivos com ls -l e verifique se eles são idênticos a diff ; por exemplo:
diff /mnt/cd-media/EFI/BOOT/bootx64.efi /mnt/esp/EFI/ubuntu/shimx64.efi
(Os pontos de montagem provavelmente serão diferentes, é claro). Esses arquivos devem ser idênticos, o que diff indica ao não fornecer saída. Se não estiverem, você pode tentar sobrescrever shimx64.efi no disco rígido com bootx64.efi da mídia de instalação. Se os dois arquivos não são idênticos por causa de uma atualização de pacote, isso seria uma causa para preencher um relatório de bug. Eles podem não ser idêntico, por algum outro motivo, como corrupção de disco ou um erro (muito raro) ao copiar arquivos.
Se os arquivos são idênticos, mas a mídia externa inicializa e o disco rígido não, então isso provavelmente significa que você tem uma EFI com bugs. Você pode procurar por uma atualização no site do fabricante. (Eles provavelmente o chamam de "atualização do BIOS", embora não seja realmente um BIOS.) Se isso não ajudar, você pode tentar preencher um relatório de bug com o fabricante.