Grub зависает при естественной загрузке, но работает, если выбран из меню EFI

Question 1

Отсюда:

Установка сертификата

Вы можете установить файл ключевого файла example.key и файл сертификата example.crt или файл сертификата, выданный вашим ЦС, путем запуска следующие команды в командной строке терминала:

sudo cp example.crt /etc/ssl/certs
sudo cp example.key /etc/ssl/private

Теперь просто настройте любые приложения с возможностью использования криптографии с открытым ключом, чтобы использовать сертификат и файлы ключей. Например, Apache может предоставлять HTTPS, Dovecot может предоставлять IMAPS и POP3S и т. Д.

Question 2

У меня была такая же проблема на той же аппаратной модели. Как отмечал оригинальный плакат, проблема исчезает после применения обновления. К сожалению, проблема снова появляется. Исправление состоит в том, чтобы отключить безопасную загрузку, следуя инструкциям на этой странице: https://support.hp.com/us-en/document/c04784866

Question 3

Question 4

Казалось бы, проблема заключается в нескольких установках несоответствия GRUB. GRUB, установленный на /EFI/ubuntu/grubx64.efi, не работает, в то время как GRUB установлен на /EFI/Boot/bootx64.efi.

Вы должны исправить это, переустановив GRUB на ESP.

sudo grub-install --efi-directory = / boot / efi / dev / sda

Question 5

К сожалению, Boot Repair не правильно обрабатывает диски NVMe, поэтому в вашем отчете BootInfo отсутствует куча важной информации; однако он показывает одну запись ubuntu в списке диспетчера загрузки NVRAM, поэтому маловероятно, что система загружается через какой-либо другой путь - ИСКЛЮЧАЕТ, что у вас есть резервный загрузчик (EFI/BOOT/bootx64.efi), который от другого файл в этом каталоге (fbx64.efi), вероятно, является инструментом для восстановления настроек загрузки в случае сбоя прошивки. Этот инструмент, как его настроить и использовать, описан в моей документации rEFInd (хотя он не является частью rEFInd, эта страница имеет самое полное и краткое описание fbx64.efi, о котором я знаю):

http://www.rodsbooks.com/refind/bootcoup.html#fallback

Возможно, ваш компьютер потеряет свою загрузочную переменную порядка, загрузив через Shim (как EFI/BOOT/bootx64.efi) и fbx64.efi, который затем загружает процесс загрузки в обычную запись ubuntu (которая запускает второй Shim, а затем GRUB), который затем зависает; но когда запись ubuntu запускается напрямую, она работает нормально. Это может произойти из-за ошибок, связанных с запуском двух копий Shim, потому что сам fbx64.efi вызывает проблемы или по какой-то другой причине. Эта гипотеза очень спекулятивна; это основано на очень мало доказательств и немало предположений. Он также предполагает ошибки в вашей прошивке и, вероятно, в Shim, fbx64.efi и / или GRUB. Это согласуется с симптомами, которые вы видите, и это единственное объяснение, которое приходит на ум. Если это то, что происходит, вы можете попробовать как диагностические процедуры или устранить проблему:

