18.04 LTS: problema de inicialização dupla no Acer Swift 3 315-41

18.04 LTS: problema de inicialização dupla no Acer Swift 3 315-41

Instalei o Ubuntu mais recente com o procedimento de inicialização dupla padrão junto com o Windows pré-instalado.

As partições resultantes são:

Disk /dev/nvme0n1: 238.5 GiB, 256060514304 bytes, 500118192 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: 1FD93AC5-481F-46E4-8743-4C1B0493E4D3

Device             Start       End   Sectors   Size Type
/dev/nvme0n1p1      2048    206847    204800   100M EFI System
/dev/nvme0n1p2    206848    239615     32768    16M Microsoft reserved
/dev/nvme0n1p3    239616 217887637 217648022 103.8G Microsoft basic data
/dev/nvme0n1p4 498020352 500117503   2097152     1G Windows recovery environment
/dev/nvme0n1p5 217888768 498020351 280131584 133.6G Linux filesystem

Partition table entries are not in disk order.

Configurei primeiro a sequência de inicialização no UEFI com o Ubuntu (grub).

A configuração EFI resultante é:

Timeout: 0 seconds
BootOrder: 0001,0002,2001,2002,2003
Boot0001* ubuntu
Boot0002* Windows Boot Manager
Boot2001* EFI USB Device
Boot2002* EFI DVD/CDROM
Boot2003* EFI Network

Na inicialização, o grub normalmente aparece com a opção padrão "ubuntu" selecionada. Outra opção é o "Gerenciador de inicialização do Windows".

O Ubuntu inicia normalmente, e se eu desligar o sistema e reiniciar mais tarde, tudo continua funcionando. Mas se eu tentar reiniciar a partir do Ubuntu, uma tela "sem dispositivo de inicialização" aparecerá e eu terei que desligar com o botão liga / desliga. Na próxima inicialização, o Windows inicializará diretamente (sem passar pelo grub). Se eu entrar no UEFI Bios, a ordem de inicialização será invertida primeiro com o Windows. Eu tenho que reinvertê-lo para iniciar o Ubuntu novamente, o que é bastante chato.

Fastboot foi desativado no Windows. Quando eu inicializo o Windows a partir do grub e depois reinicio a partir do Windows, a máquina agora passa normalmente para o grub. Então a única coisa que não funciona é reiniciar do Ubuntu.

O que me intriga é que o efibootmgr não mostra uma partição Boot0000 como em todos os exemplos que vi por aí. Talvez não tenha nada a ver com o meu problema, mas é a única diferença, pelo que vejo.

Só posso assumir que, na reinicialização do Ubuntu, o sistema tenta inicializar diretamente de /dev/nvme0n1p5 (o sistema de arquivos Linux), que não está marcado como inicializável. Mas não consigo encontrar nenhuma configuração que influencie esse comportamento.

Alguma outra ideia? Muito obrigado antecipadamente.

Detalhes adicionais:

root@JensNewLap:/boot/efi/EFI# ls -la
insgesamt 7
drwx------ 7 root root 1024 Jun  9 13:02 .
drwx------ 4 root root 1024 Jan  1  1970 ..
drwx------ 2 root root 1024 Jun 13 19:25 Boot
drwx------ 2 root root 1024 Jun  9 13:02 Insyde
drwx------ 4 root root 1024 Mär 28 15:48 Microsoft
drwx------ 4 root root 1024 Jun 10 15:50 OEM
drwx------ 3 root root 1024 Jun  6 23:33 ubuntu
root@JensNewLap:/boot/efi/EFI# ls Boot/
bootx64.efi  fbx64.efi
root@JensNewLap:/boot/efi/EFI# ls Insyde
root@JensNewLap:/boot/efi/EFI# ls Microsoft
Boot  Recovery
root@JensNewLap:/boot/efi/EFI# ls OEM
Boot  Recovery
root@JensNewLap:/boot/efi/EFI# ls ubuntu
BOOTX64.CSV  fw  fwupx64.efi  grub.cfg  grubx64.efi  mmx64.efi  shimx64.efi
root@JensNewLap:/boot/efi/EFI# 

Meu grub.cfg

Responder1

Parece haver uma solução alternativa. Preciso especificar o parâmetro de inicialização do kernel "reboot=pci". Para fazer isso, você pode editar /etc/default/grub:

GRUB_CMDLINE_LINUX="reboot=pci"

e atualize o grub:

sudo update-grub

É isso. A reinicialização parece durar bastante, mas pelo menos funciona.

Pode valer a pena registrar um bug no kernel do Linux por uma peculiaridade, a fim de adicionar uma entrada aoreboot_dmi_table?

informação relacionada