Uefi shell что это

Built-in EFI Shell — что это?

Built-in EFI Shell — опция в boot-меню, с которой сегодня нам нужно разобраться. На официальном сайте ASRock указано что данная опция используется при создании RAID-массива.

Опцию можно заметить, если нажать кнопку F11 при загрузке системы. Возможно на материнках ASRock F11 запускает загрузочное меню (boot menu).

Информация по поводу того что опция имеет отношение к RAID найдена здесь:

Если разобрать название Built-in EFI Shell, то получается Built-in это переводится как встроенный, EFI — некий интерфейс между железом и операционкой, Shell — оболочка, то есть визуальная составляющая.

Вот и сама опция в биосе:

Какой можно сделать вывод? Без причины трогать опцию Built-in EFI Shell не стоит.

О UEFI

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

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

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

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

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

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

Идеи отказаться от всего того ненужного, что делает 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 была запрещена.

ESP раздел

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

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

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.

Получившаяся в результате «солянка» (из 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.

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

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

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

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

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

Переменные 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, где — одно из:

Если загрузка по умолчанию не прошла, то менеджер загрузки 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 раздела (подписи добавляются к коду). Если верификация не прошла — такому коду отказывают в запуске.

Однако, довольно быстро шумиха улеглась. Во-первых 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 — не единственная причина по которой может не происходить загрузка с установочной флешки или диска).

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

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

Ключи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Используя sbkeysync

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

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

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

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

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

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

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

Хотя лучше убедиться, что вернуть 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 записаны именно те ключи, что вы хотели и не забудьте проверить правильность подписей.

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

EFS раздел (необходимый для загрузки в UEFI режиме) прописан и в таблицу разделов в MBR, и в каталог разделов iso9660 формата. По UEFI стандарту загрузчик по умолчанию должен находится в EFS разделе по пути: 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, что позволяет загрузиться из образа на большинстве компьютеров.

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

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

Образ 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).

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

После этой команды у вас появится новый пункт меню загрузки 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 будет выглядеть примерно так:

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

В первом варианте — для загрузки из 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)

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

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

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

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

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

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

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

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

То же самое можно сделать командой bcfg из UEFI-Shell. Следующая команда добавит пункт загрузки Driver0000 (номер задает первый аргумент команды add), который будет загружать драйвер из файла EFI\drivers\ext2_x64.efi (с ESP раздела). Драйвер получит описание «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 и сохранить файл.

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

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

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

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

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

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

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

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

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

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

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

Более детальная проработка этого варианта описана в отдельной статье UEFI Boot. Там реализовано автоматическое обновление пунктов загрузки 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.

У всех этих утилит есть вполне толковые 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 лет назад отпущенная шутка, до сих пор стреляет, да еще с невиданной доселе мощью.

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

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

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

Contents

Версии 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. Если не указано явно, эти инструкции являются общими, и некоторые из них могут не работать или отличаться в MacBook.

Спецификацию последней версии 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-приложение должно быть скомпилировано для конкретной разрядности/архитектуры процессора, на котором работает прошивка.

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

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

Из Linux

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

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

Из macOS

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

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

Если команда возвращает значение 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] такова:

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

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

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

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

Переменные UEFI

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

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

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

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

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

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

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

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

Если systemd не смонтировал efivarfs в /sys/firmware/efi/efivars автоматически, смонтируйте его вручную:

Документация ядра доступна здесь: 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/sdaY или /dev/nvme0n1pY .
• Путь к приложению EFI (относительно корня ESP).

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

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

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

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

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

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