Переименуйте каталог EFI/BOOT в ESP. Если вы переименуете этот каталог, и проблема будет сохраняться точно так, как она есть, то моя гипотеза неверна. (Это связано с тем, что переименование EFI/BOOT не позволит компьютеру пытаться запустить Shim и fbx64.efi, хранящиеся в этом каталоге, поэтому, если он продолжает загружаться, должно быть, что порядок загрузки и загрузочные переменные сохраняются и соблюдаются, наоборот к моей гипотезе.) Если, однако, компьютер начинает правильно загружаться или загружается прямо в Windows, то это свидетельствует о том, что он загружался таким образом, и моя гипотеза становится гораздо более вероятной. Вы должны иметь возможность переименовать каталог обратно в EFI/BOOT, чтобы восстановить загрузочную операцию (failing), которая будет необходима для следующих трех ремонтов .... Отключить Безопасную загрузку - Отключение Secure Boot изменит способ работы Shim, и если моя гипотеза верна, это может заставить все работать - или это может не иметь никакого эффекта. Даже если моя гипотеза верна, это изменение будет работать только в том случае, если отказ вызван Secure Boot, чего может и не быть. Скопируйте EFI/ubuntu/grub* в EFI/BOOT. Если вы скопируете GRUB (grubx64.efi) и его файл конфигурации (grub.cfg) с EFI/ubuntu на EFI/BOOT, затем Shim в EFI/BOOT (то есть EFI/BOOT/bootx64.efi ) должен запускать GRUB непосредственно из EFI/BOOT, а не проходить через fbx64.efi. Это должно обойти проблему, если моя гипотеза правильная. Используйте rEFInd. Мой менеджер загрузки rEFInd загружается совсем по-другому из GRUB, поэтому вероятность того, что проблема не будет затронута этой проблемой. Однако, если активна Secure Boot, вам нужно зарегистрировать ключ или два в списке MOK, как описано в документации rEFInd Secure Boot. Кроме того, вам может потребоваться удалить или переименовать файл EFI/ubuntu/BOOTX64.CSV в ESP. (Переименуйте его на что-то с именем файла, которое не заканчивается на .CSV, или любым измененным в зависимости от случая вариантом, например .csv.) Причина в том, что fbx64.efi ищет файлы .CSV для восстановления NVRAM- основанный на загрузке, поэтому, если этот файл присутствует, вероятность 50/50 будет иметь приоритет над файлом BOOT.CSV, который создает rEFInd для себя, тем самым заставляя систему загружаться в GRUB и продолжать сбой в том, как вы описываете. Обновите свою прошивку. Если ваш производитель предлагает новую прошивку (возможно, называемую «BIOS»), чем то, что вы используете сейчас, вы можете ее обновить. Это выстрел в темноте; ваша проблема звучит достаточно экзотично, что вряд ли она будет исправлена в обновлении прошивки.

Я рекомендую вам попробовать первый из этих параметров в качестве диагностики. Если поведение загрузки изменяется, как я описал, вы можете восстановить EFI/BOOT так, как он был, и попробовать любой из следующих трех параметров - или более одного, если ваша первая попытка не удалась. Если OTOH, переименование EFI/BOOT не имеет эффекта, то следующие два варианта вряд ли сработают (хотя может быть отключено Безопасная загрузка). Установка rEFInd становится вариантом, который, скорее всего, будет работать в этом случае, но это действительно выстрел в темноте. Обновление прошивки может работать, даже если первая диагностическая опция не изменяет поведение, но, как я уже сказал, это отчаянный вариант, который вряд ли будет работать независимо от причины. Тем не менее, стоит попробовать, если у вас нет других параметров (или, может быть, даже если вы это сделаете - обновления прошивки могут устранить всевозможные проблемы, добавить функции и повысить производительность).

Удачи, исправляя вашу проблему!

Question 6

У меня была такая же проблема на той же аппаратной модели. Как отмечал оригинальный плакат, проблема исчезает после применения обновления. К сожалению, проблема снова появляется. Исправление состоит в том, чтобы отключить безопасную загрузку, следуя инструкциям на этой странице: https://support.hp.com/us-en/document/c04784866

Question 7

Question 8

Казалось бы, проблема заключается в нескольких установках несоответствия GRUB. GRUB, установленный на /EFI/ubuntu/grubx64.efi, не работает, в то время как GRUB установлен на /EFI/Boot/bootx64.efi.

Вы должны исправить это, переустановив GRUB на ESP.

sudo grub-install --efi-directory = / boot / efi / dev / sda

Question 9

К сожалению, Boot Repair не правильно обрабатывает диски NVMe, поэтому в вашем отчете BootInfo отсутствует куча важной информации; однако он показывает одну запись ubuntu в списке диспетчера загрузки NVRAM, поэтому маловероятно, что система загружается через какой-либо другой путь - ИСКЛЮЧАЕТ, что у вас есть резервный загрузчик (EFI/BOOT/bootx64.efi), который от другого файл в этом каталоге (fbx64.efi), вероятно, является инструментом для восстановления настроек загрузки в случае сбоя прошивки. Этот инструмент, как его настроить и использовать, описан в моей документации rEFInd (хотя он не является частью rEFInd, эта страница имеет самое полное и краткое описание fbx64.efi, о котором я знаю):

