Имя \EFI\BOOT\grubx64.efiговорит мне, что система использует не путь загрузки UEFI CentOS по умолчанию, а резервный путь. Но запасной путь загрузки — \EFI\BOOT\bootx64.efi, который будет занят прокладкой SecureBoot. Таким образом, кажется, что прокладка загружена, но она не может выполнить следующий шаг :загрузку фактического загрузчика GRUB из резервного каталога.

Моя теория:

• установка настраивает загрузчик обычным образом:\EFI\CentOS\shimx64.efi— это загрузчик-загрузчик SecureBoot, а \EFI\CentOS\grubx64.efi— фактический загрузчик GRUB. Путь \EFI\CentOS\shimx64.efiбыл зарегистрирован в переменных загрузки UEFI NVRAM. Установщик также (попытался )настроить вторую копию с прокладкой в ​​пути загрузки резервного/съемного носителя по умолчанию \EFI\BOOT\bootx64.efiи GRUB как \EFI\BOOT\grubx64.efi.
• при первой перезагрузке, инициированной установщиком, загрузочные переменные NVRAM остались нетронутыми, и микропрограмма выполнила «теплую перезагрузку», успешно загрузив ядро ​​с помощью \EFI\CentOS\shimx64.efiи \EFI\CentOS\grubx64.efi. Эта попытка загрузки привела к зависанию, поскольку Nouveau не был отключен.
• Затем что-то привело к тому, что прошивка забыла загрузочные переменные NVRAM, в результате чего система вместо этого попыталась загрузиться с резервного пути \EFI\BOOT\bootx64.efi. Это происходит, когда вы указываете UEFI загружаться с определенного диска, но не указываете путь к загрузчику. По той или иной причине,это позволяет загрузить резервную копию прокладки SecureBoot, но затем происходит сбой при загрузке \EFI\BOOT\grubx64.efi. Обратите внимание, не говорит что файл поврежден :, а говорит, что файл просто не существует.

Теперь вам, вероятно, следует использовать efibootmgr -vдля просмотра ваших загрузочных переменных UEFI в том виде, в каком они существуют сейчас, и записать текущий набор -вверх или, по крайней мере, загрузочную запись CentOS, чтобы вы могли воспроизвести это, если он снова потеряется. В этой ситуации вы можете либо загрузиться в режиме восстановления с установочного носителя CentOS и использовать команду efibootmgrдля исправления переменных NVRAM, либо, возможно, просто ввести правильные настройки с помощью меню «настройки загрузки» UEFI, если это позволяет. (К сожалению, большинство реализаций UEFI, которые я видел, не поддерживаются.)

Вам также следует убедиться, что резервный загрузчик GRUB не поврежден. Файл должен быть доступен как /boot/efi/EFI/BOOT/grubx64.efiв Linux. Убедитесь, что файл существует и идентичен /boot/efi/EFI/CentOS/grubx64.efi.

Я действительно не знаю, что привело к потере загрузочных переменных UEFI NVRAM между первой и третьей перезагрузкой. Существуют различные реализации UEFI с ошибками. Или, возможно, вы сбросили «настройки BIOS» в рамках устранения неполадок, связанных с зависанием, которое, как оказалось, было вызвано Nouveau? Сброс «настроек BIOS» UEFI может также сбросить или не сбросить загрузочные переменные NVRAM, в зависимости от реализации UEFI.

Если выяснится, что случайная потеря переменных загрузки UEFI NVRAM является ошибкой микропрограммы, вы можете проверить наличие обновления BIOS :, запустить dmidecode -s bios-version, чтобы увидеть текущую версию. Согласно страницам поддержки ASUS, самой последней версией UEFI BIOS от -до -для вашей системы является версия 1301. ASUS обычно включает функцию обновления в сам UEFI BIOS; если это так в вашей системе, вам просто нужно сохранить файл обновления в системный раздел EFI (= где-нибудь под /boot/efiв CentOS ), перейдите в настройки BIOS, активируйте инструмент обновления оттуда,и скажите ему, где находится файл обновления.

Одной из возможных причин повреждения NVRAM является efi-pstoreмодуль ядра. Если он включен (или встроен в стандартное ядро ​​CentOS )и активна функция сохранения журнала ядра в pstoreпри панике ядра, это могло заполнить NVRAM до 100% рядом переменных, содержащих журнал ядра. Это могло привести к тому, что микропрограмма определила хранилище переменных как поврежденное и автоматически повторно инициализировала загрузочные переменные NVRAM.

Если резервный путь /boot/efi/EFI/BOOT/grubx64.efiна самом деле не был поврежден, сбой при загрузке с резервного пути мог быть вызван ошибкой в ​​прокладке SecureBoot или чрезмерным -принудительным применением безопасной загрузки в резервном пути загрузки жесткого диска. (технически это прошивка UEFI ошибка недокументированная функция, которая делает ее несовместимой с прокладкой SecureBoot ). В этом случае может помочь обновление оболочки SecureBoot.