• Монтирование efivars в режиме только для чтения через fstab. Например:
• Использование параметра ядра noefi , который полностью отключит доступ к UEFI из ОС.

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.
  от TianoCore (больше не обновляется).
  — из загрузчика Clover EFI. — из загрузчика 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 в корне тома. и systemd-boot автоматически добавляют пункт меню для UEFI Shell, если находят shellx64.efi в корне системного раздела EFI.

  Системы с прошивкой Phoenix SecureCore Tiano UEFI имеют встроенный UEFI Shell, которую можно запустить с помощью клавиши F6 , F11 или F12 .

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

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

  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.

  Список текущих загрузочных записей:

  Добавление пункта загрузки для rEFInd (например) как четвёртый (нумерация начинается с нуля) пункт в меню загрузки:

  где FS0: соответствует системному разделу EFI, а FS0:\EFI\refind\refind_x64.efi — запускаемый файл.

  Чтобы добавить запись для загрузки непосредственно в систему без загрузчика, настройте пункт загрузки, используя ваше ядро в качестве EFISTUB:

  где N — приоритет, V — номер тома системного раздела EFI, а /dev/sdX# — корневой раздел.

  Удаление четвёртого пункта загрузки:

  Перемещение четвёртого пункта на место первого пункта:

  Справка команды bcfg:

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

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

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

  Например, для редактирования файла refind.conf в системном разделе EFI (доступен в прошивке как FS0: ):

  Нажмите Ctrl+e для справки.

  Загрузочные носители 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:

  Затем пересоберите ISO, исключив поддержку загрузки оптических носителей UEFI, используя xorriso(1) из пакета libisoburn . Обязательно установите правильную метку тома, например ARCH_202103 ; её можно получить с помощью file(1) на исходном ISO.

  Запишите archlinux-версия-x86_64-noUEFI.iso на оптический носитель, и установка с него должна пройти нормально.

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

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

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

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

  Рекомендуется сделать локальную копию хранилища энергонезависимых переменных для вашей виртуальной машины:

  Чтобы использовать прошивку OVMF и это хранилище переменных, используйте следующие опции QEMU:

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

  DUET был проектом TianoCore, который позволял сделать chainloading полного окружения UEFI из системы BIOS, способом, аналогичным загрузке ОС BIOS. Этот метод подробно обсуждается на сайте https://www.insanelymac.com/forum/topic/186440-linux-and-windows-uefi-boot-using-tianocore-duet-firmware/. Образы DUET можно загрузить из одного из репозиториев по адресу https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer. Конкретные инструкции по настройке DUET доступны на https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/blob/master/Migle_BootDuet_INSTALL.txt. Однако по состоянию на ноябрь 2018 года код DUET был удалён из git-репозитория TianoCore.

  Вы также можете попробовать https://sourceforge.net/projects/cloverefiboot/ , который предоставляет модифицированные образы 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: команда перезагрузит компьютер в настройки прошивки.
  • Через GRUB: нажмите c для открытия командной строки и введите fwsetup .
  • Через Windows: через расширенные параметры запуска, как описано в разделе #Загрузка в Arch Linux после застревания в Windows.

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

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

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

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

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

  Windows 7 не загружается в режиме UEFI

  Если вы установили Windows на другой жёсткий диск с разметкой GPT, а в компьютере все еще есть жёсткий диск с разметкой MBR, то возможно, что прошивка (UEFI) включает поддержку CSM (для загрузки MBR-разделов), и поэтому Windows не загружается. Чтобы решить эту проблему, измените разметку жёсткого диска MBR на GPT или отключите порт SATA, в который вставлен жёсткий диск MBR, или отсоедините SATA-кабель от этого жёсткого диска.

  Материнские платы с подобной проблемой:

  • Gigabyte Z77X-UD3H rev. 1.1 (UEFI version F19e)
    • Опция загрузки «UEFI Only» не предотвращает запуск CSM.

    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 » «
      4. Откройте gpedit.msc и в разделе Политика «Локальный компьютер» > Конфигурация компьютера > Конфигурация Windows > Сценарии (запуск/завершение) выберите пункт Автозагрузка.
      5. На вкладке Сценарии нажмите кнопку Добавить и выберите ваш bat-файл.
    • В качестве альтернативы можно воспользоваться планировщиком заданий:
      1. Повторите шаги 1-3, описанные выше, для создания bat-файла.
      2. Запустите taskschd.msc и выберите пункт меню Действие > Создать задачу.
      3. На вкладке Общие: Введите подходящие Имя и Описание. Убедитесь, что выбранная учётная запись является администратором, а не обычным пользователем. Выберите пункт «Выполнять для всех пользователей«. Поставьте галочку «Выполнить с наивысшими правами«.
      4. На вкладке Триггеры создайте триггер При входе в систему.
      5. На вкладке Действия нажмите Создать, затем Обзор и выберите ваш bat-файл, созданный в первом шаге.
      6. На вкладке Условия снимите галочки в секции Питание, чтобы скрипт запускался при работе от батареи (для ноутбуков).
      7. Нажмите 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 и введите:

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

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

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

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

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

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

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

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

    1. Wcf ria services что это
    2. Webres dll что это
    3. Whitelabel error page что это за ошибка
    4. Win32 sector 17 что за вирус