http://www.rodsbooks.com/refind/bootcoup.html#fallback

Возможно, ваш компьютер потеряет свою загрузочную переменную порядка, загрузив через Shim (как EFI/BOOT/bootx64.efi) и fbx64.efi, который затем загружает процесс загрузки в обычную запись ubuntu (которая запускает второй Shim, а затем GRUB), который затем зависает; но когда запись ubuntu запускается напрямую, она работает нормально. Это может произойти из-за ошибок, связанных с запуском двух копий Shim, потому что сам fbx64.efi вызывает проблемы или по какой-то другой причине. Эта гипотеза очень спекулятивна; это основано на очень мало доказательств и немало предположений. Он также предполагает ошибки в вашей прошивке и, вероятно, в Shim, fbx64.efi и / или GRUB. Это согласуется с симптомами, которые вы видите, и это единственное объяснение, которое приходит на ум. Если это то, что происходит, вы можете попробовать как диагностические процедуры или устранить проблему:

Переименуйте каталог EFI/BOOT в ESP. Если вы переименуете этот каталог, и проблема будет сохраняться точно так, как она есть, то моя гипотеза неверна. (Это связано с тем, что переименование EFI/BOOT не позволит компьютеру пытаться запустить Shim и fbx64.efi, хранящиеся в этом каталоге, поэтому, если он продолжает загружаться, должно быть, что порядок загрузки и загрузочные переменные сохраняются и соблюдаются, наоборот к моей гипотезе.) Если, однако, компьютер начинает правильно загружаться или загружается прямо в Windows, то это свидетельствует о том, что он загружался таким образом, и моя гипотеза становится гораздо более вероятной. Вы должны иметь возможность переименовать каталог обратно в EFI/BOOT, чтобы восстановить загрузочную операцию (failing), которая будет необходима для следующих трех ремонтов .... Отключить Безопасную загрузку - Отключение Secure Boot изменит способ работы Shim, и если моя гипотеза верна, это может заставить все работать - или это может не иметь никакого эффекта. Даже если моя гипотеза верна, это изменение будет работать только в том случае, если отказ вызван Secure Boot, чего может и не быть. Скопируйте EFI/ubuntu/grub* в EFI/BOOT. Если вы скопируете GRUB (grubx64.efi) и его файл конфигурации (grub.cfg) с EFI/ubuntu на EFI/BOOT, затем Shim в EFI/BOOT (то есть EFI/BOOT/bootx64.efi ) должен запускать GRUB непосредственно из EFI/BOOT, а не проходить через fbx64.efi. Это должно обойти проблему, если моя гипотеза правильная. Используйте rEFInd. Мой менеджер загрузки rEFInd загружается совсем по-другому из GRUB, поэтому вероятность того, что проблема не будет затронута этой проблемой. Однако, если активна Secure Boot, вам нужно зарегистрировать ключ или два в списке MOK, как описано в документации rEFInd Secure Boot. Кроме того, вам может потребоваться удалить или переименовать файл EFI/ubuntu/BOOTX64.CSV в ESP. (Переименуйте его на что-то с именем файла, которое не заканчивается на .CSV, или любым измененным в зависимости от случая вариантом, например .csv.) Причина в том, что fbx64.efi ищет файлы .CSV для восстановления NVRAM- основанный на загрузке, поэтому, если этот файл присутствует, вероятность 50/50 будет иметь приоритет над файлом BOOT.CSV, который создает rEFInd для себя, тем самым заставляя систему загружаться в GRUB и продолжать сбой в том, как вы описываете. Обновите свою прошивку. Если ваш производитель предлагает новую прошивку (возможно, называемую «BIOS»), чем то, что вы используете сейчас, вы можете ее обновить. Это выстрел в темноте; ваша проблема звучит достаточно экзотично, что вряд ли она будет исправлена в обновлении прошивки.

Я рекомендую вам попробовать первый из этих параметров в качестве диагностики. Если поведение загрузки изменяется, как я описал, вы можете восстановить EFI/BOOT так, как он был, и попробовать любой из следующих трех параметров - или более одного, если ваша первая попытка не удалась. Если OTOH, переименование EFI/BOOT не имеет эффекта, то следующие два варианта вряд ли сработают (хотя может быть отключено Безопасная загрузка). Установка rEFInd становится вариантом, который, скорее всего, будет работать в этом случае, но это действительно выстрел в темноте. Обновление прошивки может работать, даже если первая диагностическая опция не изменяет поведение, но, как я уже сказал, это отчаянный вариант, который вряд ли будет работать независимо от причины. Тем не менее, стоит попробовать, если у вас нет других параметров (или, может быть, даже если вы это сделаете - обновления прошивки могут устранить всевозможные проблемы, добавить функции и повысить производительность).

Удачи, исправляя вашу проблему!

Brian Rhodes · Answer 1 · 18 July 2018 в 04:56

У меня была такая же проблема на той же аппаратной модели. Как отмечал оригинальный плакат, проблема исчезает после применения обновления. К сожалению, проблема снова появляется. Исправление состоит в том, чтобы отключить безопасную загрузку, следуя инструкциям на этой странице: https://support.hp.com/us-en/document/c04784866

jdwolf · Answer 2 · 18 July 2018 в 04:56

Казалось бы, проблема заключается в нескольких установках несоответствия GRUB. GRUB, установленный на /EFI/ubuntu/grubx64.efi, не работает, в то время как GRUB установлен на /EFI/Boot/bootx64.efi.

Вы должны исправить это, переустановив GRUB на ESP.

sudo grub-install --efi-directory = / boot / efi / dev / sda

Rod Smith · Answer 3 · 18 July 2018 в 04:56

К сожалению, Boot Repair не правильно обрабатывает диски NVMe, поэтому в вашем отчете BootInfo отсутствует куча важной информации; однако он показывает одну запись ubuntu в списке диспетчера загрузки NVRAM, поэтому маловероятно, что система загружается через какой-либо другой путь - ИСКЛЮЧАЕТ, что у вас есть резервный загрузчик (EFI/BOOT/bootx64.efi), который от другого файл в этом каталоге (fbx64.efi), вероятно, является инструментом для восстановления настроек загрузки в случае сбоя прошивки. Этот инструмент, как его настроить и использовать, описан в моей документации rEFInd (хотя он не является частью rEFInd, эта страница имеет самое полное и краткое описание fbx64.efi, о котором я знаю):

http://www.rodsbooks.com/refind/bootcoup.html#fallback

Возможно, ваш компьютер потеряет свою загрузочную переменную порядка, загрузив через Shim (как EFI/BOOT/bootx64.efi) и fbx64.efi, который затем загружает процесс загрузки в обычную запись ubuntu (которая запускает второй Shim, а затем GRUB), который затем зависает; но когда запись ubuntu запускается напрямую, она работает нормально. Это может произойти из-за ошибок, связанных с запуском двух копий Shim, потому что сам fbx64.efi вызывает проблемы или по какой-то другой причине. Эта гипотеза очень спекулятивна; это основано на очень мало доказательств и немало предположений. Он также предполагает ошибки в вашей прошивке и, вероятно, в Shim, fbx64.efi и / или GRUB. Это согласуется с симптомами, которые вы видите, и это единственное объяснение, которое приходит на ум. Если это то, что происходит, вы можете попробовать как диагностические процедуры или устранить проблему:

