18.04 LTS: проблема Двойной загрузки о Acer Swift 3 315-41

Я установил последнюю человечность со стандартной процедурой двойной загрузки вместе с предварительно установленным Windows.

Получающиеся разделы:

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.

Я настроил последовательность начальной загрузки в UEFI с человечностью (личинка) сначала.

Получающаяся конфигурация EFI:

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

На начальной загрузке личинка обычно разоблачает с опцией по умолчанию выбранную "человечность". Другая опция является "Windows Boot Manager".

человечность обычно запускается, и если я завершаю работу системы и перезапускаю позже, все продолжает работать. Но если я пытаюсь перезагрузить от человечности, "никакое устройство загрузки" экран не подходит, и я должен трудно закрыться с кнопкой питания. На следующем запуске Windows загрузится непосредственно (не проходя через личинку). Если я затем вхожу в BIOS UEFI, порядок загрузки инвертируется с Windows сначала. Я должен повторно инвертировать его для запуска человечности снова, которая является довольно раздражающей.

Fastboot был отключен в Windows. Когда я загружаю Windows от личинки и затем перезагрузки из Windows, машина поворачивается теперь обычно для расчистки. Таким образом, единственной вещью, не работающей, является перезагрузка от человечности.

То, что озадачивает меня, что efibootmgr не показывает разделу Boot0000 как вместо этого во всех примерах, которые я видел вокруг. Возможно, это не имеет никакого отношения к моей проблеме, но это - единственная разница, я вижу.

Я могу только принять, который на перезагрузке человечности, система пытается загрузить непосредственно от/dev/nvme0n1p5 (файловая система Linux), который не отмечен как загрузочный вообще. Но я не могу найти установку, которая влияет на это поведение.

Какие-либо другие идеи? Большое спасибо заранее.

Более подробная информация:

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# 

Мой grub.cfg

0
задан 24 June 2018 в 01:43

1 ответ

Кажется, существует обходное решение. Я должен указать параметр начальной загрузки ядра "reboot=pci". Для этого можно отредактировать/etc/default/grub:

GRUB_CMDLINE_LINUX="reboot=pci"

и личинка обновления:

sudo update-grub

Именно. Перезагрузка, кажется, длится довольно долго, но по крайней мере она работает.

Могло бы стоить зарегистрировать ошибку ядру Linux для причуды для добавления записи в reboot_dmi_table?

0
ответ дан 29 October 2019 в 03:56

Другие вопросы по тегам:

Похожие вопросы: