Em uma inicialização EFI, os boot loaders são arquivos comuns em uma partição conhecida como EFI System Partition (ESP) . Esses arquivos podem, em princípio, ser armazenados sob qualquer nome de arquivo em qualquer local em qualquer ESP. (Você pode ter vários ESPs.) Assim, uma EFI armazena informações sobre o carregador de inicialização a ser usado na NVRAM. Parece que sua entrada NVRAM para o Ubuntu foi perdida ou danificada.
Uma possível causa desse problema é se o disco estiver desconectado; algumas EFIs procuram carregadores de boot descritos na NVRAM e, se uma entrada descreve um arquivo inexistente, exclua essa entrada. Isso é bom na maioria das vezes, mas se você desconectar um disco, qualquer carregador de inicialização que ele contiver ficará inacessível da próxima vez que você inicializar o computador. Você não mencionou a desconexão do disco externo contendo o Ubuntu quando fez a atualização, mas essa prática é bastante comum, então não posso deixar de pensar que você pode ter feito isso, e seu firmware, portanto, excluiu a entrada relevante.
Se esta foi a causa, há várias soluções:
-
Recriar a entrada antiga - Você pode usar EasyUEFI no Windows ou
efibootmgrno Ubuntu para recriar sua entrada antiga da NVRAM. Em ambos os casos, você precisará localizar o GRUB antigo e informar ao utilitário onde encontrá-lo. Isso será mais fácil com o EasyUEFI, que é uma ferramenta GUI;efibootmgré um programa de linha de comando. Você precisará identificar seu (s) ESP (s) e descobrir em qual deles o GRUB reside. Os ESPs são partições FAT, portanto, você deve usar o GParted,parted,blkidou alguma ferramenta semelhante (no Ubuntu; ou equivalentes no Windows) para identificar os candidatos ao ESP e localizar o GRUB. Em qualquer disco, o ESP é geralmente (mas nem sempre) a primeira ou a segunda partição. Observe que, se o GRUB tiver uma entrada para o Windows, uma vez que se torne o padrão, você poderá selecionar o Windows no menu GRUB. OTOH, se o GRUB estiver em seu disco externo, desconectá-lo poderá recriar seu problema atual. -
Renomear GRUB - Em vez de recriar a entrada NVRAM, você pode ignorá-la, dando ao GRUB o nome de arquivo "fallback" de
EFI/BOOT/bootx64.efi. Esse nome de arquivo é usado em mídias removíveis como instaladores de SO, a idéia é que o firmware precisa de um nome de arquivo padronizado para inicializar a partir de discos removíveis que nunca foram usados antes. Se você der ao GRUB o nome do arquivo de fallback, seu computador deve ser capaz de inicializar o GRUB a partir do disco externo como se fosse um instalador do SO. Você precisará usar o gerenciador de boot interno do seu firmware (como você parece estar fazendo até agora) para selecionar o sistema operacional a ser inicializado. - Use um gerenciador de inicialização mais flexível no disco rígido - Você pode instalar um gerenciador de inicialização que procure ativamente por carregadores de inicialização disponíveis em seu disco rígido. Eu sei de dois que fazem isso: o agora abandonado rEFIt e meu fork atualmente mantido, rEFInd. Se você instalar um desses no ESP do seu disco rígido interno, ele deverá detectar e permitir que você inicie o GRUB (ou até mesmo seus kernels Linux diretamente, no caso de rEFInd) no seu disco externo. Você pode testar o rEFInd usando a versão da unidade flash USB ou do CD-R e, se funcionar, instale o rEFInd no ESP do seu disco interno.
Algumas dessas soluções podem funcionar mesmo se eu tiver diagnosticado mal a causa do seu problema, mas isso realmente depende do problema real. Uma questão crítica é: Onde o GRUB está instalado? Se estiver no mesmo ESP que o carregador de inicialização do Windows, a causa provavelmente é algo diferente do que eu estou especulando, e você pode configurar esse GRUB como o principal programa de inicialização e deve funcionar muito bem. Se o GRUB estiver em um ESP separado no disco externo, você terá que prestar muita atenção em qual ESP é que não importa o que você faça.