Переименуйте каталог EFI/BOOT в ESP. Если вы переименуете этот каталог, и проблема будет сохраняться точно так, как она есть, то моя гипотеза неверна. (Это связано с тем, что переименование EFI/BOOT не позволит компьютеру пытаться запустить Shim и fbx64.efi, хранящиеся в этом каталоге, поэтому, если он продолжает загружаться, должно быть, что порядок загрузки и загрузочные переменные сохраняются и соблюдаются, наоборот к моей гипотезе.) Если, однако, компьютер начинает правильно загружаться или загружается прямо в Windows, то это свидетельствует о том, что он загружался таким образом, и моя гипотеза становится гораздо более вероятной. Вы должны иметь возможность переименовать каталог обратно в EFI/BOOT, чтобы восстановить загрузочную операцию (failing), которая будет необходима для следующих трех ремонтов .... Отключить Безопасную загрузку - Отключение Secure Boot изменит способ работы Shim, и если моя гипотеза верна, это может заставить все работать - или это может не иметь никакого эффекта. Даже если моя гипотеза верна, это изменение будет работать только в том случае, если отказ вызван Secure Boot, чего может и не быть. Скопируйте EFI/ubuntu/grub* в EFI/BOOT. Если вы скопируете GRUB (grubx64.efi) и его файл конфигурации (grub.cfg) с EFI/ubuntu на EFI/BOOT, затем Shim в EFI/BOOT (то есть EFI/BOOT/bootx64.efi ) должен запускать GRUB непосредственно из EFI/BOOT, а не проходить через fbx64.efi. Это должно обойти проблему, если моя гипотеза правильная. Используйте rEFInd. Мой менеджер загрузки rEFInd загружается совсем по-другому из GRUB, поэтому вероятность того, что проблема не будет затронута этой проблемой. Однако, если активна Secure Boot, вам нужно зарегистрировать ключ или два в списке MOK, как описано в документации rEFInd Secure Boot. Кроме того, вам может потребоваться удалить или переименовать файл EFI/ubuntu/BOOTX64.CSV в ESP. (Переименуйте его на что-то с именем файла, которое не заканчивается на .CSV, или любым измененным в зависимости от случая вариантом, например .csv.) Причина в том, что fbx64.efi ищет файлы .CSV для восстановления NVRAM- основанный на загрузке, поэтому, если этот файл присутствует, вероятность 50/50 будет иметь приоритет над файлом BOOT.CSV, который создает rEFInd для себя, тем самым заставляя систему загружаться в GRUB и продолжать сбой в том, как вы описываете. Обновите свою прошивку. Если ваш производитель предлагает новую прошивку (возможно, называемую «BIOS»), чем то, что вы используете сейчас, вы можете ее обновить. Это выстрел в темноте; ваша проблема звучит достаточно экзотично, что вряд ли она будет исправлена в обновлении прошивки.

Я рекомендую вам попробовать первый из этих параметров в качестве диагностики. Если поведение загрузки изменяется, как я описал, вы можете восстановить EFI/BOOT так, как он был, и попробовать любой из следующих трех параметров - или более одного, если ваша первая попытка не удалась. Если OTOH, переименование EFI/BOOT не имеет эффекта, то следующие два варианта вряд ли сработают (хотя может быть отключено Безопасная загрузка). Установка rEFInd становится вариантом, который, скорее всего, будет работать в этом случае, но это действительно выстрел в темноте. Обновление прошивки может работать, даже если первая диагностическая опция не изменяет поведение, но, как я уже сказал, это отчаянный вариант, который вряд ли будет работать независимо от причины. Тем не менее, стоит попробовать, если у вас нет других параметров (или, может быть, даже если вы это сделаете - обновления прошивки могут устранить всевозможные проблемы, добавить функции и повысить производительность).

Удачи, исправляя вашу проблему!

Brian Rhodes · Answer 4 · 24 July 2018 в 18:12

У меня была такая же проблема на той же аппаратной модели. Как отмечал оригинальный плакат, проблема исчезает после применения обновления. К сожалению, проблема снова появляется. Исправление состоит в том, чтобы отключить безопасную загрузку, следуя инструкциям на этой странице: https://support.hp.com/us-en/document/c04784866

jdwolf · Answer 5 · 24 July 2018 в 18:12

