Por que o initramfs está caindo para um shell depois de instalar o Ubuntu ao lado de uma instalação do Windows 10?

Question

Instalei o Ubuntu 18.04 LTS via Live USB em um ASUS Zenbook 13 UX331UN que é fornecido com um Windows 10. pré-instalado. É um sistema UEFI com inicialização segura ativada e inicialização rápida desativada. Eu estou aqui sentado há dias tentando fazer o boot do Ubuntu, mas sem sucesso.

fdisk -lu me fornece o seguinte layout de partição

Disk /dev/sda: 477 GiB, 512110190592 bytes, 1000215216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 94F7C923-6092-46D5-AFD6-38F3F4F6096F

Device         Start        End   Sectors   Size Type
/dev/sda1       2048     534527    532480   260M EFI System
/dev/sda2     534528     567295     32768    16M Microsoft reserved
/dev/sda3     567296  946147327 945580032 450.9G Microsoft basic data
/dev/sda4  998576128 1000214527   1638400   800M Windows recovery environment
/dev/sda5  946147328  998576127  52428800    25G Linux filesystem

Partition table entries are not in disk order.

O arquivo boot/grub/grub.cfg criado pelo instalador do Ubuntu contém a seguinte entrada no menu para inicializar o Ubuntu

menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-97209f84-060d-4e49-a790-e9af75f2dc40' {
    ...
    set root='hd0,gpt5'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt5 --hint-efi=hd0,gpt5 --hint-baremetal=ahci0,gpt5  97209f84-060d-4e49-a790-e9af75f2dc40
    else
      search --no-floppy --fs-uuid --set=root 97209f84-060d-4e49-a790-e9af75f2dc40
    fi
    linux   /boot/vmlinuz-4.15.0-20-generic.efi.signed root=/dev/sda5 ro  quiet splash $vt_handoff
    initrd  /boot/initrd.img-4.15.0-20-generic
}

mas resulta em

ALERT! /dev/disk/by-uuid/97209f84-060d-4e49-a790-e9af75f2dc40 does not exist. Dropping to a shell
initramfs:_

Eu tentei várias correções possíveis, incluindo reinstalação do grub, reparo de inicialização, alteração manual do EFI, mas ... nada.

Como último recurso, tentei inicializar o Ubuntu a partir do prompt do grub manualmente, conforme descrito em muitos tutoriais por aí com os seguintes comandos

set root=(hd0,5)
linux   /vmlinuz root=/dev/sda5 ro
initrd  /initrd.img
boot

e ... tada, inicializa com sucesso.

Então eu adotei esses comandos no grub.cfg e agora a entrada do menu se parece com isso

menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-97209f84-060d-4e49-a790-e9af75f2dc40' {
    ...
    set root=(hd0,5)
    linux   /vmlinuz root=/dev/sda5 ro quiet splash
    initrd  /initrd.img
}

Com esta configuração de entrada, o Ubuntu é inicializado com sucesso.

É uma abordagem válida para alterar o grub.cfg dessa maneira? Eu tenho que enfrentar possíveis efeitos colaterais por essas mudanças e por que o Ubuntu não pode criar um grub.cfg em funcionamento?

Atualização 1

Acho que encontrei o culpado.

Primeiramente, o UUID está errado, como já foi apontado por Gilles, por isso eu reverti para o original grub.cfg e mudei todas as ocorrências de 97209f84- para 44ada74f- . Mas ainda com essa mudança, ele não está inicializando, pois ainda recebo um prompt caindo para um shell . Para verificar um problema de UUID , eu reinstalei o Ubuntu, agora o UUID é diferente (como é gerado quando uma partição é formatada até onde eu sei), mas agora o grub.cfg declara o UUID de% correto código%. Muito estranho. Então, o /dev/sda5 claramente não é o problema.

Em segundo lugar, substituí UUID por set root='hd0,gpt5' , mas isso também não faz diferença. Na terceira tentativa, alterei o nome do arquivo no comando set root=(hd0,5) de linux para /boot/vmlinuz-4.15.0-20-generic.efi.signed e ... agora é inicializado.

Após verificar com sucesso a existência do arquivo /boot/vmlinuz-4.15.0-20-generic , agora acho que o sistema não confia nele de acordo com a resposta desta pergunta: link

Alguma idéia de por que /boot/vmlinuz-4.15.0-20-generic.efi.signed não está funcionando?