Устранение неполадок безопасной загрузки

Простое решение состоит в том, чтобы отключить Защищенную загрузку, как описано на этой моей странице. Безусловно, лучше работать с включенной Защищенной загрузкой, но если функция не работает, как разработано, это - ответственность.

Для более полной диагностики я рекомендую запустить путем исследования записей загрузки EFI путем ввода sudo efibootmgr -v, как в:

$ sudo efibootmgr -v
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0003,0007,0001
Boot0000* rEFInd Boot Manager   HD(2,1f4800,82000,5f6b4992-fcfe-4a2c-9e67-98b0a30dfe7d)File(\EFI\refind\refind_x64.efi)
Boot0001* Lenovo Recovery System    HD(3,276800,1f4000,de3b7563-97f5-48c6-ab7f-2f5d6d57c644)File(\EFI\Microsoft\Boot\LrsBootMgr.efi)RC
Boot0003* ubuntu    HD(2,1f4800,82000,5f6b4992-fcfe-4a2c-9e67-98b0a30dfe7d)File(\EFI\ubuntu\shimx64.efi)RC
Boot0007* Windows Boot Manager  HD(2,1f4800,82000,5f6b4992-fcfe-4a2c-9e67-98b0a30dfe7d)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................

Проверьте BootOrder строка и исследует каждую из записей, указанных в порядке. Например, в этом примере, 0000 является первым, и Boot0000 запуски повторно находят. Что необходимо исследовать, более подробно файл, это запускается, такой как \EFI\refind\refind_x64.efi для этого примера Boot0000. В случае стандартного запуска Защищенной загрузки Ubuntu файл должен быть shimx64.efi, который, конечно, не имеет место для этого примера Boot0000 - но это верно для следующей записи загрузки этого примера, Boot0003.

Этот пример, вероятно, произвел бы Защищенную загрузку, предупреждающую, такую как, Вы описываете на большинстве компьютеров, но после того, как то предупреждение, GRUB и Ubuntu могли бы запуститься, с тех пор когда Boot0000 неудавшийся, система шла бы дальше к Boot0003, который должен успешно выполниться. Возможно, что что-то вроде этого происходит с Вами - но это, вероятно, запускается grubx64.efi во-первых и затем или отказ идти дальше или shimx64.efi не мог бы иметь записи. Если это верно, для Вас, Вы могли настроить порядок загрузки с -o опция к efibootmgr или создайте новую запись полностью. Детали зависят от того, от чего Вы видите efibootmgr -v и что на самом деле установлено на Вашем жестком диске, все же.

Если Ваш efibootmgr -v вывод показывает, что компьютер должен запускаться shimx64.efi во-первых, затем я рекомендую сравнить тот файл с EFI/BOOT/bootx64.efi файл на установочном носителе Ubuntu, которые действительно загружаются. Проверьте их размеры файла с ls -l и проверьте, идентичны ли они с diff; например:

diff /mnt/cd-media/EFI/BOOT/bootx64.efi /mnt/esp/EFI/ubuntu/shimx64.efi

(Точки монтирования, вероятно, будут отличаться, конечно.) Эти файлы должны быть идентичными, который diff указывает, не обеспечивая вывода. Если они не, Вы могли бы попытаться перезаписать shimx64.efi на жестком диске с bootx64.efi из носителя установки. Если бы эти два файла не идентичны из-за обновления пакета, которое было бы причиной для регистрации отчета об ошибках. Они не могли бы быть идентичными по некоторой другой причине, тем не менее, как дисковое повреждение или (очень редкая) ошибка при копировании файлов.

Если файлы идентичны, но внешние средние начальные загрузки и жесткий диск не делают, то это, вероятно, означает, что у Вас есть ошибочный EFI. Вы могли бы искать обновление на веб-сайте своего производителя. (Они, вероятно, называют это "обновлением BIOS", хотя это - действительно не BIOS.), Если это не помогает, Вы могли бы попытаться регистрировать отчет об ошибках с производителем.