Казалось бы, проблема заключается в нескольких установках несоответствия GRUB. GRUB, установленный на /EFI/ubuntu/grubx64.efi, не работает, в то время как GRUB установлен на /EFI/Boot/bootx64.efi.

Вы должны исправить это, переустановив GRUB на ESP.

sudo grub-install --efi-directory = / boot / efi / dev / sda

0

ответ дан jdwolf 24 July 2018 в 18:12

1

EFI/ubuntu/grubx64.efi - GRUB, но EFI/BOOT/bootx64.efi, скорее всего, Shim. Описанное сообщение (Selected boot image did not Authenticate) указывает на проблему с безопасностью загрузки, и я уверен, что на 80% это сообщение из прошивки. Это понятно и ожидается, если включена Безопасная загрузка, и вы попытаетесь запустить GRUB напрямую, что ваша диагностическая процедура сделала туман. Фактически, два отказа (загрузка без вмешательства и загрузка GRUB напрямую) вызывают разные симптомы, поэтому вы, вероятно, окажетесь на дикой гусиной погоне с этим решением; но, возможно, переустановка GRUB исправит это случайно. – Rod Smith 21 October 2017 в 17:52
2

Я согласен, что сообщение связано с безопасной загрузкой. OP указывает, что у него есть двойная система загрузки с Windows, которая сама загружается. Из-за этой прокладки (которая загружает grub) также должна работать. Однако UEFI не должен содержать записи, запускающие unsigned grub, или вообще без подписи. Так как grub проверен с помощью прокладки и подкладки, мое мышление состояло в том, чтобы сначала попробовать Ubuntus, встроенный в метод установки grub: grub-install. Если у вас есть предложение о том, как мысленно настраивать процесс подписи, Ubuntu использует способ, совместимый, прямо сейчас и редактируя мой ответ. – jdwolf 21 October 2017 в 18:50
3

Если это так: sudo grub-install --efi-directory = / boot / efi / dev // dev / nvme0n1? Еще одна небольшая заметка: это новый ноутбук, и в первый раз, когда я установил на него какую-либо другую ОС, так это не так, как если бы я установил множество других дистрибутивов, сначала создав несколько записей UEFI. – fog 21 October 2017 в 22:04

Rod Smith · Answer 6 · 24 July 2018 в 18:12

К сожалению, Boot Repair не правильно обрабатывает диски NVMe, поэтому в вашем отчете BootInfo отсутствует куча важной информации; однако он показывает одну запись ubuntu в списке диспетчера загрузки NVRAM, поэтому маловероятно, что система загружается через какой-либо другой путь - ИСКЛЮЧАЕТ, что у вас есть резервный загрузчик (EFI/BOOT/bootx64.efi), который от другого файл в этом каталоге (fbx64.efi), вероятно, является инструментом для восстановления настроек загрузки в случае сбоя прошивки. Этот инструмент, как его настроить и использовать, описан в моей документации rEFInd (хотя он не является частью rEFInd, эта страница имеет самое полное и краткое описание fbx64.efi, о котором я знаю):

http://www.rodsbooks.com/refind/bootcoup.html#fallback

Возможно, ваш компьютер потеряет свою загрузочную переменную порядка, загрузив через Shim (как EFI/BOOT/bootx64.efi) и fbx64.efi, который затем загружает процесс загрузки в обычную запись ubuntu (которая запускает второй Shim, а затем GRUB), который затем зависает; но когда запись ubuntu запускается напрямую, она работает нормально. Это может произойти из-за ошибок, связанных с запуском двух копий Shim, потому что сам fbx64.efi вызывает проблемы или по какой-то другой причине. Эта гипотеза очень спекулятивна; это основано на очень мало доказательств и немало предположений. Он также предполагает ошибки в вашей прошивке и, вероятно, в Shim, fbx64.efi и / или GRUB. Это согласуется с симптомами, которые вы видите, и это единственное объяснение, которое приходит на ум. Если это то, что происходит, вы можете попробовать как диагностические процедуры или устранить проблему:

