Bootx64 efi что это

Исправить ошибки Bootx64.efi и скачать

Файл bootx64.efi, также известный как файл Boot Manager, был создан компанией CFS-Technologies для разработки Microsoft® Windows® Operating System. Файлы EFI относятся к категории типов файлов Win64 DLL (Исполняемое приложение).

Файл bootx64.efi впервые был выпущен в ОС Windows 10 09/11/2014 с PhotoScape X 3.7. Самая последняя версия [версия 10.0.18362.1 (WinBuild.160101.0800)] была представлена 07/22/2002 для Speakonia 1.3.5. Файл bootx64.efi включен в Speakonia 1.3.5, Free Convert to DIVX AVI WMV MP4 MPEG Converter 6.2 и RAR Password Cracker 4.4.

В этой короткой статье приводятся подробные сведения о файле, шаги по устранению проблем EFI с bootx64.efi и список бесплатных загрузок для каждой версии, содержащейся в нашем полном каталоге файлов.

Рекомендуемая загрузка: исправить ошибки реестра в WinThruster, связанные с bootx64.efi и (или) Speakonia.

Совместимость с Windows 10, 8, 7, Vista, XP и 2000

Средняя оценка пользователей

Обзор файла

Сведения о разработчике и ПО
Разработчик ПО:	Microsoft Corporation
Программа:	Microsoft® Windows® Operating System
Авторское право:	© Microsoft Corporation. All rights reserved.

Сведения о файле
Набор символов:	Unicode
Код языка:	English (U.S.)
Флаги файлов:	(none)
Маска флагов файлов:	0x003f
Точка входа:	0x1f280
Размер кода:	1395712

Информация о файле	Описание
Размер файла:	1490 kB
Дата и время изменения файла:	2020:01:29 09:04:16+00:00
Тип файла:	Win64 DLL
Тип MIME:	application/octet-stream
Предупреждение!	Possibly corrupt Version resource
Тип компьютера:	AMD AMD64
Метка времени:	2025:04:29 05:50:41+00:00
Тип PE:	PE32+
Версия компоновщика:	14.15
Размер кода:	1395712
Размер инициализированных данных:	389632
Размер неинициализированных данных:	0
Точка входа:	0x1f280
Версия ОС:	0.0
Версия образа:	0.0
Версия подсистемы:	1.0
Подсистема:	EFI application
Номер версии файла:	10.0.18362.1
Номер версии продукта:	10.0.18362.1
Маска флагов файлов:	0x003f
Флаги файлов:	(none)
Файловая ОС:	Windows NT 32-bit
Тип объектного файла:	Executable application
Подтип файла:	0
Код языка:	English (U.S.)
Набор символов:	Unicode
Наименование компании:	Microsoft Corporation
Описание файла:	Boot Manager
Версия файла:	10.0.18362.1 (WinBuild.160101.0800)
Внутреннее имя:	bootmgr.exe
Авторское право:	© Microsoft Corporation. All rights reserved.
Название продукта:	Microsoft® Windows® Operating System
Версия продукта:	10.0.18362.1

✻ Фрагменты данных файлов предоставлены участником Exiftool (Phil Harvey) и распространяются под лицензией Perl Artistic.

Что такое сообщения об ошибках bootx64.efi?

bootx64.efi — ошибки выполнения

Ошибки выполнения — это ошибки Speakonia, возникающие во время «выполнения». Термин «выполнение» говорит сам за себя; имеется в виду, что данные ошибки EFI возникают в момент, когда происходит попытка загрузки файла bootx64.efi — либо при запуске приложения Speakonia, либо, в некоторых случаях, во время его работы. Ошибки выполнения являются наиболее распространенной разновидностью ошибки EFI, которая встречается при использовании приложения Speakonia.

В большинстве случаев ошибки выполнения bootx64.efi, возникающие во время работы программы, приводят к ненормальному завершению ее работы. Большинство сообщений об ошибках bootx64.efi означают, что либо приложению Speakonia не удалось найти этот файл при запуске, либо файл поврежден, что приводит к преждевременному прерыванию процесса запуска. Как правило, Speakonia не сможет запускаться без разрешения этих ошибок.

К числу наиболее распространенных ошибок bootx64.efi относятся:

bootx64.efi — недопустимое изображение.
bootx64.efi — ошибка приложения.
Не удается найти bootx64.efi.
Не удается установить bootx64.efi.
Не удается запустить bootx64.efi. Класс не зарегистрирован.
Не удается запустить bootx64.efi.
Не удалось правильно инициализировать bootx64.efi.
Ошибка файла bootx64.efi; файл должен быть закрыт. Приносим извинения за неудобства.
Файл bootx64.efi не является допустимым приложением Win32.
Файл bootx64.efi не выполняется.
Не удается найти bootx64.efi.
Ошибка при запуске программы: bootx64.efi.
Неправильный путь приложения: bootx64.efi.
Файл bootx64.efi отсутствует или поврежден.
Windows не удалось запустить — bootx64.efi.

Системная ошибка

Не удается запустить программу из-за отсутствия bootx64.efi на компьютере. Попробуйте переустановить программу, чтобы устранить эту проблему.

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

Поиск причины ошибки bootx64.efi является ключом к правильному разрешению таких ошибок. Несмотря на то что большинство этих ошибок EFI, влияющих на bootx64.efi, происходят во время запуска, иногда ошибка выполнения возникает при использовании Microsoft® Windows® Operating System. Причиной этого может быть недостаточное качество программного кода со стороны Microsoft Corporation, конфликты с другими приложениями, сторонние плагины или поврежденное и устаревшее оборудование. Кроме того, эти типы ошибок bootx64.efi могут возникать в тех случаях, если файл был случайно перемещен, удален или поврежден вредоносным программным обеспечением. Таким образом, крайне важно, чтобы антивирус постоянно поддерживался в актуальном состоянии и регулярно проводил сканирование системы.

Как исправить ошибки bootx64.efi — 3-шаговое руководство (время выполнения: ~5-15 мин.)

Если вы столкнулись с одним из вышеуказанных сообщений об ошибке, выполните следующие действия по устранению неполадок, чтобы решить проблему bootx64.efi. Эти шаги по устранению неполадок перечислены в рекомендуемом порядке выполнения.

Шаг 1. Восстановите компьютер до последней точки восстановления, «моментального снимка» или образа резервной копии, которые предшествуют появлению ошибки.

Чтобы начать восстановление системы (Windows XP, Vista, 7, 8 и 10):

Нажмите кнопку «Пуск» в Windows
В поле поиска введите «Восстановление системы» и нажмите ENTER.
В результатах поиска найдите и нажмите «Восстановление системы»
Введите пароль администратора (при необходимости).
Следуйте инструкциям мастера восстановления системы, чтобы выбрать соответствующую точку восстановления.
Восстановите компьютер к этому образу резервной копии.

Если на этапе 1 не удается устранить ошибку bootx64.efi, перейдите к шагу 2 ниже.

Шаг 2. Если вы недавно установили приложение Speakonia (или схожее программное обеспечение), удалите его, затем попробуйте переустановить Speakonia.

Чтобы удалить программное обеспечение Speakonia, выполните следующие инструкции (Windows XP, Vista, 7, 8 и 10):

Нажмите кнопку «Пуск» в Windows
В поле поиска введите «Удалить» и нажмите ENTER.
В результатах поиска найдите и нажмите «Установка и удаление программ»
Найдите запись для Speakonia 1.3.5 и нажмите «Удалить»
Следуйте указаниям по удалению.

После полного удаления приложения следует перезагрузить ПК и заново установить Speakonia.

Если на этапе 2 также не удается устранить ошибку bootx64.efi, перейдите к шагу 3 ниже.

Шаг 3. Выполните обновление Windows.

Когда первые два шага не устранили проблему, целесообразно запустить Центр обновления Windows. Во многих случаях возникновение сообщений об ошибках bootx64.efi может быть вызвано устаревшей операционной системой Windows. Чтобы запустить Центр обновления Windows, выполните следующие простые шаги:

Нажмите кнопку «Пуск» в Windows
В поле поиска введите «Обновить» и нажмите ENTER.
В диалоговом окне Центра обновления Windows нажмите «Проверить наличие обновлений» (или аналогичную кнопку в зависимости от версии Windows)
Если обновления доступны для загрузки, нажмите «Установить обновления».
После завершения обновления следует перезагрузить ПК.

Если Центр обновления Windows не смог устранить сообщение об ошибке bootx64.efi, перейдите к следующему шагу. Обратите внимание, что этот последний шаг рекомендуется только для продвинутых пользователей ПК.

Если эти шаги не принесут результата: скачайте и замените файл bootx64.efi (внимание: для опытных пользователей)

Если ни один из предыдущих трех шагов по устранению неполадок не разрешил проблему, можно попробовать более агрессивный подход (примечание: не рекомендуется пользователям ПК начального уровня), загрузив и заменив соответствующую версию файла bootx64.efi. Мы храним полную базу данных файлов bootx64.efi со 100%-ной гарантией отсутствия вредоносного программного обеспечения для любой применимой версии Speakonia . Чтобы загрузить и правильно заменить файл, выполните следующие действия:

Найдите версию операционной системы Windows в нижеприведенном списке «Загрузить файлы bootx64.efi».
Нажмите соответствующую кнопку «Скачать», чтобы скачать версию файла Windows.
Скопируйте этот файл в соответствующее расположение папки Speakonia:

Windows 10: C:\$WINDOWS.~BT\efi\boot\
Windows 10: C:\$WINDOWS.~BT\efi\boot\
Windows 10: C:\$WINDOWS.~BT\efi\boot\
Windows 10: C:\Program Files (x86)\AOMEI Backupper\msefi64\boot\
Windows 10: C:\$WINDOWS.~BT\efi\boot\
Показать на 7 каталогов больше +

Windows 10: C:\Program Files (x86)\Lazesoft Recover My Password\PETools\amd64\efi\boot\
Windows 10: C:\Program Files (x86)\Lazesoft Recovery Suite\PETools\amd64\efi\boot\
Windows 10: C:\$WINDOWS.~BT\efi\boot\
Windows 10: C:\$WINDOWS.~BT\efi\boot\
Windows 10: C:\$WINDOWS.~BT\efi\boot\
Windows 10: C:\Program Files\MiniTool Partition Wizard 11\PETools\amd64\efi\boot\
Windows 10: C:\$WINDOWS.~BT\efi\boot\

Если этот последний шаг оказался безрезультативным и ошибка по-прежнему не устранена, единственно возможным вариантом остается выполнение чистой установки Windows 10.

СОВЕТ ОТ СПЕЦИАЛИСТА: Мы должны подчеркнуть, что переустановка Windows является достаточно длительной и сложной задачей для решения проблем, связанных с bootx64.efi. Во избежание потери данных следует убедиться, что перед началом процесса вы создали резервные копии всех важных документов, изображений, установщиков программного обеспечения и других персональных данных. Если вы в настоящее время не создаете резервных копий своих данных, вам необходимо сделать это немедленно.

Unified Extensible Firmware Interface (Русский)

Состояние перевода: На этой странице представлен перевод статьи Unified Extensible Firmware Interface. Дата последней синхронизации: 22 августа 2023. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

Системный раздел EFI
Процесс загрузки Arch
Таблица разделов GUID
Secure Boot
Unified kernel image

Unified Extensible Firmware Interface (UEFI, преемник EFI) — интерфейс между операционной системой и прошивкой устройства. Он обеспечивает стандартную среду для загрузки операционной системы и запуска предзагрузочных приложений.

Он вводит новый способ загрузки операционных систем, который отличается от обычного «загрузочного кода MBR», который использовался в системах BIOS. Различия в процессе загрузки описаны в статье Процесс загрузки Arch. Установка загрузчиков UEFI описана в разделе Процесс загрузки Arch#Загрузчик.

Примечание: Ранние реализации UEFI могут содержать больше ошибок, чем их BIOS-аналоги. Если вы столкнётесь с неразрешимыми проблемами, подумайте об использовании Legacy BIOS для таких систем.

Версии UEFI

UEFI начинался как EFI от Intel в версиях 1.x.
Позже группа компаний под названием UEFI Forum взяла на себя его разработку и переименовала в Unified EFI, начиная с версии 2.0.
Если не указано, что имеется в виду EFI 1.x, термины EFI и UEFI используются как взаимозаменяемые для обозначения прошивки UEFI 2.x.
Реализация EFI от Apple не является ни версией EFI 1.x, ни версией UEFI 2.x, а смешивает оба варианта. Этот вид прошивок не подпадает ни под одну из спецификаций (U)EFI и поэтому не является стандартной прошивкой UEFI. Если не указано явно, эти инструкции являются общими, и некоторые из них могут не работать или отличаться на устройствах Mac.

Спецификацию последней версии UEFI можно найти на https://uefi.org/specifications.

Разрядность прошивки UEFI

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

Подавляющее большинство прошивок UEFI, включая последние модели Apple Mac, используют прошивку UEFI x86_64. Единственными известными устройствами, использующими IA32 (32-битный) UEFI, являются старые (до 2008 года) Apple Mac, системы Intel Atom System-on-Chip (по состоянию на 2 ноября 2013 года)[1] и некоторые старые серверные платы Intel, которые, как известно, работают на прошивке Intel EFI 1.10.

Прошивки x86_64 UEFI не имеют поддержки запуска 32-битных EFI-приложений (в отличие от x86_64 версий Linux и Windows, которые имеют такую поддержку). Поэтому EFI-приложение должно быть скомпилировано для конкретной разрядности/архитектуры процессора, на котором работает прошивка.

Примечание: Для систем с IA32 UEFI понадобится загрузчик с поддержкой mixed mode booting, например, GRUB с целью i386-efi .

Проверка разрядности прошивки

Разрядность прошивки можно проверить из загруженной операционной системы.

Из Linux

В дистрибутивах с ядром Linux версии 4.0 или новее разрядность прошивки UEFI можно узнать через интерфейс sysfs. Выполните:

$ cat /sys/firmware/efi/fw_platform_size

Это вернёт 64 для 64-битного (x86_64) UEFI или 32 для 32-битного (IA32) UEFI. Если файл не существует, значит, вы загрузились не в режиме UEFI.

Из macOS

Mac, выпущенные до 2008 года, в основном имеют прошивку IA32 EFI, а выпущенные в 2008 или позднее — x86_64 EFI. Все Mac, способные работать с 64-битным ядром Mac OS X Snow Leopard, имеют прошивку x86_64 EFI 1.x.

Чтобы узнать разрядность прошивки EFI в Mac, введите следующую команду в терминале Mac OS X:

$ ioreg -l -p IODeviceTree | grep firmware-abi

Если команда возвращает значение EFI32 , то прошивка IA32 EFI (32-битная), а если значение EFI64 — прошивка x86_64 EFI (64-битная). Большинство Mac не имеют прошивку UEFI 2.x, так как реализация EFI от Apple не полностью совместима со спецификацией UEFI 2.x.

Из Microsoft Windows

64-битные версии Windows не поддерживают загрузку на 32-битном UEFI. Поэтому, если у вас 32-битная версия Windows, загруженная в режиме UEFI, у вас 32-битный UEFI.

Для проверки разрядности запустите msinfo32.exe . В разделе Сведения о системе смотрите значения записей «Тип» и «Режим BIOS».

Для 64-битного Windows и 64-битного UEFI будет Тип: Компьютер на базе x64 и Режим BIOS: UEFI . Для 32-битного Windows и 32-битного UEFI — Тип: Компьютер на базе x86 и Режим BIOS: UEFI . Если «Режим BIOS» имеет значение не UEFI , значит, Windows загружен не в режиме UEFI.

Конфигурация ядра Linux для UEFI

Необходимая конфигурация для ядра Linux[2] такова:

CONFIG_RELOCATABLE=y CONFIG_EFI=y CONFIG_EFI_STUB=y CONFIG_X86_SYSFB=y CONFIG_FB_SIMPLE=y CONFIG_FRAMEBUFFER_CONSOLE=y

Поддержка UEFI Runtime Variables (файловая система efivarfs — /sys/firmware/efi/efivars ). Эта опция важна, так как нужна для работы с переменными времени выполнения UEFI с помощью инструментов вроде efibootmgr. Эта опция появилась в ядре 3.10.

CONFIG_EFIVAR_FS=y

Поддержка UEFI Runtime Variables (старый интерфейс efivars sysfs — /sys/firmware/efi/vars ). Эта опция должна быть отключена, чтобы предотвратить возможные проблемы при одновременно включенных efivarfs и sysfs-efivars.

CONFIG_EFI_VARS=n

Таблица разделов GUID (GPT) — необходима для поддержки UEFI

CONFIG_EFI_PARTITION=y

Поддержка EFI mixed-mode — для загрузки 64-битного ядра на 32-битной прошивке UEFI.

CONFIG_EFI_MIXED=y

Совет: Все эти опции применяются в официально поддерживаемых ядрах.

Переменные UEFI

UEFI определяет переменные, через которые операционная система может взаимодействовать с прошивкой. Переменные загрузки UEFI используются загрузчиком и применяются ОС только для раннего запуска системы. Переменные времени выполнения (runtime variables) позволяют ОС управлять определёнными настройками прошивки, такими как менеджер загрузки UEFI или управление ключами для протокола UEFI Secure Boot и т. д. Вы можете получить список с помощью команды:

$ efivar --list

Поддержка переменных UEFI в ядре Linux

Ядро Linux даёт пользовательскому пространству доступ к переменным UEFI через интерфейс efivarfs (EFI VARiable FileSystem) ( CONFIG_EFIVAR_FS ) — монтируется с помощью модуля ядра efivarfs в /sys/firmware/efi/efivars — не имеет ограничений на максимальный размер переменной и поддерживает переменные UEFI Secure Boot. Появилось в ядре 3.8.

Требования для поддержки переменных UEFI

Ядро должно быть загружено в режиме UEFI через EFISTUB (опционально с использованием менеджера загрузки) или загрузчиком UEFI, а не через BIOS или CSM, или Apple Boot Camp, который также является CSM.
Ядро должно иметь поддержку EFI Runtime Services ( CONFIG_EFI=y , проверить наличие можно командой zgrep CONFIG_EFI /proc/config.gz ).
EFI Runtime Services в ядре не должны быть отключены через командную строку ядра, то есть параметр noefi должен отсутствовать.
Файловая система efivarfs должна быть смонтирована в /sys/firmware/efi/efivars , иначе следуйте разделу #Монтирование efivars ниже.
efivar должен отобразить список переменных UEFI (опция -l / —list ) без ошибок.

Если поддержка переменных UEFI не работает даже после выполнения вышеуказанных условий, попробуйте следующие обходные пути:

Если просмотр списка переменных UEFI ( efivar -l ) приводит к ошибке efivar: error listing variables: Function not implemented и система загружена в ядро реального времени, добавьте efi=runtime в параметры ядра и перезагрузитесь (efivarfs отключен по умолчанию на таких ядрах).
Дополнительные шаги по устранению неполадок смотрите в разделе #Пользовательские инструменты не могут изменить переменные UEFI

Монтирование efivars

Если systemd не смонтировал efivarfs в /sys/firmware/efi/efivars автоматически, смонтируйте его вручную, чтобы у инструментов вроде efibootmgr появился доступ к переменным UEFI:

# mount -t efivarfs efivarfs /sys/firmware/efi/efivars

Примечание: При использовании chroot нужно выполнить монтирование и снаружи (то есть перед запуском chroot), и внутри него.

Документация ядра доступна здесь: efivarfs.html.

Пользовательские инструменты

Существует несколько инструментов, работающих в пространстве пользователя (userspace), которые могут взаимодействовать с переменными UEFI:

efivar — Библиотека и инструмент для работы с переменными UEFI (используется в efibootmgr)

efibootmgr — Инструмент для работы с настройками менеджера загрузки прошивки UEFI

uefivars — Выгружает список переменных UEFI с некоторой дополнительной информацией, связанной с PCI (использует код efibootmgr).

efitools — Инструменты для манипулирования платформами UEFI secure boot

Ubuntu’s Firmware Test Suite — Набор тестов, выполняющий проверку исправности прошивок ПК Intel/AMD

efibootmgr

Если efibootmgr не работает в вашей системе, вы можете перезагрузиться в #UEFI Shell и использовать bcfg для создания загрузочной записи для загрузчика.
Если вы не можете использовать efibootmgr , некоторые прошивки UEFI позволяют пользователям напрямую управлять загрузочными записями UEFI из интерфейса времени загрузки. Например, некоторые прошивки имеют опцию «Add New Boot Option», которая позволяет выбрать локальный системный раздел EFI и вручную ввести расположение приложения EFI, например, \EFI\refind\refind_x64.efi .
В приведённых ниже командах в качестве примера используется менеджер загрузки rEFInd.

Чтобы добавить новую загрузочную запись с помощью efibootmgr, необходимо знать три вещи:

Диск, содержащий системный раздел EFI (ESP). Например: /dev/sda , /dev/nvme0n1 .
Номер раздела ESP на этом диске. Y в /dev/sdaY или /dev/nvme0n1pY .
Путь к приложению EFI (относительно корня ESP).

Например, если вы хотите добавить запись для /efi/EFI/refind/refind_x64.efi , где /efi — это точка монтирования ESP, выполните

$ findmnt /efi

TARGET SOURCE FSTYPE OPTIONS /efi /dev/sda1 vfat rw,flush,tz=UTC

В данном примере это означает, что ESP находится на диске /dev/sda и имеет номер раздела 1. Путь к EFI-приложению относительно корня ESP — /EFI/refind/refind_x64.efi . Соответственно, можно загрузочную запись так:

# efibootmgr --create --disk /dev/sda --part 1 --loader /EFI/refind/refind_x64.efi --label "rEFInd Boot Manager" --unicode

# efibootmgr --create --disk /dev/nvme0n1p1 --loader /EFI/refind/refind_x64.efi --label "rEFInd Boot Manager" --unicode

Смотрите efibootmgr(8) или efibootmgr README для более подробной информации.

Примечание: UEFI использует обратный слэш \ в качестве разделителя в путях, но efibootmgr автоматически конвертирует UNIX-разделители / .

Отключение доступа к переменным UEFI

Доступ к UEFI потенциально может нанести вред не только на уровне ОС. Иногда возможно даже «окирпичивание» устройства на некоторых забагованных реализациях UEFI. [3]

Так как доступ к переменным UEFI не требуется для ежедневного использования системы, вы можете отключить его, чтобы избежать потенциальных проблем безопасности или случайного вреда.

efivarfs /sys/firmware/efi/efivars efivarfs ro,nosuid,nodev,noexec 0 0

Примечание: #Пользовательские инструменты UEFI перестанут работать, поэтому выполните все нужные настройки заранее. Команды, связанные с UEFI (например, systemctl reboot —firmware-setup ), тоже перестанут работать.

UEFI Shell

Командная оболочка UEFI (UEFI Shell) — это оболочка/терминал для прошивки, позволяющий запускать EFI-приложения, в том числе загрузчики UEFI. Кроме того, оболочка может использоваться для получения различной информации о системе или прошивке, например, распределение памяти (memmap), изменение переменных менеджера загрузки (bcfg), запуск программ разметки (diskpart), загрузки драйверов UEFI, редактирование текстовых файлов (edit), hexedit и т.д.

Получение UEFI Shell

Можно получить UEFI Shell из проекта TianoCore EDK2 (лицензия BSD):

Shell v2:
- На установочном носителе Arch: /shellx64.efi — это копия файла /usr/share/edk2-shell/x64/Shell_Full.efi , доступного на момент сборки ISO.
- edk2-shell предоставляет x86_64 Shell для x86_64 (64-bit) UEFI и IA32 Shell для IA32 (32-bit) UEFI — скомпилировано непосредственно из последнего выпуска TianoCore EDK2.
- uefi-shell-gitAUR предоставляет x86_64 Shell для x86_64 (64-bit) UEFI и IA32 Shell для IA32 (32-bit) UEFI — компилируется непосредственно из последнего выпуска TianoCore EDK2.
- Прекомпилированные файлы UEFI Shell v1 от TianoCore (больше не обновляется).
- Прекомпилированный UEFI Shell v2 с bcfg, модифицированный для работы с прошивкой UEFI pre-2.3 [устаревшая ссылка 2023-07-30 ⓘ] — из загрузчика Clover EFI.
- Прекомпилированный UEFI Shell v2, совместимый с широким спектром прошивок — из загрузчика OpenCore. В архиве: EFI/OC/Tools/OpenShell.efi .
Shell v2 лучше всего работает в системах UEFI 2.3+ и рекомендуется вместо Shell v1. Shell v1 должен работать во всех системах UEFI независимо от версии спецификации, которой соответствует прошивка. Дополнительная информация доступна на ShellPkg и в теме из списка рассылки EDK2 — Inclusion of UEFI shell in Linux distro iso.

Запуск UEFI Shell

Некоторые материнские платы Asus и другие материнские платы, использующие AMI Aptio x86_64 UEFI (начиная с Sandy Bridge и далее), имеют опцию под названием Launch EFI Shell from filesystem device. Для этих материнских плат скопируйте x86_64 UEFI Shell в корень системного раздела EFI с именем shellx64.efi .
- Установочный носитель Arch Linux имеет shellx64.efi в корне тома.
- rEFInd и systemd-boot автоматически добавляют пункт меню для UEFI Shell, если находят shellx64.efi в корне системного раздела EFI.
Системы с прошивкой Phoenix SecureCore Tiano UEFI имеют встроенный UEFI Shell, которую можно запустить с помощью клавиши F6 , F11 или F12 .

Примечание: Если вам не удаётся запустить UEFI Shell из прошивки напрямую, используя любой из вышеперечисленных методов, создайте USB-накопитель FAT32 с файлом EFI, скопированным в /точка_монтирования_USB/EFI/BOOT/BOOTx64.EFI . Этот USB должен появиться в меню загрузки прошивки, и загрузка с него запустит UEFI Shell.

Важные команды UEFI Shell

Команды UEFI Shell обычно поддерживают опцию -b , которая приостанавливает вывод после каждой страницы. Выполните команду help -b , чтобы получить список доступных внутренних команд. Доступные команды либо встроены в оболочку, либо являются отдельными приложениями EFI.

bcfg

bcfg изменяет записи UEFI NVRAM, что позволяет пользователю изменить загрузочные записи или опции драйвера. Эта команда подробно описана на странице 96 (раздел 5.3) документа UEFI Shell Specification 2.2.
- Пробуйте bcfg только если efibootmgr не смог создать рабочие загрузочные записи в вашей системе.
- Официальный бинарный файл UEFI Shell v1 не поддерживает команду bcfg . В разделе #Получение UEFI Shell есть модифицированный бинарный файл UEFI Shell v2, который может работать в прошивках UEFI pre-2.3.
Список текущих загрузочных записей:
```
Shell> bcfg boot dump -v
```
Добавление пункта загрузки для rEFInd (например) как четвёртый (нумерация начинается с нуля) пункт в меню загрузки:
```
Shell> bcfg boot add 3 FS0:\EFI\refind\refind_x64.efi "rEFInd Boot Manager"
```
где FS0: соответствует системному разделу EFI, а FS0:\EFI\refind\refind_x64.efi — запускаемый файл.

Чтобы добавить запись для загрузки непосредственно в систему без загрузчика, настройте пункт загрузки, используя ваше ядро в качестве EFISTUB:
```
Shell> bcfg boot add N fsV:\vmlinuz-linux "Arch Linux" Shell> bcfg boot -opt N "root=/dev/sdX# initrd=\initramfs-linux.img"
```
где N — приоритет, V — номер тома системного раздела EFI, а /dev/sdX# — корневой раздел.

Удаление четвёртого пункта загрузки:
```
Shell> bcfg boot rm 3
```
Перемещение четвёртого пункта на место первого пункта (что сделает его записью по умолчанию в загрузочном меню UEFI):
```
Shell> bcfg boot mv 3 0
```
Справка команды bcfg:
```
Shell> help bcfg -v -b
```
```
Shell> bcfg -? -v -b
```
map

map отображает список сопоставлений устройств, то есть имена доступных файловых систем ( FS0 ) и устройств хранения ( blk0 ).

Перед выполнением команд, связанных с файловой системой, таких как cd или ls , нужно переключить оболочку на соответствующую файловую систему, набрав её имя:
```
Shell> FS0: FS0:\> cd EFI/
```
edit

edit предоставляет базовый текстовый редактор с интерфейсом, похожим на nano, но немного менее функциональный. Он обрабатывает кодировку UTF-8 и поддерживает окончания строк LF и CRLF.

Например, для редактирования файла refind.conf в системном разделе EFI (доступен в прошивке как FS0: ):
```
Shell> edit FS0:\EFI\refind\refind.conf
```
Нажмите Ctrl+e для справки.

Драйверы UEFI

Драйверы UEFI — это программы, поддерживающие определённую функциональность. Например, доступ к NTFS-разделам обычно невозможен через UEFI shell. В пакете efifs есть драйверы, поддерживающие чтение многих других файловых систем из EFI shell. Для использования можно скопировать такой драйвер на раздел, доступ к которому возможен из UEFI shell, а затем в UEFI shell выполнить такие команды:
```
Shell> load ntfs_x64.efi Shell> map -r
```
После выполнения команды map у пользователя появится доступ к разделам, отформатированным в формате NTFS, через UEFI shell.

Загрузочные носители UEFI

Создание загрузочного UEFI USB из ISO

Удаление поддержки UEFI с оптического носителя
- Этот раздел описывает удаление поддержки загрузки UEFI только с CD/DVD (загрузка с оптического носителя через EL Torito), но не с USB-накопителя.
- Чтобы скрыть оборудование UEFI на USB-накопителе, используйте редактор разделов после копирования ISO на флэш-накопитель. Удалите раздел типа EF . Не принимайте предложение сконвертировать таблицу разделов в GPT.
Большинство 32-битных компьютеров Mac с EFI и некоторые 64-битные компьютеры Mac с EFI отказываются загружаться с загрузочного CD/DVD с UEFI(X64)+BIOS. Если вы хотите продолжить установку с оптического носителя, возможно, придётся сначала удалить поддержку UEFI.

Распакуйте ISO, пропуская каталоги, специфичные для UEFI:
```
$ mkdir extracted_iso $ bsdtar -x --exclude=EFI/ --exclude=loader/ -f archlinux-версия-x86_64.iso -C extracted_iso
```
Затем пересоберите ISO, исключив поддержку загрузки оптических носителей UEFI, используя xorriso(1) из пакета libisoburn . Обязательно установите правильную метку тома, например ARCH_202103 ; её можно получить с помощью file(1) на исходном ISO.
```
$ xorriso -as mkisofs \ -iso-level 3 \ -full-iso9660-filenames \ -joliet \ -joliet-long \ -rational-rock \ -volid "ARCH_ГГГГММ" \ -appid "Arch Linux Live/Rescue CD" \ -publisher "Arch Linux https://archlinux.org>" \ -preparer "prepared by $USER" \ -eltorito-boot syslinux/isolinux.bin \ -eltorito-catalog syslinux/boot.cat \ -no-emul-boot -boot-load-size 4 -boot-info-table \ -isohybrid-mbr "extracted_iso/syslinux/isohdpfx.bin" \ -output archlinux-версия-x86_64-noUEFI.iso extracted_iso/
```
Запишите archlinux-версия-x86_64-noUEFI.iso на оптический носитель, и установка с него должна пройти нормально.

Тестирование UEFI на системах без его поддержки

OVMF для виртуальных машин

OVMF — это проект TianoCore для поддержки UEFI в виртуальных машинах. OVMF содержит образец прошивки UEFI и отдельное энергонезависимое хранилище переменных для QEMU.

Его можно установить с помощью пакета edk2-ovmf .

Рекомендуется сделать локальную копию хранилища энергонезависимых переменных для вашей виртуальной машины:
```
$ cp /usr/share/edk2-ovmf/x64/OVMF_VARS.fd my_uefi_vars.fd
```
Чтобы использовать прошивку OVMF и это хранилище переменных, используйте следующие опции QEMU:
```
-drive if=pflash,format=raw,readonly,file=/usr/share/edk2-ovmf/x64/OVMF_CODE.fd \ -drive if=pflash,format=raw,file=my_uefi_vars.fd
```
```
$ qemu-system-x86_64 -enable-kvm -m 1G -drive if=pflash,format=raw,readonly,file=/usr/share/edk2-ovmf/x64/OVMF_CODE.fd -drive if=pflash,format=raw,file=my_uefi_vars.fd …
```
DUET для BIOS-систем

DUET был проектом TianoCore, который позволял сделать chainloading полного окружения UEFI из системы BIOS, способом, аналогичным загрузке ОС BIOS. Этот метод подробно обсуждается. Собранные образы DUET можно загрузить из одного из репозиториев [устаревшая ссылка 2023-04-07 ⓘ] . Смотрите также конкретные инструкции по настройке DUET [устаревшая ссылка 2023-04-07 ⓘ] . Однако по состоянию на ноябрь 2018 года код DUET был удалён из git-репозитория TianoCore.

Вы также можете попробовать Clover, который предоставляет модифицированные образы DUET, которые могут содержать некоторые специфические для системы исправления и чаще обновляются по сравнению с репозиториями gitlab.

Решение проблем

Загрузка в Arch Linux после застревания в Windows

Если вы застряли в Windows, то для возвращения в Arch Linux зайдите в расширенные параметры запуска в Windows с помощью команды Windows PowerShell shutdown /r /o или через Параметры > Обновление и безопасность > Восстановление > Расширенные параметры запуска и выберите Перезагрузить сейчас. Когда вы достигнете меню выбора действия, выберите Использовать устройство, которое фактически содержит ваши варианты загрузки UEFI (не ограничивается USB или CD, но может также загружать операционную систему на жёстком диске), и выберите «Arch Linux».

Открытие настроек прошивки без функциональных клавиш

На некоторых ноутбуках, например Lenovo XiaoXin 15are 2020, использование клавиш вроде F2 или F12 ничего не даёт. Возможно, это можно исправить, вернув ноутбуки OEM-производителю для восстановления информации на материнской плате, но иногда это невозможно или нежелательно. Однако есть и другие способы войти в настройки прошивки:
```
$ systemctl reboot --firmware-setup
```
Пользовательские инструменты не могут изменить переменные UEFI

Если никакой инструмент пользовательского пространства не может изменить данные переменных UEFI, проверьте существование файлов /sys/firmware/efi/efivars/dump-* . Если они существуют, удалите их, перезагрузитесь и попробуйте ещё раз. Если это не помогло, попробуйте загрузиться с параметром ядра efi_no_storage_paranoia , чтобы отключить проверку пространства хранения переменных UEFI ядра, которая может препятствовать изменению переменных UEFI.

Важно: efi_no_storage_paranoia следует использовать только при необходимости и не оставлять в качестве обычной опции загрузки. Этот параметр отключает защиту, которая была введена, чтобы помочь избежать окирпичивания устройств при переполнении NVRAM. Смотрите FS#34641 для подробностей.

Не удаётся создать загрузочные записи с помощью efibootmgr

Некоторые комбинации версий ядра и efibootmgr могут не работать. Это может быть связано с нехваткой свободного места в NVRAM. Проверьте способы, описанные в разделе #Пользовательские инструменты не могут изменить переменные UEFI.

Вы также можете попробовать откатить efibootmgr до версии 0.11.0. Она работает с Linux 4.0.6. Смотрите обсуждение FS#34641, в частности закрывающий комментарий.

Windows изменяет порядок загрузки

Если при двойной загрузке с Windows материнская плата сразу же загружает Windows вместо выбранного приложения EFI, существует несколько возможных причин и способов их устранения.
- Убедитесь, что в настройках Windows отключен быстрый запуск (Fast Startup).
- Убедитесь, что Secure Boot в настройках прошивки отключен (если у вас неподписанный загрузчик).
- Убедитесь, что Windows Boot Manager не прописывается прошивкой на первое место: например, сравните вывод efibootmgr с тем, что вы видите в настройках UEFI. Некоторые материнские платы автоматически ставят Windows на первое место, если обнаруживают его. В частности, это наблюдалось на ноутбуке Packard Bell.
- Если ваша материнская плата загружает путь по умолчанию ( \EFI\BOOT\BOOTx64.EFI ), этот файл может быть перезаписан загрузчиком Windows. Попробуйте установить правильный путь загрузки, например, с помощью efibootmgr.
- Если предыдущие шаги не сработали, можно указать загрузчику Windows запустить другое приложение EFI. В командной строке, запущенной от имени администратора, выполните: bcdedit /set «» path «\EFI\путь\к\app.efi«
- Как вариант, отключите Windows Boot Manager, выполнив efibootmgr -A -b bootnumber от имени root. Замените bootnumber на фактический номер записи Windows Boot Manager; вы можете узнать его, запустив efibootmgr без опций.
- Ещё можно установить скрипт запуска в Windows, который обеспечивает правильную установку порядка загрузки при каждой загрузке Windows.
  1. Запустите командную строку от имени администратора. Выполните bcdedit /enum firmware и найдите нужную загрузочную запись.
  2. Скопируйте его идентификатор вместе с фигурными скобками, например
  3. Создайте bat-файл с командой bcdedit /set «» DEFAULT » «
В качестве альтернативы можно воспользоваться планировщиком заданий:

Повторите шаги 1-3, описанные выше, для создания bat-файла.

Запустите taskschd.msc и выберите пункт меню Действие > Создать задачу.

На вкладке Общие: Введите подходящие Имя и Описание. Убедитесь, что выбранная учётная запись является администратором, а не обычным пользователем. Выберите пункт «Выполнять для всех пользователей«. Поставьте галочку «Выполнить с наивысшими правами«.

На вкладке Триггеры создайте триггер При входе в систему.

На вкладке Действия нажмите Создать, затем Обзор и выберите ваш bat-файл, созданный в первом шаге.

На вкладке Условия снимите галочки в секции Питание, чтобы скрипт запускался при работе от батареи (для ноутбуков).

Нажмите OK и по необходимости введите пароль от учётной записи администратора, выбранного в шаге 3.

Чёрный экран при загрузке с USB

Возможно, это проблемы с KMS. Попробуйте отключить KMS при загрузке с USB.

Загрузчик UEFI не отображается в меню прошивки

Некоторые прошивки не поддерживают пользовательские загрузочные записи. Вместо этого они загружаются только из жёстко закодированных загрузочных записей.

Типичное решение — не полагаться на загрузочные записи в NVRAM и установить загрузчик на один из распространённых путей в системном разделе EFI.

В следующих разделах описаны варианты.

Стандартные пути загрузки для съёмных носителей

Спецификация UEFI определяет стандартные пути к файлам EFI для загрузки со съёмных носителей:

esp/EFI/BOOT/BOOTx64.EFI для x86_64 UEFI

esp/EFI/BOOT/BOOTIA.EFI для IA32 UEFI.

Хотя спецификация определяет их только для съёмных дисков, большинство прошивок поддерживают их загрузку с любого диска.

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

Расположение загрузчика Microsoft Windows

На некоторых материнских платах с UEFI, например, на платах с чипсетом Intel Z77, добавление записей с помощью efibootmgr или bcfg из UEFI Shell не работает, поскольку они не отображаются в списке меню загрузки после добавления в NVRAM.

Эта проблема вызвана тем, что материнские платы умеют загружать только Microsoft Windows. Чтобы решить эту проблему, необходимо поместить файл .efi в то место, которое использует Windows.

Скопируйте файл BOOTx64.EFI с установочного носителя Arch Linux ( FS0: ) в каталог Microsoft вашего раздела ESP на жёстком диске ( FS1: ). Для этого загрузитесь в UEFI Shell и введите:

Shell> mkdir FS1:\EFI\Microsoft Shell> mkdir FS1:\EFI\Microsoft\Boot Shell> cp FS0:\EFI\BOOT\BOOTx64.EFI FS1:\EFI\Microsoft\Boot\bootmgfw.efi

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

Загрузочные записи, созданные с помощью efibootmgr, не отображаются в UEFI

efibootmgr может не обнаружить EDD 3.0 и в результате создать непригодные для использования загрузочные записи в NVRAM. Смотрите efibootmgr issue 86 для подробностей.

Чтобы обойти эту проблему, при создании загрузочных записей вручную добавьте опцию -e 3 к команде efibootmgr. Например:

# efibootmgr --create --disk /dev/sda --part 1 --loader /EFI/refind/refind_x64.efi --label "rEFInd Boot Manager" --unicode -e 3

Для исправления программ установки загрузчиков, таких как grub-install и refind-install , создайте скрипт-обёртку /usr/local/bin/efibootmgr и сделайте его исполняемым:

/usr/local/bin/efibootmgr

#!/bin/sh exec /usr/bin/efibootmgr -e 3 "$@"

Загрузочная запись UEFI исчезает после удаления диска, на который она ссылается

Некоторые прошивки удаляют загрузочные записи, относящиеся к дискам, которые недоступны во время загрузки. Это может быть проблемой при частом отсоединении/присоединении дисков или при загрузке со съёмного диска.

Решением является установка загрузчика в стандартный путь загрузки.

Загрузочные записи удаляются случайным образом

Некоторые материнские платы могут удалять загрузочные записи из-за нехватки свободного места в NVRAM вместо того, чтобы выдавать ошибку при их создании. Чтобы этого не происходило, уменьшите количество добавляемых загрузочных записей путём минимизации процесса создания записей, а также уменьшите количество автоматических записей от Compatibility Support Module (CSM), отключив его в настройках UEFI. Смотрите BBS#1608838.

Другой причиной может быть то, что спецификация UEFI позволяет производителям выполнять «обслуживание NVRAM» в процессе загрузки. Эти производители делают это просто: они просто ищут приложения EFI в заранее определённых, жёстко закодированных путях на устройстве. Если таковых не обнаруживается, они делают вывод об отсутствии ОС на устройстве и стирают все загрузочные записи из NVRAM, связанные с ним, поскольку предполагают, что NVRAM содержит повреждённые или устаревшие данные. Если вы не планируете устанавливать Windows, но хотите загрузить ядро Linux непосредственно из прошивки, то одним из возможных обходных путей является создание пустого файла esp/EFI/BOOT/BOOTX64.EFI :

# mkdir -p esp/EFI/BOOT # touch esp/EFI/BOOT/BOOTX64.EFI

После этого восстановите удалённую загрузочную запись. Теперь после перезагрузки материнская плата будет видеть «фальшивую ОС» и не должна стирать другие загрузочные записи из NVRAM. При желании, конечно, можно заменить загрузчик фальшивой ОС на реальное EFI-приложение, если использовать это стандартное имя.

Смотрите также

UEFI (Википедия)

UEFI Forum — содержит официальные спецификации UEFI — таблица разделов GUID является частью спецификации UEFI

UEFI boot: how does that actually work, then? — A blog post by AdamW

x86_64 UEFI — документация ядра

Intel’s page on EFI

Intel Architecture Firmware Resource Center [устаревшая ссылка 2023-07-30 ⓘ]

Matt Fleming — The Linux EFI Boot Stub

Matt Fleming — Accessing UEFI Variables from Linux

Rod Smith — Linux on UEFI: A Quick Installation Guide

UEFI Boot problems on some newer machines (LKML)

Intel’s TianoCore Project для прошивки UEFI с открытым исходным кодом, которая включает DuetPkg для прямой загрузки на основе BIOS и OvmfPkg, используемый в QEMU и Oracle VirtualBox

FGA: The EFI boot process

Microsoft’s Windows and GPT FAQ

Convert Windows x64 from BIOS-MBR mode to UEFI-GPT mode without Reinstall

Create a Linux BIOS+UEFI and Windows x64 BIOS+UEFI bootable USB drive

Rod Smith — A BIOS to UEFI Transformation

EFI Shells and Scripting — Intel Documentation

UEFI Shell — Intel Documentation

UEFI Shell — bcfg command info

The bootstrap process on EFI systems

Настройка UEFI-загрузчика. Самое краткое руководство в мире

Как устроена загрузка современных ОС? Как при установке системы настроить загрузку посредством UEFI, не утонув в руководствах и ничего не сломав?

Я обещал «самое краткое руководство». Вот оно:

Создаём на диске таблицу разделов GPT

Создаём FAT32-раздел на пару сотен мегабайт

Скачиваем из интернета любой UEFI-загрузчик
(нам нужен сам загрузчик, это один бинарный файл!)

Переименовываем и кладем этот файл на созданный раздел по адресу /EFI/Boot/bootx64.efi

Создаём текстовый конфиг, кладем его там, где загрузчик ожидает его увидеть
(настройка и местоположение конфига зависят от конкретной реализации загрузчика, эта информация доступна в интернете)

После перезагрузки видим меню загрузчика
(Если на диске установлена Windows 8 или 10 — с большой вероятностью это руководство сокращается до пунктов 3 — 5.)

TL;DR не надо прописывать путь к загрузчику в новых загрузочных записях UEFI — надо файл загрузчика расположить по стандартному «пути по-умолчанию», где UEFI его найдет, и вместо загрузочного меню UEFI пользоваться меню загрузчика, которое гораздо проще и безопаснее настраивается

Как делать не надо

Есть, на самом-то деле, несколько способов настроить UEFI-загрузку. Я начну с описания других вариантов — чтобы было понятно, как (и почему) делать не надо. Если вы пришли за руководством — мотайте в самый низ.

Не надо лезть в NVRAM и трогать efivars

Наиболее «популярная» процедура установки загрузчика в систему такова: установщик ОС создаёт специальный раздел, на нём — структуру каталогов и размещает файлы загрузчика. После этого он с помощью особой утилиты (efibootmgr в linux, bcdedit в windows) взаимодействует с прошивкой UEFI-чипа, добавляя в неё загрузочную запись. В этой записи указывается путь к файлу загрузчика (начиная от корня файловой системы) и при необходимости — параметры. После этого в загрузочном меню компьютера появляется опция загрузки ОС. Для linux существует возможность вообще обойтись без загрузчика. В загрузочной записи указывается путь сразу к ядру вместе со всеми параметрами. Ядро должно быть скомпилировано с опцией EFISTUB (что давно является стандартом для большинства дистрибутивов), в этом случае оно содержит в себе заголовок «исполняемого файла EFI», позволяющий прошивке его запускать без внешнего загрузчика.

При старте системы, когда пользователь выбирает нужную ему загрузочную запись, прошивка UEFI сперва ищет на прописанном в этой записи диске особый EFI-раздел, обращается к файловой системе на этом разделе (обязательно FAT или FAT32), и запускает загрузчик. Загрузчик считывает из файла настроек свой конфиг, и либо грузит ОС, либо предоставляет загрузочное меню. Ничего не замечаете? Да, у нас два загрузочных меню — одно на уровне прошивки чипа UEFI, другое — на уровне загрузчика. В реальности о существовании второго пользователи могут даже не догадываться — если в меню всего один пункт, загрузчик Windows начинает его грузить без лишних вопросов. Увидеть экран с этим меню можно, если поставить вторую копию Windows или просто криво её переустановить.

Обычно для управления загрузочными записями руководства в интернете предлагают взаимодействовать с прошивкой UEFI. Есть аж пять основных вариантов, как это можно сделать: efibootmgr под linux, bcdedit в windows, какая-то софтина на «Маках», команда bcfg утилиты uefi shell (запускается из-под UEFI, «на голом железе» и без ОС, поскольку скомпилирована в том самом особом формате) и для особо качественных прошивок — графическими средствами UEFI (говоря популярным языком, «в настройках BIOS»).

За всеми вышенаписанными «многобуков» вы могли легко упустить такую мысль: пользователь, чтобы изменить настройки программной части (например, добавить параметр запуска ОС), вынужден перезаписывать flash-память микросхемы на плате. Есть ли тут подводные камни? О да! Windows иногда способна сделать из ноутбука кирпич, linux тоже, причём разными способами. Качество прошивок часто оставляет желать лучшего — стандарты UEFI либо реализованы криво, либо не реализованы вообще. По логике, прошивка обязана переживать полное удаление всех переменных efivars без последствий, не хранить в них критичных для себя данных и самостоятельно восстанавливать значения по-умолчанию — просто потому что пользователь имеет к ним доступ, и вероятность их полного удаления далека от нуля. Я лично в процессе экспериментов неоднократно (к счастью, обратимо) «кирпичил» свой Lenovo — из загрузочного меню исчезали все пункты, включая опцию «зайти в настройки».

Работа с загрузочными записями UEFI — тоже не сахар. К примеру, утилита efibootmgr не имеет опции «редактировать существующую запись». Если ты хочешь немного изменить параметр ядра — ты удаляешь запись целиком и добавляешь её снова, уже измененную. При этом строка содержит в себе двойные и одинарные кавычки, а также прямые и обратные слеши в не особо очевидном порядке. Когда я наконец заставил эту магию работать — я сохранил её в виде bash-скриптов, которые до сих пор валяются у меня в корневой ФС:

efibootmgr -c -L "Archlinux (debug)" -l '\EFI\archlinux\vmlinuz-linux' -u "root=/dev/mapper/vg1-lvroot rw initrd=\EFI\archlinux\initramfs-linux.img systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M enforcing=0"

Не надо использовать GRUB

Это чёртов мастодонт, 90% функциональности которого предназначено для дисков с MBR. Для настройки необходимо отредактировать ряд файлов, после чего выполнить команду генерации конфига. На выходе получается огромная малопонятная нормальному человеку простыня. В составе — гора исполняемых файлов. Ставится командой, которую просто так из головы не возьмешь — надо обязательно лезть в документацию

grub-install --target=x86_64-efi --efi-directory=esp_mount --bootloader-id=grub

Для сравнения — самый простенький UEFI-bootloader, который есть в составе пакета systemd, ставится командой

bootctl install --path=/boot

Эта команда делает ровно две вещи: копирует исполняемый файл загрузчика на EFI-раздел и добавляет свою загрузочную запись в прошивку. А конфиг для неё занимает ровно СЕМЬ строчек.

«Самое краткое руководство» — чуть более подробно

Загрузочное меню надо реализовывать на уровне загрузчика — править текстовые конфиги гораздо проще и безопасней.

Загрузочная запись нам не нужна — дело в том, что при выставлении в настройках BIOS загрузки с диска прошивка UEFI сначала ищет на нём EFI-раздел, а затем пытается исполнить файл по строго фиксированному адресу на этом разделе: /EFI/Boot/BOOTX64.EFI

Что такое «EFI-раздел»? В теории, он должен иметь особый тип «EFI System» (ef00). На практике, годится первый раздел на GPT-диске, отформатированный в FAT32 и имеющий достаточно места, чтобы разместить загрузчик и вспомогательные файлы (если есть).

Пункт 3: «Скачиваем из интернета любой UEFI-загрузчик». Что это значит? Загрузчик — это просто исполняемый файл определенного формата, к которому в комплекте идет конфиг. К примеру, если у вас есть под рукой установленный пакет с systemd — файл загрузчика можно найти по адресу /usr/lib/systemd/boot/efi/systemd-bootx64.efi, переименовать его в bootx64.efi и скопировать в /EFI/Boot/ на EFI-разделе. Нет под рукой systemd? Скачайте архив с сайта Archlinux. Или с репозитария Ubuntu. Или Debian. Есть под рукой система с Windows? Возьмите виндовый загрузчик оттуда, тоже сгодится )) Если сумеете настроить, я честно говоря не пробовал.

Пункт 4: «Настроить конфиг». Как и обычная программа, когда загрузчик запускается — он ожидает найти по определенным путям файлы конфигурации. Обычно эту информацию легко найти в интернете. Для загрузчика systemd-boot нам необходимо в корне EFI-раздела создать каталог «loader», а в нём файл «loader.conf» с тремя строчками (привожу свои):

default archlinux timeout 10 editor 1

Параметр editor отвечает за возможность отредактировать пункт загрузочного меню перед запуском.

Рядом с loader.conf необходимо создать каталог entries — один файл в нём будет отвечать за одну загрузочную запись в boot-меню. У меня там один файл arch.conf с таким содержанием:

title Arch Linux linux /efi/archlinux/vmlinuz-linux initrd /efi/archlinux/initramfs-linux.img options root=/dev/mapper/vg1-lvroot rw initrd=\EFI\archlinux\intel-ucode.img

Я не упомянул, но довольно очевидно — ядро и initramfs должны лежать в одной файловой системе с загрузчиком, то есть на EFI-разделе. Пути к ним в конфигах отсчитываются от корня этой ФС.

Другие загрузчики

systemd-boot очень простой и предоставляет спартанского вида чёрно-белое меню. Есть варианты красивей, если душа просит красоты.

rEFind — очень красивый загрузчик. Скачать можно тут в виде deb-пакета. Использую на своём ноуте. Умеет создавать загрузочное меню автоматически, без конфига — просто сканируя файлы.

Clover. Позволяет выставлять нативное разрешение экрана, имеет поддержку мыши на экране загрузки, разные темы оформления. Дефолтная тема ужасна, конфиг в виде xml нечитаем, настроить не смог.

Различные неочевидные последствия

Вы можете легко попробовать эту схему в работе. Берёте USB-флешку, форматируете в таблицу разделов GPT, создаете FAT-раздел и копируете туда загрузчик. Комп сможет с неё стартовать.

Если просто скопировать на такую флешку boot-раздел установленного linux — система будет спокойно загружаться с флешки, не видя разницы.

О UEFI

Вообще, представленный в статье материл не относятся исключительно к Ubuntu. В статье освящены и вопросы на прямую не зависящие от ОС.

Статья сфокусирована на объяснении понятий и принципов, а также важных и интересных возможностях UEFI. Более детально сам процесс установки и настройки загрузки Ubuntu в UEFI режиме описан в этой статье или в этой.

Практически все современные компьютеры оснащены системной прошивкой позволяющей загрузиться через UEFI. На более старых компьютерах за загрузку отвечал BIOS. В чем разница и как с этим всем жить — давайте разберемся.

BIOS

Старый добрый BIOS отвечает за первичное тестирование (POST), инициализацию практически всего аппаратного обеспечения компьютера и за инициализацию загрузки ОС с дискового носителя (хотя сегодня уже не все носители имеют в своей конструкции диск ). Собственно вся процедура инициализации загрузки ОС заключалась в двух шагах:

по настройкам BIOS найти устройство (диск) с которого надо загрузиться.

считать в память MBR, т.е. первый сектор (512 байт) диска и запустить находящийся там код на исполнение.

За все остальное (даже за работу с таблицей разделов, которая располагается в конце MBR) отвечает тот самый маленький код, который расположен в первых 446 байтах MBR.

Проблемой BIOS принято считать то, что много работы он делает зря (чем затягивает процесс загрузки системы). Практически всю его работу по инициализации и поддержке оборудования компьютера все современные ОС попросту игнорируют и повторно инициализируют и далее работают через свои драйвера. Все, что дает BIOS, было реально востребовано только в ранних версиях DOS…

Другой проблемой являются ограничения, которые установлены для поддержки BIOS: это 16-разрядный реальный режим работы процессора с набором команд i8086, 1Мб адресуемого пространства памяти и периферия (клавиатура, видео адаптер, контроллер прямого доступа в память) совместимая с IBM AT. На сегодняшний день, требовать от 64-х разрядного многоядерного, многопоточного процессора совместимости с одноядерным и однопоточным 16-разрядным i8086 — уже немного смешно, а требование совместимости по периферии с IBM PC-AT(компьютер 1984-го года выпуска) уже даже не смешно, а очень грустно.

(U)EFI

Идеи отказаться от всего того ненужного, что делает BIOS, снять архаичные ограничения BIOS и сделать процесс инициализации и загрузки более гибким возникали уже очень давно, и различные попытки сделать это предпринимались, но IT-индустрия реально созрела к принятию нового общего стандарта загрузки персональных компьютеров только в начале этого века. В 2005 был создан консорциуму UEFI Forum, которому INTEL передал свою наработки по проекту Intel Boot Initiative (позже переименованному в EFI — Extensible Firmware Interface), начатому еще середине 90-х. Помимо Intel в консорциум вошли AMD, Apple, IBM, Microsoft и многие другие крупные IT-компании. Вместе с созданием консорциума спецификация EFI была переименована в UEFI (Unified Extensible Firmware Interface) 1) .

Основные концепции положенные в основу UEFI — «минималистичность», «модульность» и поддержка разных процессоров. Прошивка UEFI может быть собрана под 32-битный или 64-битный процессоры Intel, 32- или 64-битный процессор ARM, а также для процессоров Intel Itanium. Кроме того UEFI имеет собственный менеджер загрузки и умеет работать с файловыми системами на диске (по умолчанию только FAT32), а также умеет загружать драйверы для поддержки различного оборудования и любых файловых систем.
После включения компьютера и проведения первичного теста оборудования (на этом этапе разницы с BIOS нет) инициализируются только те подсистемы, которые необходимые для загрузки.

В некоторых режимах загрузки, которые обычно называют Fast-boot (или Fast-Startup), даже клавиатура может оставаться не инициализированной, пока не загрузится ОС. Некоторые настройки Fast-boot могут отключать работу со всеми USB устройствами и не будет возможности даже выбрать с чего грузиться компьютеру, ведь клавиатура не работает до тех пор, пока не загрузится ОС.

Причем, в отличии от BIOS, все компоненты которого записаны в постоянную (флеш) память, UEFI может хранить часть своего кода на диске — в специальном разделе ESP 2) . Это позволяет легко расширять, менять и обновлять код поддерживающий различные устройства компьютера без необходимости перепрограммировать постоянное ЗУ компьютера. А кроме драйверов для поддержки устройств на ESP разделе может хранится и поддержка протоколов, утилиты и даже собственная EFI-оболочка (shell), из-под которой можно запускать собственные EFI-приложения. Т.е. UEFI по сути — маленькая ОС (или псевдо-ОС). При этом загрузчик операционной системы становится обычным приложением, которое исполняется в окружении, предоставляемом псевдо-ОС UEFI. Подробнее о EFS разделе мы поговорим в главе ESP раздел.

UEFI реализует свой менеджер загрузки, он поддерживает мульти-загрузку: позволяет выбирать загрузку из нескольких ОС и/или утилит. Загрузчик ОС — это просто efi-приложение, которое хранится на ESP разделе. В ESP может храниться много приложений, и пункты меню загрузки могут ссылаться каждый на свое приложение (или на одно, но с передачей разных параметров). Кроме того, UEFI поддерживает ассоциацию нажатия клавиш с пунктами загрузки (выбор пункта загрузки осуществляется в зависимости от того какая нажата клавиша в момент загрузки). Т.о. UEFI берет на себя большую часть задач, которые раньше могли решать только загрузчики ОС (типа GRUB). Более подробно мы поговорим о менеджере загрузки UEFI в разделе Менеджер загрузки UEFI

Архитектура UEFI позволяет также загрузить драйвера устройств (необходимые для работы ОС и для процедуры загрузки). Да и само ядро ОС можно загрузить (по крайней мере ядро Linux, собранное с опцией UEFISTUB) непосредственно из UEFI (т.е. устранить загрузчик из процесса загрузки). Такую возможность мы разберем более детально чуть позже в разделе Загрузка ядра Linux непосредственно из UEFI.

Как и в случае с BIOS, UEFI — это стандарт, практической реализацией которого занимаются разные поставщики решений. Поэтому в реализации стандарта UEFI в прошивках разных поставщиков могут значительно отличаться (как визуально так и функциональным наполнением). Могут встречаться сильно урезанные по функционалу реализации (чаще в компьютерах выпущенных в 2000-х годах). Но базовые принципы работы UEFI в процессе загрузки различаться сильно не должны (он был определен и зафиксирован в самых ранних стандартах UEFI). Интерфейсы утилиты настройки могут сильно различаться, но значение имеет не способ оформления интерфейса, а те настройки, которые доступны для изменения через этот интерфейс.

Совместимость

Само собой, современные прошивки умеют эмулировать работу BIOS. Отвечает за совместимость с BIOS модуль CSM (Compatibility Support Module иногда он еще называется Legasy support). Когда CSM включен и при загрузке загрузиться в UEFI не удалось, то CSM пытается найти загрузчик ОС в первом секторе диска (MBR) или в специальном служебном разделе (при GPT разбивке диска). Если код загрузчика найден, то CSM считает, что установлена ОС, требующая поддержки режима BIOS, и, прежде чем загрузить и запустить код из MBR, CSM проделывает все те же шаги инициализации оборудования, что предусмотрены для BIOS.

Если вы планируете использовать только загрузку в варианте UEFI, то работу этого модуля лучше запретить в системной утилите вашей материнской платы (Firmware setup utility). Кроме того, загрузка в режиме SecureBoot (о ней будет рассказано ниже) явно требует, что бы работа модуля CSM была запрещена.

Собственно использовать сразу оба варианта загрузки (для разных ОС) — не стоит. Лучше для всех ОС установленных на данном компьютере использовать один вариант загрузки: через CSM или UEFI.

ESP раздел

Отдельно стоит рассмотреть служебный раздел UEFI. Раздел обязательно должен иметь специальный идентификатор UUID = C12A7328-F81F-11D2-BA4B-00A0C93EC93B (или тип EF если он создан на диске с таблицей разделов в MBR). По стандарту этот раздел должен иметь файловую систему FAT32 (в принципе стандарт допускает использование других ФС, но на практике это не распространено). Предусмотренная в стандарте структура каталогов довольно проста.

В корне системного раздела могут располагаться системные утилиты (например тот же шелл-интерпретатор).

В каталогах EFI\ <Поставщик>3) должны лежать загрузчики ОС указанного поставщика.

Если у UEFI нет явного указания какой загрузчик загружать, то он загружает файл EFI\BOOT\BOOTx64.EFI (…x32.EFI для 32-х битных платформ).

При установке UBUNTU (с загрузкой через UEFI) служебный раздел ESP монтируется в /boot/efi. И на ESP разделе создается каталог EFI\ubuntu в котором размещается загрузчик 4) GRUB и/или Shim (о них — чуть позже).

EFS раздел лучше создавать из установщика. Когда вы делаете его сами через gparted/parted/fdisk, то есть шанс сделать что-то не так (например выберете FAT16 вместо FAT32) и тогда UEFI не поймет, что это EFS раздел и не будет с него загружаться. Доверьте установщику выполнить работу, которую он умеет делать хорошо — делайте EFS раздел из установщика.

MBR и GPT

Еще одно «новшество» в индустрии относится к таблице разделов диска.

Во времена IBM-PC/AT и BIOS таблица разделов размещалась в первом секторе на диске, т.е. в MBR (Master Boot Record). В MBR хранится и исполняемый код загрузчика ОС и таблица разделов. Т.к. в 512 5) байт много не запихнешь, то таблица разделов была рассчитана только на 4 раздела. Изначальное ограничение на 4 раздела позже было обойдено через внедрение расширенного раздела — внутри него можно было создать множество логических разделов 6) .

Другой недостаток 7) : на указатели начала и конца раздела было зарезервировано 32 бита, что позволяло адресовать 2 терабайта (что в те давние времена казалось просто астрономически много ).

Однако уже к началу 2010-х на рынке стали появляться диски более 2Тб. Но к этому времени уже набрал популярность стандарт таблицы разделов GPT (GUID Partition Table). В GPT число разделов практически не ограничено (по умолчанию 128, но можно и больше) и установлена новая планка для размера диска: 9,4 ЗБ, т.е 9,4 × 10^21 байт (на сегодня этот размер вновь выглядит астрономически большим… )

К чему я упомянул про таблицы разбиения дисков? А к тому, что, несмотря на то, что первоначально UEFI планировалось использовать только с GPT, а BIOS умел работать с MBR (вернее код в MBR работает с таблицей разделов расположенной в конце MBR), но в реальной жизни и BIOS (вернее сказать CSM) научили понимать GPT, и для UEFI предусмотрели использование таблицы разделов из MBR.

EFS раздел может быть также создан в таблице разделов формата ISO9660 (стандарт используемый для разметки CD/DVD оптических лисков). Это позволяет загружаться в режиме UEFI и с CD/DVD.

Получившаяся в результате «солянка» (из 4-х допустимых вариантов: UEFI + MBR, UEFI + GPT, BIOS/CSM + MBR и BIOS/CSM + GPT) создает некоторую путаницу и недопонимание. Давайте попробуем во всем этом разобраться более детально.

Что нужно для того что бы ОС грузилась через BIOS?

Несмотря на то, что загрузка в режиме BIOS уже не современна, не модна , а главное — технологически устарела, но, уверен, будет еще много сторонников этого пути, на протяжении долгих лет… Однако я не могу найти ни одного разумного довода использовать этот вариант если и ОС и компьютер поддерживают загрузку через UEFI.

В первую очередь, для загрузки через BIOS, в утилите настройки вашего компьютера должна быть разрешена работа модуля CSM. Само собой, режим SecureBoot (о нем рассказано чуть ниже) в таком варианте организовать невозможно в принципе.

Если разбивка диска — c таблицей разделов в MBR (вариант «BIOS/CSM + MBR»), то ничего дополнительно не нужно (это сочетание собственно и есть оригинальная конфигурация для варианта загрузки через BIOS).

А вот если у вас диск размечен через GPT (вариант «BIOS/SCM + GPT»), то возникают некоторые сложности.
В первую очередь: не совсем ясно — куда разместить код, который ранее размещался в MBR. Да, в GPT первый блок размером в 512 байт зарезервирован и в нем даже есть защитная версия таблицы разделов (в формате принятом для MBR). В защитной таблице разделов записан единственный раздел размером на все адресуемое пространство диска 8) и с типом EE. Само собой, с единственной фейковой записью в таблице разделов никакой код в MBR не сможет корректно отработать процесс загрузки 9) .
Еще одно проблемное место возникает когда загрузчик использует для размещения своего кода сектора на первом треке диска за MBR (к примеру так поступает GRUB). В GPT на этом месте уже идут служебные записи (заголовок таблицы разделов и сами записи о разделах).
Для решения обоих этих проблем предусмотрен специальный бинарный (он не форматируется ни в какую ФС) раздел BIOS-Boot (Тип = EF02 или UUID = 21686148-6449-6E6F-744E-656564454649). Установщик ОС может прописать на этот раздел весь тот код, который ранее размещался в MBR и на незанятом пространстве за MBR. Этот раздел должен иметь установленный флаг boot. Размер этого раздела может быть совсем маленьким, ведь MBR — это всего 512 байт, а размер неиспользуемого пространства за MBR, составляет всего 31Кb или 1023,5Кb 10) . Однако, некоторые современные загрузчики требуют раздел BIOS-Boot размером в 10-30Мb.
В процессе загрузки CSM модуль (эмулирующий работу BIOS) отвечает за то, что находит в GPT раздел BIOS-Boot, загружает первые 512 байт с этого раздела, и передает управление загруженному коду. За дальнейший процесс загрузки отвечает этот код, а CSM берет на себя задачу эмулировать обращение к секторам диска за MBR (вместо этих секторов производится подстановка секторов из раздела BIOS-Boot).

Пожалуй вот на этом и закончим обсуждать CSM и BIOS, все дальнейшее будет относится только к UEFI.

Что нужно для установки ОС, что бы она грузилась через UEFI?

На самом деле все не так сложно как кажется. Как уже было сказано UEFI требует специального раздела ESP (с файловой системой FAT32 и флагами boot и esp). И, несмотря на то, что для этого раздела был предусмотрен специальный длинный идентификатор (UUID = C12A7328-F81F-11D2-BA4B-00A0C93EC93B) для GPT, который в таблицу разделов MBR ну никак не запихнешь, этому разделу дали еще и короткий идентификатор (EF), который можно «впихнуть» в таблицу разделов в MBR. Т.е. ESP раздел можно создать и на диске с GPT и на диске с таблицей разделов в MBR (однако такой вариант поддерживает не любая ОС).

Т.о. при установке системы, помимо создания нужных для работы ОС разделов, нужно создать специальный раздел ESP:

— для варианта «UEFI + MBR» : c типом EF

— для варианта «UEFI + GPT» : c типом EF00 и UUID = C12A7328-F81F-11D2-BA4B-00A0C93EC93B

Этот раздел должен быть отформатирован в FAT32 и иметь установленные флаги boot и esp. Размер раздела можно выбрать небольшим 200-300Мб (занято там будет, скорее всего, гораздо меньше, но делать его совсем маленьким, при современных объемах дисков — просто бессмысленно).

Если ESP раздел создается из установщика Ubuntu, то нужный формат, точку монтирования и необходимые флаги установщик сделает сам: нужно только выбрать тип раздела «EFI Boot» и задать его размер.

Если на компьютере уже стоит ОС загружающаяся через UEFI, то ESP раздел уже должен быть на диске и новый ESP создавать не нужно. В установщике Ubuntu надо только убедиться, что этот раздел используется как «EFI Boot». Более того, если создать несколько разделов ESP (на одном диске), то некоторые прошивки UEFI могут «окриветь» из-за такого неожиданного разнообразия. Общее правило — на диске должен быть только один раздел ESP. На разных устройствах ESP разделов может быть несколько — это вполне штатная ситуация для UEFI.

Ядро Linux загруженное не через UEFI не обеспечивает доступа к переменным UEFI, а это не позволяет изменять настройки загрузки UEFI. Поэтому, поставить новый Linux (что бы он загружался через UEFI) можно только предварительно загрузившись с установочного носителя через UEFI.

Некоторые дистрибутивы не умеют загружаться через UEFI, если у вас таблица разделов в MBR.

Для загрузки через UEFI модуль CSM не нужен, и, если все установленные на компьютере ОС грузятся через UEFI, то CSM лучше отключить. А вот если вы организуете загрузку в режиме SecureBoot, то CSM модуль отключить просто необходимо: без этого, обычно, просто не включить режим SecureBoot или включение SecureBoot автоматически запрещает работу CSM.

Менеджер загрузки UEFI

Кроме кода отвечающего за первичную инициализацию системы UEFI имеет свой менеджер загрузки. Работу менеджера загрузки задают переменные UEFI, хранящиеся в энергонезависимой памяти NVRAM 11) .

Переменные, которые задают работу менеджера загрузки это:

Driver####
DriverOrder
SysPrep####
SysPrepOrder
Boot####
BootOrder
OsRecovery####
PlatformRecovery####
BootNext

, где #### — шестнадцатеричный номер записи.

Переменные Driver#### инициализируют загрузку UEFI драйверов. Переменная DriverOrder определяет последовательность загрузки драйверов.

Драйвера остаются в памяти после своей инициализации. Однако загруженные драйвера сразу не связываются с устройствами, которые они обслуживают. Процесс такого связывания необходимо инициализировать отдельно. Но нужно отметить, что происходит не просто связывание загруженных драйверов, а повторное связывание, т.к. некоторые драйвера уже были связаны со своими устройствами в процессе первичной инициализации системы. За запуск процесса инициализации отвечает флаг LOAD_OPTION_FORCE_RECONNECT, который можно установить в поле атрибутов загрузочной записи Driver####. Если хоть у одного из загруженных драйверов этот флаг установлен, то после окончания загрузки всех драйверов менеджер загрузки UEFI инициализирует процедуру пере-связывания всех драйверов и устройств.

Переменные SysPrep#### инициализируют загрузку системных утилит. Переменная SysPrepOrder определяет последовательность утилит. Системных утилита должна выполнить свои действия и вернуть управление менеджеру загрузки UEFI. Утилиты не остаются в памяти, если нужен резидентный код, то его нужно загружать как Driver####.

Переменные Boot#### отвечают за загрузку загрузчиков ОС. Переменная BootOrder определяет приоритет загрузки загрузчиков ОС. Загрузчик обязан определить возможность загрузки ОС и принять решение — будет он загружать ОС или нет. Если ОС не будет загружаться, то загрузчик должен просто вернуть управление менеджеру загрузки UEFI. Если же ОС будет загружаться, то загрузчик должен уведомить об этом менеджера загрузки UEFI специальным вызовом. Этот вызов имеет принципиальное значение, т.к. те услуги которые UEFI обеспечивает для ОС гораздо уже и более ограничены чем те, которые доступны в процессе инициализации системы. И Именно для переключения режима услуг необходимо такое уведомление от загрузчика.

На работу менеджера загрузки влияют как переменные DriverOrder, SysPrepOrder и BootOrder, так и значение флага LOAD_OPTION_ACTIVE устанавливаемого в поле атрибутов загрузочной записи (Driver####, SysPrep#### или Boot####). Загрузочные записи с неактивным флагом LOAD_OPTION_ACTIVE игнорируются менеджером загрузки UEFI даже если эти записи указаны в переменной задающей порядок/приоритет (DriverOrder, SysPrepOrder или BootOrder). Также игнорируются записи с активным флагом LOAD_OPTION_ACTIVE, но не включенные в переменную задающую порядок/приоритет.

Менеджер загрузки UEFI в нормальном режиме работы сначала загружает все активные Driver#### упомянутые в DriverOrder и в том порядке, в котором они записаны в DriverOrder, затем загружает все активные SysPrep####, указанные в SysPrepOrder, в указанном там порядке, а после этого пытается загрузить активный загрузчик ОС (Boot####) в порядке указанном в BootOrder. А вот если ни одна из активных записей упомянутых BootOrder не смогла загрузить ОС (все вернули управление менеджеру загрузки UEFI), то запускается процесс восстановления.

Процесс восстановления настраивается переменными OsRecovery#### и PlatformRecovery####. Если эти переменные не заданы, то менеджер загрузки UEFI пытается произвести загрузку по умолчанию: загружается загрузчик хранящийся по пути \EFI\BOOT\BOOT.EFI, где — одно из:

IA32 — для 32-х битной платформы c INTEL-подобным процессором
x64 — для 64-х битной платформы c INTEL-подобным процессором
IA64 — для 64-х битной платформы с INTEL Itanium процессором
ARM — для 32-х битной платформы c ARM процессором
AA64 — для 64-х битной платформы c ARM процессором

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

Если заданы OsRecovery#### и/или PlatformRecovery####, то сначала выполняются OsRecovery#### и после этого менеджер загрузки UEFI пробует снова загрузить одну из Boot#### указанных в BootOrder и пробует загрузку по умолчанию.

Если и после этого ни один загрузчик не начал загрузку ОС, то выполняются PlatformRecovery####, но после выполнения записей PlatformRecovery#### загрузка начинается сначала: с Driver####, затем SysPrep####, а только после этого пробует снова загрузить одну из Boot#### указанных в BootOrder и загрузку по умолчанию. И вот если уже и после этого не удалось запустить загрузку ОС, то менеджер загрузки UEFI сдается и выводит сообщение о невозможности дальнейшей загрузки системы.

Отдельно нужно упомянуть возможность манипуляции приоритетом загрузки ОС заданным в BootOrder. Если задана переменная BootNext (в ней указывается номер одной из записей Boot####, которая должна быть активной), то менеджер загрузки пробует сначала загрузить запись Boot#### указанную в BootNext, и только если загрузить ОС по этой записи не удалось, то менеджер загрузки переходит к загрузке в соответствии с BootOrder. При этом BootNext удаляется в любом случае.

Еще один способ изменения приоритета загрузки ОС — выбор записи Boot#### по нажатию кнопки на клавиатуре в процессе загрузки. Для реализации такого механизма нужно привязать кнопку к записи Boot####. И если кнопка будет нажата, то менеджер загрузки пробует сначала загрузить запись Boot#### привязанную к кнопке, и только если загрузить ОС по этой записи не удалось, то менеджер загрузки переходит к загрузке в соответствии с BootOrder.

Практически все функции и настройки менеджера загрузки UEFI позволяет настроить утилита efibootmgr (смотрите man efibootmgr что бы узнать как).

Вот такие серьезные возможности обеспечивает менеджер загрузки UEFI. Фактически в нем реализован весь функционал классических менеджеров загрузки ОС поддерживающих мультизагрузку (загрузку нескольких ос или нескольких версий одной ОС). Причем в вопросах восстановления функционал менеджера загрузки UEFI даже шире за счет того, что он реализуется в процессе инициализации системы.

Таким образом UEFI делает такие загрузчики (например GRUB) фактически ненужными. И ниже мы поговорим о том, как можно организовать загрузку ОС Linux из UEFI без дополнительных загрузчиков.

Secure Boot

Особого упоминания требует такая особенность UEFI как Secure Boot.

Как уже было сказано EFI раздел (ESP) находится на диске, к которому может быть организован доступ во время работы ОС. Это означает не только легкость в изменении загрузки и инициализации оборудования системы, но и то, что туда можно подсунуть заведомо зловредный код, который (О. УЖАС. ) будет загружен еще ДО!! загрузки ОС. На самом деле, перепрограммировать микросхемы BIOS или подменить код в MBR из запущенной ОС тоже можно было, но на это практически никто раньше не обращал внимания .

Закрыть эту «ужасающую дыру» в безопасности и призван Secure Boot. Вот как он работает:

При программировании системной памяти UEFI загрузчика (firmware), производители, вместе с кодом, записывают и сертификаты (содержащие ключи), и при загрузке в режиме Secure Boot UEFI проверяет по этим ключам подписи у любого исполняемого кода, который он загружает из ESP раздела (подписи добавляются к коду). Если верификация не прошла — такому коду отказывают в запуске.

Большая шумиха поднялась когда Microsoft заявили, что производители оборудования, желающие получить сертификат совместимости с Windows 8, обязаны исключить возможность загрузки с отключенным режимом Secure Boot. Дело в том, что это бы не позволило загрузить ни одну ОС, которая была бы не подписана колючем Microsoft.

Однако, довольно быстро шумиха улеглась. Во-первых Secure Boot практически все производители компьютеров разрешают отключать (Microsoft позже насколько переформулировал свои требования: от оборудования сертифицированного под Windows 8 не требуется запрещать загрузку без Secure Boot, зато требуется сообщить загрузчику Windows 8, что загрузка была не в SecureBoot режиме, и уже самой Windows решать — грузится ей дальше или нет). А во-вторых, в рамках консорциума UEFI были предусмотрены интерфейсы для управления ключами. «Подсуетились» и Canonical, и RedHat вместе с фондом FSF (Free Software Foundation). Как результат всех этих мероприятий и событий — и GRUB, и другие загрузчики обзавелись методами загрузки в режиме Secure Boot, а кроме того, стали доступны утилиты по управлению ключами UEFI. Вы даже можете свой собственный код подписать своим собственным ключом, загрузить ключ в UEFI (утилитами из пакета efitools) и это позволит загружать ваш собственный код в Secure Boot режиме.

Чуть хуже дело обстоит с планшетами и телефонами с предустановленной Windows — в прошивках этих устройств SecureBoot может быть не отключаем, а иногда нет и управления ключами.

Все дистрибутивы Ubuntu поддерживающие загрузку через UEFI уже имеют в своем составе все необходимое для загрузки в Secure Boot режиме практически на любом компьютере. Но, если загрузка с установочной флешки или диска не идет, то Secure Boot следует отключить (конечно же Secure Boot — не единственная причина по которой может не происходить загрузка с установочной флешки или диска).

В Ubuntu раздел ESP монитруется (при стандартной установке) в каталог /boot/efi/. Но правами доступа туда обладает только root (остальные пользователи даже прочитать из этого каталога ничего не могут). Т.е. даже без Secure Boot защита от атак через доступ в ESP раздел предусмотрена на том же уровне, на котором защищена и вся система: если рута взломали — то уже в принципе ничего не помешает злоумышленнику сделать с системой все, что он пожелает.

Обратите внимание: режим SecureBoot включается для всего компьютера, а это означает, что правильно подписанными должны быть все загрузчики (всех установленных ОС), утилиты и драйвера, которые загружаются с ESP раздела.

Ключи системы Secure Boot

На самом деле в энергонезависимой памяти компьютера (NVRAM) рассчитанного на работу с UEFI предусмотрено место не на один сертификат, более того, сертификаты хранятся в специально организованной, иерархической системе. Давайте рассмотри этот вопрос более детально, но начнем с того, что определим — что такое сами ключи, о которых мы тут говорим.

Ключи

Что же представляют собой эти ключи? На самом деле хранятся все ключи UEFI в сертификате — бинарном файле контейнере специального формата (специальное расширение стандарта x.509). Внутри сертификата могут содержаться открытый ключ, информация о владельце ключа, удостоверяющий ключ подписи и иная информация. Сами используемые ключи — это пары ключей (открытый/публичный и закрытый/секретный) сформированные алгоритмом RSA. UEFI стандарт рекомендует использовать ключи длинной 2048 bit.

Набор ключей системы SecureBoot

UEFI стандарт предусматривает следующие ключи (или списки ключей):

PK (Platform Key) — Это основной (единственный) ключ системы. Часто это ключ производителя оборудования.

KEK (Key Exchange Keys) — Ключ используемый для обмены ключами. Этих ключей может быть несколько.

db (база разрешенных ключей) — А вот в этом списке и хранятся те самые ключи, которые используются для проверки подписи загружаемых UEFI программ.

dbx (база отозванных ключей) — Здесь хранятся скомпрометированные ключи. Программный код подписанный такими ключами не будет загружаться и исполняться.

dbt (база временных меток) — тут хранятся ключи с отметкой времени 12) ) (оставим пока детальное рассмотрение вопроса использования этих ключей за рамками статьи).

dbr (база ключей для восстановления) — тут хранятся ключи восстановления системы (оставим пока детальное рассмотрение вопроса использования этих ключей за рамками статьи).

В зависимости от реализации часть ключей может отсутствовать (или даже все, если система вовсе не поддерживает SecureBoot). В самых старых реализациях (поддерживающих SecureBoot) набор ключей мог быть: PK и db. В более свежих могут отсутствовать dbr и/или dbt.

Кроме того в NVRAM UEFI могут быть созданы кастомные списки ключей. Примером такого списка служит список ключей MOK (Mashine Owner Keys). MOK ключи используются не самим UEFI, а загрузчиком Shim. Shim (подписанный ключем из db) загружается как обычное UEFI приложение и сам проверяет подпись загружаемого им кода по ключам из MOK.

Если вам неохота/лень разбираться в режимах работы UEFI и ключей описанных далее, то можете условно считать, что PK ключ должен быть само-подписанным, KEK ключ — должен быть подписан ключем PK, а db (dbx|dbt|dbr) ключ должен быть подписан ключем KEK или PK. Если вас устраивает такая упрощенная модель (на самом деле там все несколько сложнее, что и описано далее), то вы можете смело пропустить остаток этого раздела и перейти сразу к разделу Собственные ключи

Состояния системы SecureBoot

Работа с ключем PK сильно зависит от состояния в котором находится UEFI. В спецификации UEFI v2.5 предусмотрено 4 состояния, на два из них наиболее важны, а еще два — служебные (они могут быть вовсе не реализованы в некоторых прошивках UEFI). Состояния определяются значениями глобальных переменных UEFI (хранящимися в NVRAM). При этом, в разных состояниях меняется не только значение переменных, но и возможность записать в эти переменные новое значение. Далее будет использоваться следующая нотация: =/[RO|RW], где признаки RO и RW говорят о доступности переменной для изменения (RO, от ReadOnly — только чтение; RW, от ReadWrite — чтение и запись).

Setup — Режим настройки системы (SetupMode = 1/RO): PK — не определен, SecureBoot — не разрешен (SecureBoot = 0/RO), переход в состояние Audit разрешен (AuditMode == 0/RW), а переход в состояние Deployed запрещено (DeployedMode = 0/RO).
В этом режиме можно задать PK: он должен иметь удостоверяющую подпись своим собственным секретным ключем (т.е. он должен быть само-подписанным). При задании PK система сразу переходит состояние User.
Можно также перейти в состояние Audit, присвоив переменной AuditMode значение 1.

User — Рабочий режим (SetupMode = 0/RO): в этом режиме можно включить или выключить режим SecureBoot (SecureBoot=0/RW) или 13) он включается автоматом, при переходе из состояния Setup (SecureBoot=1/RW), а может включаться и фиксироваться (SecureBoot=1/RO).
В этом режиме тоже можно поменять PK, но новый PK должен иметь удостоверяющую подпись секретным ключем текущего PK.
Из этого режима можно перейти в Audit (AuditMode = 0/RW) или в Deployed (DeployedMode == 0/RW). Так же можно удалить или очистить PK (реализация зависит от платформы) с автоматическим переходом в состояние Setup.

Audit — служебное состояние для проведения аудита системы — в этом режиме возможна загрузка любых модулей без проверки подписи, но о каждой загрузке создается запись в специальной таблице. При присвоении переменной AuditMode значения 1 (возможно в User и Setup) сразу происходят несколько действий: система переходит в состояние аналогичное состоянию Setup (SetupMode = 1/RO), отключается SecureBoot (SecureBoot = 0), текущий PK сбрасывается (очищается), DeployedMode = 0/RO.
Фактически это сброс системы SecureBoot в состояние Setup (что разрешает записать само-подписанный PK). Однако выход из этого режима иной чем из состояния Setup: При установке нового PK — состояние меняется на Deployed (AuditMode = 0/RO, DeployedMode = 1/RO, SetupMode = 0/RO). При этом в состоянии Deployed будет отключен SecureBoot.

Deployed — служебное состояние в котором запрещена любая работа с ключами, состояние SecureBoot тоже нельзя изменить (если включено — не отключить и наоборот). Как раз в этот режим переведены производителями UEFI на виндо-планшетах и виндо-смартфонах. Перевести в этот режим можно: из состояния User, присвоив глобальной переменной UEFI «DeployedMode» значение 1 или из состояния Audit, задав PK. Как вы правильно понимаете после этого и саму переменную «DeployedMode» уже будет не изменить.
Выход из этого режима возможен в User или Setup, а вот механизм выхода — зависит от реализации UEFI (Platform specific DeployedMode clear — как написано в спецификации). Т.е. либо какие-то шаманские действия (возможно и недокументированные) либо вовсе — никак (по крайней мере без аппаратного обнуления NVRAM).

KEK ключ может быть добавлен в состояниях Setup (без подписи или само-подписанный) и User (обязательно подписанный секретным ключем от PK).

С ключами в db* (db, dbx, dbt, dbr) — все значительно проще и одновременно сложнее: Т.к. существует огромное количество операционных систем и их различных версий, а также загрузчиков этих ОС, драйверов и утилит от разных поставщиков, то поставить (от производителя) систему сразу со всеми нужными ключами — просто нереально. То же касается и ключей, которые были скомпрометированы и ключей восстановления. Поэтому предусмотрен режим добавления этих ключей. При этом если система находится в состоянии Setup, то ключи в db* можно добавлять без подписей или само-подписанные, а если в User, то добавляемые ключи должны быть подписаны приватной ключем от одного из KEK ключей или от PK.

Причем в ключи в db (dbt) могут добавляться и автоматически (если это предусмотрено конкретной реализацией UEFI): когда подпись загружаемого модуля не может быть проверена, то могут быть предусмотрены механизмы (поиск в массиве на диске или интерактивное подтверждение от авторизованного пользователя), которые разрешат добавить публичный ключ от подписи (подпись содержит публичный ключ для своей проверки) в db (или dbt).

Собственные ключи

Так как все ключи/сертификаты UEFI (PK, KEK, db) построены на основе открытых стандартов, то и весь набор этих ключей можно сформировать самостоятельно. Далее рассмотрим как это можно сделать, а вот тут описано все тоже другим толковым автором.

Прежде чем вы приступите к манипуляциям с ключами, настоятельно рекомендуется убедится в том, что ваша прошивка UEFI позволяет отключить SecureBoot из утилиты настройки или удалить/обнулить PK. Если этой возможности прошивка не предоставляет, то подумайте десять раз прежде чем что-либо делать с ключами — ваши шансы трансформировать ваш компьютер/ноутбук в кирпич крайне высоки!

Для работы нам потребуются утилита openssh (практически во всех дистрибутивах Linux эта утилита уже установлена) и утилиты из пакета efitools (доступна в репозиориях ubuntu 14) ).

Создание ключей

Для начала создадим наш тестовый ключ и само-подписанный сертификат:

$ openssl genrsa -out test-key.rsa 2048 $ openssl req -new -x509 -sha256 -subj '/CN=test-key' -key test-key.rsa -out test-cert.pem $ openssl x509 -in test-cert.pem -inform PEM -out test-cert.der -outform DER

Как показали мои эксперименты с UEFI прошивкой от AMI — срок действия сертификата в db не имеет значения для загрузки в режиме SecureBoot (подписанный моим собственным ключем UEFI-Shell продолжал загружаться в режиме SecureBoot и после окончания срока действия сертификата). Однако я не берусь гарантировать, что это не может быть важно для какой-либо другой реализации UEFI. Если это окажется важно, то нужно задать разумное время действия сертификата во второй команде через опцию -days : где — число дней в течении которых сертификат действует (по умолчанию задается — один месяц, чего самом собой — маловато…).

Для дальнейших действий нам потребуется GUID для идентификации нашего ключа. Его очень просто сформировать через утилиту uuidgen, а для удобства новый GUID мы запишем в переменную.

$ guid=$(uuidgen) $ echo $guid c752155d-093f-4441-87c3-20e2352205ac

Создание UEFI ключей

Для того что бы установить наш ключ в базу ключей UEFI, нам потребуется специальны контейнер EFI_SIGNATURE_LIST, в котором будет задана переменная EFI_VARIABLE_AUTHENTICATION_2. Для упрощения, ключи в контейнере будут само-подписанными.

Сначала мы создаем контейнер EFI_SIGNATURE_LIST содержащий сертификат:

$ sbsiglist --owner $guid --type x509 --output test-cert.der.siglist test-cert.der

Далее создадим подписанные ключи для последующей загрузки в энергонезависимую память UEFI. Наши файлы будут содержать сертификат с префиксом в виде EFI_VARIABLE_AUTHENTICATION_2 описателя. Описатель будет подписывать ключ, и содержать название переменной и другие атрибуты. Т.к. в файл будет включено название переменной (PK, KEK and db), нам придется создать отдельный контейнер для каждой переменной.

$ for n in PK KEK db > do > sbvarsign --key test-key.rsa --cert test-cert.pem \ > --output test-cert.der.siglist.$n.signed \ > $n test-cert.der.siglist > done

Здесь мы несколько упрощаем стандарт работы ключей UEFI: у нас не будет выстроена цепочка удостоверяющих подписей различающихся ключей: PK → KEK → db. Все три ключа у нас — само-подписанные и в PK, KEK и в db будет записан одинаковый ключ (чисто формально они удостоверяют подписи друг друга по цепочке). Ключ который мы будем записывать — тот самый rsa ключ, который мы сформировали самой первой командой. Можно, конечно, сформировать различающиеся ключи для PK, KEK и db, но не совсем понятно — зачем нужно такое усложнение в нашем случае.

Кроме того, все известные сертификаты от разработчиков linux (Canonical, Fedora, AltLinux, openSUSE и др.) — тоже само-подписанные, их вы можете найти в на сайте проекта rEFInd или в проекте UEFI-Boot на github

Создание хранилища ключей

Далее нам потребуется создать хранилище ключей в стандартном месте, где утилита sbkeysync будет их искать.

$ sudo mkdir -p /etc/secureboot/keys/ $ sudo cp *.PK.signed /etc/secureboot/keys/PK/ $ sudo cp *.KEK.signed /etc/secureboot/keys/KEK/ $ sudo cp *.db.signed /etc/secureboot/keys/db/

На самом деле вы можете создать хранилище где угодно и указать утилите sbkeysync где оно находится в значении ключа –keystore.

Загрузка ключей

Через утилиту прошивки

Загрузка ключей в UEFI может быть выполнена из утилиты настройки вашей материнской платы. Там нужно будет найти раздел (обычно Security) где задаются параметры SecureBoot. Возможно потребуется явно разрешить работу с ключами — выбрать режим управления ключами custom или как либо еще. Попав в окно утилиты по управлению ключами, первым делом сохраните (на всякий случай) фабричные ключи 15) . После этого удалите все фабричные ключи, и по одному добавляйте ключи из вашего хранилища ключей (скорее всего, его придется перенести на ESP раздел, т.к. только этот раздел доступен для UEFI).

PK ключ желательно записывать последним (почему? — детально описано в финальной части раздела «Ключи системы SecureBoot»).

Следует также отметить, что формат, в котором прошивка умеет загружать ключи может разниться в разных прошивках UEFI. Например прошивка AMI из недавно купленного мини-PC может взять сертификат и из подготовленного контейнера, и непосредственно из файла .pem. Т.о. вся эта возня со специальными контейнерами, в этом случае, вовсе не нужна: один и тот же само-подписанный сертификат можно загрузить и в PK, и в KEK, и в db.

Используя sbkeysync

Если UEFI находится в Setup режиме, то ключи можно загрузить и из ОС, используя утилиту sbkeysync. Но для начала воспользуйтесь опцией –dry-run, что бы убедится, что у вас все верно настроено и готово к этому важному процессу:

$ sbkeysync --verbose --pk --dry-run Filesystem keystore: /etc/secureboot/keys/db/test-cert.der.siglist.db.signed [2116 bytes] /etc/secureboot/keys/KEK/test-cert.der.siglist.KEK.signed [2116 bytes] /etc/secureboot/keys/PK/test-cert.der.siglist.PK.signed [2116 bytes] firmware keys: PK: KEK: db: dbx: filesystem keys: PK: /CN=test-key from /etc/secureboot/keys/PK/test-cert.der.siglist.PK.signed KEK: /CN=test-key from /etc/secureboot/keys/KEK/test-cert.der.siglist.KEK.signed db: /CN=test-key from /etc/secureboot/keys/db/test-cert.der.siglist.db.signed dbx: New keys in filesystem: /etc/secureboot/keys/db/test-cert.der.siglist.db.signed /etc/secureboot/keys/KEK/test-cert.der.siglist.KEK.signed /etc/secureboot/keys/PK/test-cert.der.siglist.PK.signed

Вывод покажет списки ключей найденных в базе данных UEFI, ключей найденных в хранилище ключей и список синхронизации (какой ключ куда будет загружен).

Если все выглядит правильно, удалите –dry-run параметр из команды для фактического обновления ключей в UEFI базе данных.

Будьте предельно осторожны выполняя загрузку ключей, т.к. как только PK будет записан прошивка UEFI перейдет в режим User, а в некоторых прошивках это еще автоматом включит SecureBoot режим. Вы должны быть уверены, что прошивка UEFI позволит вам вернутся в Setup режим и/или удалить PK.

Некоторые прошивки требуют перезагрузки для применения этих изменений в переменных UEFI. Прежде чем вы выполните перезагрузку, обязательно подпишите ваш загрузчик, иначе просто ничего не загрузится, ведь SecureBoot активирован и в db прописан ключ, которым будет проверяться подпись любого кода, который будет загружаться UEFI.

Подписывание загрузчика

Т.к. мы активировали SecureBoot, то теперь нам нужно подписать наш загрузчик что бы он мог быть загружен UEFI в этом режиме. В нашем примере мы подпишем код загрузчика GRUB2.

Это не рекомендуется в работающих системах, т.к. код этого загрузчика довольно регулярно обновляется, подписывать его придется каждый раз после обновления!

$ sbsign --key test-key.rsa --cert test-cert.pem \ --output grubx64.efi /boot/efi/EFI/ubuntu/grubx64.efi $ sudo cp /boot/efi/EFI/ubuntu/grubx64.efi $ sudo cp grubx64.efi /boot/efi/EFI/ubuntu/

Теперь, можно скрестить пальцы, плюнуть три раза через левое плечо и попробовать перегрузиться

Возврат в режим Setup

Переключаться обратно в режим Setup лучше всего из прошивки UEFI, однако теоретически это возможно и внутри OS . Т.к. мы имеем секретный ключ от нашего PK, мы можем попробовать вернуть UEFI из режима User в режим Setup. Для этого потребуется подготовить пустой ключ и записать его в переменную PK:

$ : > empty $ sbvarsign --key test-key.rsa --cert test-cert.pem \ --attrs NON_VOLATILE,BOOTSERVICE_ACCESS,RUNTIME_ACCESS \ --include-attrs --output empty.PK.signed PK empty $ sudo dd bs=4k if=empty.PK.signed \ of=/sys/firmware/efi/vars/PK-8be4df61-93ca-11d2-aa0d-00e098032b8c

Хотя лучше убедиться, что вернуть UEFI в режим Setup можно из самой прошивки (утилиты настройки) перед тем как прописывать PK.

Как Ubuntu загружается в режиме Secure Boot

Как уже было сказано выше, сертификаты с ключами для загрузки в режиме Secure Boot записываются производителем оборудования (довольно подробно о ключах UEFI (англ.)). И, как правило, набор сертификатов состоит из: сертификата производителя, KEK и db ключей от Microsoft (конечно же). Крайне редко, но все же попадаются такие машины, у которых в db есть и ключ от Canonical и/или RedHad. Как же на машине c ключами только от Microsoft загрузить Ubuntu в режиме SecureBoot?
Решение было найдено: Microsoft согласился (не без активности со стороны Canonical) подписать своим ключом простенький загрузчик от Red Hat — shim (есть еще мини-загрузчик — PRELoader, о его подписании ключом Microsoft похлопотал фонд FSF). Shim, в свою очередь, содержит (в MOK) UEFI сертификат от Canonical и проверяет подпись GRUB2 (версия которого, распространяемая через репозитории Ubuntu, подписана ключем Canonical). А GRUB2 проверяет подпись ядра (из пакета linux-signed-generic, которое подписано Canonical).

Введение дополнительного звена в виде shim продиктовано тем, что GRUB довольно часто обновляется и каждый раз после обновления его надо подписывать. Само собой, его гораздо проще подписать собственным ключом Canonical нежели каждый раз снова договариваться с Microsoft.

Если вы не хотите оставлять сертификаты Microsoft и производителя на своей машине 16) , то из утилиты настройки вашей материнской платы или с помощью утилит efitools можно стереть сертификаты прописанные производителем, и записать в UEFI (db) ключ от Canonical, тогда уже Grub (так же как и само ядро Linux) сможет загружаться в режиме Secure Boot, и shim (со своим MOK) — не нужен.

Если вам не хочется даже сертификат от Canonical оставлять в своем компьютере 17) , то вы можете создать свои собственные ключи и сертификаты (как описано выше), подписать grub или само ядро Linux (утилитой sbsign из пакета sbsigntool) и записать ключи в базу данных ключей EFI (утилитами efitools). Подробно этот процесс описан выше и тут (англ.).

ВНИМАНИЕ, если ваш компьютер не позволяет отключить Secure Boot режим, то все манипуляции с ключами и подписями нужно проделывать с предельной осторожностью, т.к. любая ошибка может привести к тому, что ваш компьютер превратится в «кирпич».

Проверяйте все ваши настройки, проверяйте, что в UEFI записаны именно те ключи, что вы хотели и не забудьте проверить правильность подписей.

Хорошая идея: проделать все сначала на виртуальной машине.

ВНИМАНИЕ, если вы организовали загрузку GRUB (или другого загрузчика что вы используете) на основе только своего собственного ключа, то внимательно следите за обновлениями: при обновлении GRUB вам необходимо подписать новую версию GRUB своим ключом, иначе он не загрузится в Secure Boot режиме.

isolinux (вариант загрузчика syslinux) он используется для загрузки в BIOS режиме и размещается в MBR и специальной загрузочной записи ISO9660 стандарта, подробнее — тут).

grub (вариант grub-efi) он используется для загрузки в UEFI режиме.

EFS раздел (необходимый для загрузки в UEFI режиме) прописан и в таблицу разделов в MBR, и в каталог разделов iso9660 формата. По UEFI стандарту загрузчик по умолчанию должен находится в EFS разделе по пути: EFI\BOOT\BOOTx64.EFI

Такой «винегрет» позволяет грузиться с такого образа в следующих режимах:

в режиме BIOS/SCM
как с CD/DVD (код isolinux берется из загрузочной записи ISO9660 стандарта)
как с HDD/USB-Flash (код isolinux берется из MBR)
в режиме UEFI

как с CD/DVD (EFS раздел находится в каталоге записей ISO9660, и оттуда запускается EFI\BOOT\BOOTx64.EFI)

как с HDD/USB-Flash (EFS раздел находится в таблице разделов MBR, и оттуда запускается EFI\BOOT\BOOTx64.EFI)

Кстати в EFI\BOOT\BOOTx64.EFI (EFI\BOOT\BOOTia32.EFI для 32-х битных платформ) лежит не сам GRUB, а SHIM. Сам grubx64.efi/grubia32.efi (начальная стадия grub-efi) лежит рядом (в EFI\BOOT\) и его запускает SHIM. SHIM имеет валидную подпись ключом от Microsoft для загрузки в режиме SecureBoot, что позволяет загрузиться из образа на большинстве компьютеров.

Такой образ легко записать на флешку простой командой:

ВНИМАНИЕ! запись таким способом приводит к потере данных ранее хранившихся на флешке
sudo cp .iso /dev/sd

Второй параметр — именно девайс, а не раздел. Посмотреть диски и разделы можно в выводе команды

sudo fdisk -l

Образ Ubuntu копируется начиная с первого сектора устройства, MBR и таблица разделов ISO9660 стандарта попадают в необходимые для их правильной работы места, что позволяет с загрузиться с такой флешки как c USB-СD/DVD и как с USB-HDD/USB-Flash. Причем в обоих вариантах доступна загрузка как в UEFI, так и в BIOS/CSM режимах.

Другие интересные возможности UEFI

UEFI Shell

UEFI shell часто уже установлен в разделе ESP или прямо в прошивке UEFI. Некоторые UEFI прошивки умеют загружать командный интерпретатор UEFI прямо из консоли настройки UEFI (BIOS).

Если вы ставили Ubuntu на чистый диск, а в прошивке нет встроенного UEFI shell, то его можно доставить руками. Сам бинарный файл легко находится через любой поисковик. Вам нужно будет только скопировать его в корень ESP раздела с именем shellx64.efi (для 32-х битных платформ: shellx32.efi). Само собой копировать надо через sudo (т.е. с правами root).

Либо отключать для его загрузки режим SecureBoot

Либо подписать бинарный код UEFI Shell парным секретным ключем от одного из ключей записанных в переменной db базы данных ключей UEFI.

Если из настроек UEFI нет возможности запустить UEFI shell, то можно его прописать как вариант загрузки (как вы помните UEFI поддерживает мульти-загрузку). Для этого воспользуемся утилитой efibootmg:

# efibootmgr -c -l \\shellx64.efi -L UEFIshell

После этой команды у вас появится новый пункт меню загрузки UEFI, и это новый пункт станет первым по приоритету. Если такой приоритет загрузки вас не устраивает, то поменяйте его с помощью опции «-o» утилиты efibootmgr.

Справочник по командам UEFI shell встроенный — команда help. Если вы хотите останавливать вывод постранично (некий аналог more) то используйте в командах ключ -b. Кроме того поддерживается история вывода на 3 страницы которые можно просмотреть используя кнопки PageUp и PageDown.

Команда map покажет известные UEFI диски и разделы. Обычно диск fs0: — это и есть раздел ESP. Для того, что бы просмотреть содержимое каталогов ESP раздела (ls) выполните переход на ESP раздел — введите в строке приглашения fs0: — это очень похоже на dos команды типа а: с: (если кто еще помнит такое).

Разделитель в путях тоже в стиле DOS — обратный слеш (\).

EFI shell имеет довольно обширный набор команд, все их тут описывать смысла нет — если не достаточно встроенной подсказки, то есть краткие руководства в Internet. Наиболее полное писание UEFI Shell и его команд я нашел только в спецификации UEFI Shell 2.0 на сайте UEFI.org.

Загрузка ядра Linux непосредственно из UEFI

Если вы взгляните в файловом менеджере на ядро (/boot/vmlinuz*) то вы можете немало удивиться, заметив что тип будет указан как «DOS/Windows executable» — не удивляйтесь. Все последние ядра в Ubuntu собираются с опцией UEFISTUB (поддержка загрузки в режиме UEFI). А это добавляет заголовок аналогичный ДОСовскому .exe (именно так должны собираться все UEFI приложения). Т.е. само ядро можно загрузить как UEFI приложение. Для этого нужно разобраться с двумя основными вопросами:

1. Как правильно передать ядру параметры? Т.е. указать на корневую файловую систему, образ initrd, и указать опции загрузки ядра.
2. Как обеспечить UEFI доступ к самому ядру (и initrd)?

По первому пункту все достаточно просто: параметры, которые нужно передать ядру для загрузки можно подсмотреть в /boot/grub/grub.cfg, в команде загрузки linux (там стандартно передаются указание на корневой раздел и опции типа «ro», «quiet» и «splash»). Дополнительно ядру надо будет сообщить, где найти initrd (в ядрах версии 3.3 и выше это можно сделать через параметр intrd). В итоге, та команда, которую должен выполнить UEFI будет выглядеть примерно так:

vmlinuz.efi root=UUID=0160863a-1468-422b-8bbb-f80e98e3600d ro quiet splash initrd=initrd

В этом примере ядро и initrd лежат непосредственно в корне ESP раздела. Ядро переименовано в «vmlinuz.efi», а соответствующий ему образ рамдиска начальной инициализации ядра в «initrd». В команде указан UUID (моего корня, вам нужно прописать свой UUID) как путь к корневому разделу, но можно написать и что-то типа root=/dev/sda2 (UUID все же — лучше).

Использовать подписанное Canonical ядро (пакет linux-signed-generic из репозитоиев Ubuntu). В этом случае сертификат от Canonical должен быть помещен в переменную db базы данных ключей UEFI.

Подписывать ядро своим собственным ключем, сертификат (с публичной частью ключа) которого размещен переменной db базы данных ключей UEFI.

В первом варианте — для загрузки из UEFI нужно использовать подписанный вариант ядра (vmlinuz*.efi.signed).
Во втором варианте нужно организовать (это можно даже автоматизировать) подписывание каждого нового ядра, которое приходит с обновлениями системы.

Некоторые сложности может вызвать указание пути к initrd. Ядра выше 3.3 вообще не различают прямые и обратные слеши в параметре initrd, но нужно указать такой путь, что бы ядро смогло найти initrd при загрузки в окружение UEFI.

В целом, нам необходимо организовать доступ из UEFI и к ядру, и к initrd (напомню: UEFI имеет доступ только к ESP разделу и умеет работать только с файловой системой FAT32). Это может быть решено одним из трех вариантов:

Вариант 1: Загрузить ядро и intrd непосредственно из корневого раздела или раздела boot

Для этого нужно загрузить в UEFI драйвер для поддержки той файловой системы, в которую отформатирован ваш корень или /boot. (UEFI «из коробки» знает только FAT32, драйвера для чтения других FS можно найти например тут).

Вот какие команды надо выполнить в UEFI Shell для загрузки ядра прямо из корня, находящегося на разделе с EXT4 (boot не вынесен в отдельный раздел).
— загрузить драйвер поддержки ext2-3-4 (в нашем примере он был предварительно размещен на ESP разделе в каталоге EFI/drivers)

load fs0:\EFI\drivers\ext2_x64.efi

ВНИМАНИЕ: Если UEFI функционирует в режиме SecureBoot, то драйвер также необходимо подписать одним из ключей находящихся в списке ключей db, иначе ему будет отказано в загрузке!

— смонтировать корневую FS (эта команда пытается все доступные устройства смапить всеми доступными драйверами)

map -r

— перейти (изменить текущий путь) в новую FS

— запустить ядро с параметрами

vmlinuz root=UUID=0160863a-1468-422b-8bbb-f80e98e3600d ro queit initrd=initrd.img

В этом примере я воспользовался тем, что в корне корневой FS автоматически создаются линки на самую свежую версию установленного ядра и его initrd. Перейдя (сменив текущий путь) в корневую ФС мне уже не нужно мудрить с указанием полного пути к ядру и initrd — они находятся в текущем каталоге (из которого и запускается ядро).

Все эти действия можно записать в скрипт (для скриптов UEFI Shell принято расширение .nsh), и запускать ОС вызвав его. К сожалению, непосредственно скрипт файл нельзя указать как исполняемый файл в пункте меню загрузки UEFI. Согласно спецификации UEFI Shell может исполнить скрипт, имя которого передано ему как параметр, но мне это сделать не удалось. UEFI Shell может автоматом исполнить (после паузы) скрипт startup.nsh, находящийся в корне ESP раздела (можно записать эту последовательность команд туда).

Но можно пойти другим путем. Спецификация UEFI поддерживает автоматическую загрузку драйверов при загрузке системы. А это собственно и есть то, что нам нужно для того, что бы получить доступ к файловой системе с ядром без скрипта. Однако и тут есть один подводный камень.

Дело в том, что просто загрузить драйвер — недостаточно, нужно еще вызвать процедуру ремаппинга устройств (т.е. выполнить ту самую команду map -r). При ремапинге каждый драйвер пытается «прицепиться» ко всем доступным устройствам, т.е. наш драйвер EXT2-4 сделает доступными все разделы на всех дисках с файловыми системами EXT2-4.

Добавить автоматическую загрузку драйвера можно командой

sudo efibootmgr -crl "EFI\drivers\ext2_x64.efi" -L "EXT2-4 Driver"

То же самое можно сделать командой bcfg из UEFI-Shell. Следующая команда добавит пункт загрузки Driver0000 (номер задает первый аргумент команды add), который будет загружать драйвер из файла EFI\drivers\ext2_x64.efi (с ESP раздела). Драйвер получит описание «EXT2-4 Driver»:

bcfg driver add 0 EFI\drivers\ext2_x64.efi "EXT2-4 Driver"

Все замечательно и этот драйвер, при каждом запуске системы, будет загружаться во время инициализации UEFI автоматически, но ремапинга не будет. Для того, чтобы после загрузки драйвера инициировать ремапинг нужно в опции загрузки драйвера указать специальный атрибут LOAD_OPTION_FORCE_RECONNECT, однако ни одной командой UEFI-Shell или опцией efibootmgr этот атрибут не установить (по крайней мере мне не удалось найти такой команды). Перелопатив спецификацию UEFI можно понять, что нужно то всего прописать значение 3 вместо 1 в первом 32-битном слове UEFI переменной отвечающей за загрузку драйвера (той самой Driver0000, что мы создали командой bcfg или efibootmgr). Сделать это изменение можно любым HEX редактором (из загруженной системы), запущенным с правами рута, в котором на редактирование открывается файл /sys/firmware/efi/efivars/Driver0000-8be4df61-93ca-11d2-aa0d-00e098032b8c (это маппинг в файловую систему sys переменной UEFI). В редакторе нужно 5-й байт от начала поменять с значения 01 на 03 и сохранить файл.

После серии окирпиченных патчем Бармина машин (см. ниже эту замечательную историю) все UEFI переменные теперь защищены от изменений специальным атрибутом. Снять его перед редактированием можно командой chattr -i от рута.

Хорошим тоном будет вернуть защиту после редактирования командой chattr +i

Я конечно понимаю, что такой хакерский метод — это уже просто за гранью разумного для большинства пользователей UBUNTU, но пока мне не удалось найти другого пути задать атрибут LOAD_OPTION_FORCE_RECONNECT в опции загрузки драйвера. Поэтому я завел ишью на гитхабе с просьбой авторам efibootmgr реализовать эту возможность. Позднее я даже оформил PR (Pull Request) с реализацией этой возможности. Однако этот PR добавили в мастер ветку только 7 месяцев спустя. И, видимо, эта новая возможность efibootmgr появится в версии 17.

После нашей хакерской атаки на UEFI можно перегрузиться в UEFI-Shell и там прямо при запуске увидеть, что все EXT4 разделы уже отмаплены в FS «диски», а значит на них можно сослаться при задании команды загрузки для опции загрузки ОС. В моем примере EXT4 раздел с корневой FS отмапился в FS2. А это позволяет задать в опции загрузки (используя команду bcfg из UEFI-Shell или efibootmgr из загруженной системы) команду такого вида:

FS2:\vmlinuz root=UUID=0160863a-1468-422b-8bbb-f80e98e3600d ro queit initrd=FS2:\initrd.img

Если вы все сделали правильно и не забыли подписать драйвер (если у вас включен SecureBoot), то поле перезагрузки система успешно должна загрузится прямо с вашего корневого раздела.

В принципе, несмотря на некоторую сложность этого метода в реализации, это САМЫЙ ПРАВИЛЬНЫЙ вариант загрузки ядра Linux из UEFI. Дополнительные удобства создают постоянно обновляемые ссылки на последнее и предыдущее ядра и их initrd в корне файловой системы Linux. На них можно однократно создать пункты загрузки UEFI и не нужно никаких обновлений после установки/удаления ядер и обновления initrd. Также однократно надо скопировать в EFS раздел драйвер для ФС корня и однократно настроить его загрузку.

Вариант 2: Скопировать ядро и intrd в ESP раздел

Преимущество в том, что не нужно мудрить с организацией поддержки другой FS. Однако, каждый раз при обновлении ядра или initrd их нужно вновь копировать в ESP раздел. Решить задачу автоматизации этого процесса можно одним из методов описанных в этой статье (англ.) или подобно тому как это реализовано в проекте UEFI Boot.

Вы можете выполнить команду запуска ядра из UEFI Shell, или записать ее в командный файл и запускать его из UEFI Shell, или, воспользовавшись утилитой efibootmgr, записать эту команду как пункт меню загрузки UEFI:

# efibootmgr -c -l vmlinuz.efi -u "root=UUID=0160863a-1468-422b-8bbb-f80e98e3600d ro quiet initrd=initrd" -L LinuxKernel

Эта команда добавит пункт загрузки LinuxKernel и сделает его первым в списке приоритета загрузки.

Вариант 3: Смонтировать ESP раздел как /boot

Преимущества этого решения в том, что новые ядра и initrd будут находится (устанавливаться и обновляться) прямо на ESP раздел (который станет одновременно boot разделом). Правда, неприятность в том, что название файла с ядром и initrd есть версия, и для каждого нового ядра нужно заново прописывать команду в пункт загрузки UEFI. Можно, конечно, переименовать в короткие имена (которые однократно будут записаны в пункты загрузки UEFI), однако переименование приводит нас к ситуации близкой к предыдущему случаю — initrd будет при обновлении снова получать номер версии и его каждый раз придется переименовывать. Воспользоваться автоматически создаваемыми ссылками в корневом разделе — не получится (они останутся в файловой сиcтеме корневого раздела, к которому нет доступа без доп. драйверов), а создать ссылки на FAT разделе — невозможно (этого FAT просто не умеет от рождения).

Команда для записи пункта загрузки UEFI через утилиту efibootmgr не отличается принципиально от той, что указана для способа с копированием ядра в ESP раздел:

# efibootmgr -c -l vmlinuz-3.12.0-22-generic -u "root=UUID=0160863a-1468-422b-8bbb-f80e98e3600d ro quiet initrd=initrd.img-3.12.0-22-generic" -L Ubuntu-3.12.0-22-generic

Более детальная проработка этого варианта описана в отдельной статье UEFI Boot. Там реализовано автоматическое обновление пунктов загрузки UEFI при установке, обновлении и удалении ядер.

Загрузка, организованная одним из вышеописанных способов, не требует наличия загрузчика (GRUB и Shim можно и нужно удалить из системы), ведь мы передаем UEFI все функции загрузчика ОС.

Устранение из процесса загрузки загрузчиков (оригинально это цепочка из двух: shim + GRUB) заметно (но не так что бы очень значительно) сокращает время загрузки ОС. Вот как это выглядит в цифрах на примере одного mini-pc (I5 5257U, 8Gb RAM, SSD): утилита systemd-analyze сообщает, что на стадию работы загрузчиков в случае цепочки UEFI-Shim-GRUB-Kernel требуется чуть меньше секунды — 967ms, а на прямую загрузку UEFI-Kernel — 153ms. При полной (холодной) загрузке системы за ~14 секунд выигрыш составляет порядка 6%.

Полезные утилиты для UEFI

В стандартных репозиториях Ubuntu есть несколько полезных пакетов с утилитами для работы с настройками UEFI.

efibootmgr — утилита, которой можно менять настройки загрузки UEFI, в частности: настраивать приоритет загрузки, создавать/изменять/удалять загрузочные записи UEFI.

efivar — простая утилита для работы с переменными UEFI.

efitool — набор утилит и efi-приложений для работы с ключами/сертификатами, используемыми при загрузке в режиме Secure Boot.

sbsigntool — утилиты для подписывания и проверки подписей UEFI-приложений, для организации загрузки в Secure Boot режиме.

У всех этих утилит есть вполне толковые man-руководства и есть примеры использованию в Интернете, поэтому я не стану останавливаться на деталях использования этих утилит.

🙂 Патч Бармина живе всех живых

Ну и напоследок, последняя «веселая» история связанная с бородатым (по некоторым сведениям 1996 года рождения) патчем Бармина.

В конце января 2016 некий арчевод решил посмотреть — как работает этот известный патч. И он старательно вписал в команду даже специальный ключ, без которого этот патч уже не запускается… Ну… и получил кирпич из своего MCI нетбука — он даже после сброса не включился!

Как нетрудно догадаться корень беды — в кривой прошивке UEFI. Патч вытер вместе с корнем еще и переменные UEFI в NVRAM, которые монтируются в /sys/firmware/efi/efivars/, но принципиально это не могло быть проблемой, потому как стандартом UEFI предусматривается нарушение целостности данных в NVRAM: при обнаружении такой ситуации прошивка ОБЯЗАНА осуществить инициализацию NVRAM до состояния настроек по умолчанию/фабричных (Factory Default). Но вот в MCI решили забить на проверку целостности NVRAM, и незадачливый арчевод потащил свой нетбук кирпич в сервис.

После этой новости состоялся наезд на разработчиков SystemD (ну на них многие любят наезжать и ругаться, а те собственно сами довольно часто дают повод для вполне обоснованной и справедливой ругани в свой адрес): мол какого лешего, SystemD монтирует эти переменные с возможностью записи!? Давайте типа быстро переделайте на монтирование в режиме только-чтение. На что был дан резонный ответ — доступ на запись нужен утилитам, и разрешена запись только руту, который при желании премонтирует эти переменные в режиме записи. Так что, это не защитит от идиотов дураков «умников», которые экспериментируют с патчем Бармина.

Правда позже некоторые контрмеры все-таки были предприняты: теперь все UEFI переменные монтируются со специальным атрибутом, который запрещает запись и удаление этих файлов даже руту. Однако root в состоянии снять эти флаги (сhattr -i ). Так что теперь для повторения судьбы арчевода с ноутбуком MCI нужно не только специальный ключ в команде rm -rf задавать, но еще и предварительно снять защиту с перемнных UEFI.

Самое же примечательное в этой ситуации ИМХО в том, что 20 лет назад отпущенная шутка, до сих пор стреляет, да еще с невиданной доселе мощью.

Т.е. если раньше патч успешно уничтожал ОС на компьютере, то теперь стало возможным еще и вывести из строя компьютер (при кривой реализации UEFI).

Ссылки

Не смущайтесь тем, что во многих местах UEFI упоминается как EFI — по сути это не совсем правильно, но по факту — речь об одном и том же.

на самом деле ESP раздел может быть и во флеш-памяти и даже на сетевом хранилище, но эта экзотика (предусмотренная стандартом) вряд ли будет востребована простыми пользователями

в UEFI используются обратные косые в качестве разделителей
Виндовый загрузчик размещается в EFI\Microsoft\Boot\Bootmgfw.efi

это стандартный размер сектора, который и по сей день фигурирует как логический, хотя практически все современные диски имеют физический размер сектора 2048, 4096 или даже 8192 байта

теоретически неограниченное количество, т.к. каждый логический раздел содержит указатель на начало следующего

который уже не обойти такими выкрутасами как с расширенным разделом и логическими томами
или на первые 2ТБ, если диск имеет объем более чем 2ТБ

Само собой, в таблицу разделов можно добавить еще 3 записи, это хоть и делает возможной загрузку кодом из MBR, но создает ситуацию, при которой на диске одновременно действуют две таблицы разделов разного формата. Такие гибридные системы удается реализовать энтузиастам, но массовому пользователю использовать такие схемы не рекомендуется в виду сложности настройки и поддержания работоспособности такой системы

в зависимости от того с какого сектора начинается первый раздел, обычно это либо 64 сектор либо 2047 секторов

это та самая, для которой на материнской плате стоит батарейка, хотя в последнее время батарейка чаще ставится только для часов реального времени, а энергонезависимую память обеспечивает флеш-память

Зависит от реализации, т.к. в стандарте это не оговорено
для установки выполните: sudo apt-get install efitools

Если ваша прошивка предоставляет опцию установки/восстановления фабричных ключей, то свою резервную копию фабричных ключей вам создавать не обязательно.

не станем называть это паранойей… кто там знает, что могло быть подписано парными ключами от тех, что лежат в этих сертификатах…

ну… и это тоже — не будем считать паранойей…

Сайт

Об Ubuntu

Скачать Ubuntu

Семейство Ubuntu

Новости

Форум

Помощь

Правила

Документация

Пользовательская документация

Официальная документация

Семейство Ubuntu

Материалы для загрузки

Совместимость с оборудованием

RSS лента

Сообщество

Наши проекты

Местные сообщества

Перевод Ubuntu

Тестирование

RSS лента

© 2018 Ubuntu-ru — Русскоязычное сообщество Ubuntu Linux.
© 2012 Canonical Ltd. Ubuntu и Canonical являются зарегистрированными торговыми знаками Canonical Ltd.

Похожие публикации:

Nvcontainerwindowclass что

Какую раскладку клавиатуры выбрать при установке linux

Почему эмулятор андроид тормозит на пк

Что значит итератор

Bootx64 efi что это

Исправить ошибки Bootx64.efi и скачать

Обзор файла

Что такое сообщения об ошибках bootx64.efi?

bootx64.efi — ошибки выполнения

Как исправить ошибки bootx64.efi — 3-шаговое руководство (время выполнения: ~5-15 мин.)

Шаг 1. Восстановите компьютер до последней точки восстановления, «моментального снимка» или образа резервной копии, которые предшествуют появлению ошибки.

Шаг 2. Если вы недавно установили приложение Speakonia (или схожее программное обеспечение), удалите его, затем попробуйте переустановить Speakonia.

Шаг 3. Выполните обновление Windows.

Если эти шаги не принесут результата: скачайте и замените файл bootx64.efi (внимание: для опытных пользователей)

Unified Extensible Firmware Interface (Русский)

Версии UEFI

Разрядность прошивки UEFI

Проверка разрядности прошивки

Из Linux

Из macOS

Из Microsoft Windows

Конфигурация ядра Linux для UEFI

Переменные UEFI

Поддержка переменных UEFI в ядре Linux

Требования для поддержки переменных UEFI

Монтирование efivars

Пользовательские инструменты

efibootmgr

Отключение доступа к переменным UEFI

UEFI Shell

Получение UEFI Shell

Запуск UEFI Shell

Важные команды UEFI Shell

bcfg

map

edit

Драйверы UEFI

Загрузочные носители UEFI

Создание загрузочного UEFI USB из ISO

Удаление поддержки UEFI с оптического носителя

Тестирование UEFI на системах без его поддержки

OVMF для виртуальных машин

DUET для BIOS-систем

Решение проблем

Загрузка в Arch Linux после застревания в Windows

Открытие настроек прошивки без функциональных клавиш

Пользовательские инструменты не могут изменить переменные UEFI

Не удаётся создать загрузочные записи с помощью efibootmgr

Windows изменяет порядок загрузки

Чёрный экран при загрузке с USB

Загрузчик UEFI не отображается в меню прошивки

Стандартные пути загрузки для съёмных носителей

Расположение загрузчика Microsoft Windows

Загрузочные записи, созданные с помощью efibootmgr, не отображаются в UEFI

Загрузочная запись UEFI исчезает после удаления диска, на который она ссылается

Загрузочные записи удаляются случайным образом

Смотрите также

Настройка UEFI-загрузчика. Самое краткое руководство в мире

Как делать не надо

Не надо лезть в NVRAM и трогать efivars

Не надо использовать GRUB

«Самое краткое руководство» — чуть более подробно

Другие загрузчики

Различные неочевидные последствия

О UEFI

BIOS

(U)EFI

Совместимость

ESP раздел

MBR и GPT

Что нужно для того что бы ОС грузилась через BIOS?

Что нужно для установки ОС, что бы она грузилась через UEFI?

Менеджер загрузки UEFI

Secure Boot

Ключи системы Secure Boot

Собственные ключи

Создание ключей

Создание UEFI ключей

Создание хранилища ключей

Загрузка ключей

Через утилиту прошивки

Используя sbkeysync

Подписывание загрузчика

Возврат в режим Setup