Почему так много файлов .efi ?
Большинство из этих файлов являются файлами поддержки. Например, MokManager - это инструмент для управления ключами владельца машины (MOK), которые используются Shim для увеличения количества ключей безопасной загрузки, которые распознает компьютер. MokManager обычно вызывается, если Shim не может запустить дополнительный загрузчик по умолчанию (обычно GRUB). Похоже, у вас есть как минимум две копии Shim в EFI/centos (shim.efi и shim-centos.efi) и EFI/boot/BOOTAA64.EFI , вероятно, третий экземпляр Shim. Скорее всего, один из тех, что в EFI/centos является избыточным - возможно, остался от предыдущей установки, которая использовала другое имя или была создана случайно.
Разработчики Linux также вошли в привычку создавать новые программные файлы EFI для решения проблем или особых случаев. Например, ваша установка показывает две копии GRUB в каталоге EFI/centos - grubaa64.efi и gcdaa64.efi идентичны, за исключением того, где они ищут свои файлы конфигурации и поддержки. (См. Этот вопрос о Stack Exchange и ответьте немного подробнее по этому вопросу.)
Как менеджер загрузки нашел shim.efi?
Вы уже (частично) ответили на этот вопрос - в том, что вы назвали «native-boot», компьютер сохраняет путь к загрузчику в переменной NVRAM. Большинство дистрибутивов Linux в настоящее время используют Shim по умолчанию, поэтому переменная NVRAM будет указывать на двоичный файл Shim. Когда Shim запускается, он регистрируется в прошивке, а затем запускает дополнительный загрузчик (обычно GRUB).
Почему менеджер загрузки не нашел все остальные .efi файлы?
Стандартный менеджер загрузки EFI активно не сканирует файлы .efi , за исключением резервного имени файла и, в некоторых EFI, загрузчика Microsoft. (Существуют и другие, которые могут быть добавлены в список загрузки в некоторых случаях, например записи сетевой загрузки и записи для встроенной оболочки EFI.)
Вместо этого большинство EFI полагаются на установщик ОС для регистрации загрузчика как части процесса установки загрузчика. Таким образом, CentOS запишет в ESP Shim, GRUB и связанные с ним двоичные файлы .efi , а затем добавит одну или несколько записей NVRAM для указания на них. Теоретически, ОС может хранить десять, сто, тысячу или более файлов .efi в ESP и регистрировать только один из них. Когда вы перезагрузитесь и нажмете любое нажатие клавиши, необходимое для входа в менеджер загрузки EFI, вы увидите только одну запись, добавленную установщиком ОС. Вы можете добавлять, удалять или редактировать эти записи с помощью инструмента efibootmgr в большинстве дистрибутивов Linux.
AFAIK, единственные инструменты, которые активно сканируют загрузчики EFI:
- ПОМОЩЬ - Этот старый менеджер загрузки использовался в основном на Mac, но его можно использовать на компьютерах на основе UEFI. Он активно сканирует загрузчики в большинстве подкаталогов
EFI (то есть EFI/centos/ , EFI/BOOT/ и т.д.), EFI/tools/ является заметным исключением. Обратите внимание, что REFIt больше не поддерживается.
- rEFInd - это мой обновленный ветвь rEFIt, и он наследует алгоритм активного сканирования rEFIt с некоторыми настройками, чтобы он лучше работал в Linux и явно обрезал избыточные или иным образом ненужные загрузочные записи. Таким образом, rEFInd показывает как двоичные файлы
.efi и ядра Linux (которые в большинстве случаев являются программными файлами EFI, благодаря загрузчику заглушек EFI).
- Конфигурационные скрипты GRUB 2 - дистрибутивы, основанные на GRUB 2, обычно поставляются со скриптами, которые сканируют файлы
.efi и добавляют их в меню GRUB. Однако, в отличие от rEFIt и rEFInd, эти проверки выполняются во время работы Linux (или другой хост-системы), а не во время загрузки.
Обратите внимание, что ни один из этих инструментов не влияет на то, что появляется в собственном меню менеджера загрузки EFI; все они влияют на то, что появляется в их собственных меню, не более того. Теоретически, другие инструменты могут выполнять такое сканирование. EFI может выполнять такое сканирование, либо при каждой загрузке, либо по команде пользователя, но на практике я не знаю ни одного, который бы делал; AFAIK, все EFI полагаются на свои собственные менеджеры загрузки со связанными записями NVRAM. (Некоторые из них содержат ошибки, что делает эти записи NVRAM ненадежными, поэтому практическое использование резервного имени файла является практической необходимостью.)