Переименуйте каталог EFI/BOOT в ESP. Если вы переименуете этот каталог, и проблема будет сохраняться точно так, как она есть, то моя гипотеза неверна. (Это связано с тем, что переименование EFI/BOOT не позволит компьютеру пытаться запустить Shim и fbx64.efi, хранящиеся в этом каталоге, поэтому, если он продолжает загружаться, должно быть, что порядок загрузки и загрузочные переменные сохраняются и соблюдаются, наоборот к моей гипотезе.) Если, однако, компьютер начинает правильно загружаться или загружается прямо в Windows, то это свидетельствует о том, что он загружался таким образом, и моя гипотеза становится гораздо более вероятной. Вы должны иметь возможность переименовать каталог обратно в EFI/BOOT, чтобы восстановить загрузочную операцию (failing), которая будет необходима для следующих трех ремонтов .... Отключить Безопасную загрузку - Отключение Secure Boot изменит способ работы Shim, и если моя гипотеза верна, это может заставить все работать - или это может не иметь никакого эффекта. Даже если моя гипотеза верна, это изменение будет работать только в том случае, если отказ вызван Secure Boot, чего может и не быть. Скопируйте EFI/ubuntu/grub* в EFI/BOOT. Если вы скопируете GRUB (grubx64.efi) и его файл конфигурации (grub.cfg) с EFI/ubuntu на EFI/BOOT, затем Shim в EFI/BOOT (то есть EFI/BOOT/bootx64.efi ) должен запускать GRUB непосредственно из EFI/BOOT, а не проходить через fbx64.efi. Это должно обойти проблему, если моя гипотеза правильная. Используйте rEFInd. Мой менеджер загрузки rEFInd загружается совсем по-другому из GRUB, поэтому вероятность того, что проблема не будет затронута этой проблемой. Однако, если активна Secure Boot, вам нужно зарегистрировать ключ или два в списке MOK, как описано в документации rEFInd Secure Boot. Кроме того, вам может потребоваться удалить или переименовать файл EFI/ubuntu/BOOTX64.CSV в ESP. (Переименуйте его на что-то с именем файла, которое не заканчивается на .CSV, или любым измененным в зависимости от случая вариантом, например .csv.) Причина в том, что fbx64.efi ищет файлы .CSV для восстановления NVRAM- основанный на загрузке, поэтому, если этот файл присутствует, вероятность 50/50 будет иметь приоритет над файлом BOOT.CSV, который создает rEFInd для себя, тем самым заставляя систему загружаться в GRUB и продолжать сбой в том, как вы описываете. Обновите свою прошивку. Если ваш производитель предлагает новую прошивку (возможно, называемую «BIOS»), чем то, что вы используете сейчас, вы можете ее обновить. Это выстрел в темноте; ваша проблема звучит достаточно экзотично, что вряд ли она будет исправлена в обновлении прошивки.

Я рекомендую вам попробовать первый из этих параметров в качестве диагностики. Если поведение загрузки изменяется, как я описал, вы можете восстановить EFI/BOOT так, как он был, и попробовать любой из следующих трех параметров - или более одного, если ваша первая попытка не удалась. Если OTOH, переименование EFI/BOOT не имеет эффекта, то следующие два варианта вряд ли сработают (хотя может быть отключено Безопасная загрузка). Установка rEFInd становится вариантом, который, скорее всего, будет работать в этом случае, но это действительно выстрел в темноте. Обновление прошивки может работать, даже если первая диагностическая опция не изменяет поведение, но, как я уже сказал, это отчаянный вариант, который вряд ли будет работать независимо от причины. Тем не менее, стоит попробовать, если у вас нет других параметров (или, может быть, даже если вы это сделаете - обновления прошивки могут устранить всевозможные проблемы, добавить функции и повысить производительность).

Удачи, исправляя вашу проблему!

Никогда не мог решить проблему самостоятельно. Однако недавнее обновление за последние несколько недель решило проблему для меня. Больше не замораживается. — fog, 24 January 2018 в 02:43

Grub зависает при естественной загрузке, но работает, если выбран из меню EFI

Установка сертификата

6 ответов

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

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