18.04 LTS: problema de arranque dual en Acer Swift 3 315-41

18.04 LTS: problema de arranque dual en Acer Swift 3 315-41

Instalé el último ubuntu con el procedimiento de arranque dual estándar junto con Windows preinstalado.

Las particiones resultantes son:

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.

Primero configuré la secuencia de arranque en UEFI con ubuntu (grub).

La configuración EFI resultante es:

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

Al arrancar, grub normalmente aparece con la opción predeterminada "ubuntu" seleccionada. Otra opción es el "Administrador de arranque de Windows".

Ubuntu se inicia normalmente y si apago el sistema y lo reinicio más tarde, todo sigue funcionando. Pero si intento reiniciar desde ubuntu, aparece una pantalla que dice "no hay dispositivo de arranque" y tengo que apagarlo con el botón de encendido. En el siguiente inicio, Windows arrancará directamente (sin pasar por grub). Si luego entro en UEFI Bios, el orden de inicio se invierte primero con Windows. Tengo que volver a invertirlo para poder iniciar Ubuntu nuevamente, lo cual es bastante molesto.

Fastboot se ha deshabilitado en Windows. Cuando inicio Windows desde grub y luego reinicio desde Windows, la máquina ahora pasa normalmente a grub. Entonces lo único que no funciona es reiniciar desde ubuntu.

Lo que me desconcierta es que efibootmgr no muestra una partición Boot0000 como en todos los ejemplos que he visto. Quizás no tenga nada que ver con mi problema, pero veo que es la única diferencia.

Solo puedo suponer que al reiniciar Ubuntu, el sistema intenta arrancar directamente desde /dev/nvme0n1p5 (el sistema de archivos de Linux), que no está marcado como de arranque en absoluto. Pero no puedo encontrar ninguna configuración que influya en este comportamiento.

¿Alguna otra idea? Muchas gracias de antemano.

Más detalles:

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# 

Mi comida.cfg

Respuesta1

Parece haber una solución. Necesito especificar el parámetro de arranque del kernel "reboot=pci". Para hacerlo, puedes editar /etc/default/grub:

GRUB_CMDLINE_LINUX="reboot=pci"

y actualiza grub:

sudo update-grub

Eso es todo. El reinicio parece durar bastante, pero al menos funciona.

Podría valer la pena presentar un error en el kernel de Linux por una peculiaridad para poder agregar una entrada alreiniciar_dmi_table?

información relacionada