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

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

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

  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 автоматически, смонтируйте его вручную, чтобы у инструментов вроде efibootmgr появился доступ к переменным UEFI:

# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
Примечание: При использовании chroot нужно выполнить монтирование и снаружи (то есть перед запуском chroot), и внутри него.

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

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

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

  • efivar — Библиотека и инструмент для работы с переменными UEFI (используется в efibootmgr)
https://github.com/rhboot/efivar || efivar
  • efibootmgr — Инструмент для работы с настройками менеджера загрузки прошивки UEFI
https://github.com/rhboot/efibootmgr || efibootmgr
  • uefivars — Выгружает список переменных UEFI с некоторой дополнительной информацией, связанной с PCI (использует код efibootmgr).
https://github.com/fpmurphy/Various/tree/master/uefivars-2.0 || uefivars-gitAUR
  • efitools — Инструменты для манипулирования платформами UEFI secure boot
https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git || efitools
  • Ubuntu's Firmware Test Suite — Набор тестов, выполняющий проверку исправности прошивок ПК Intel/AMD
https://wiki.ubuntu.com/FirmwareTestSuite/ || fwts-gitAUR

efibootmgr

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

Возможные решения:

  • Монтирование efivars в режиме только для чтения через fstab. Например:
    efivarfs /sys/firmware/efi/efivars efivarfs ro,nosuid,nodev,noexec 0 0
  • Использование параметра ядра noefi, который полностью отключит доступ к UEFI из ОС.
Примечание: #Пользовательские инструменты 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 лучше всего работает в системах 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.

Подробнее можно почитать Intel Scripting Guide 2008[устаревшая ссылка 2023-07-30 ⓘ] и Intel "Course" 2011[устаревшая ссылка 2023-07-30 ⓘ].

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

Смотрите Установочный образ на USB-накопителе#Создание загрузочного USB для BIOS и UEFI.

Удаление поддержки 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: команда
    $ systemctl reboot --firmware-setup
    перезагрузит компьютер в настройки прошивки.
  • Через GRUB: нажмите c для открытия командной строки и введите fwsetup.
  • Через Windows: через расширенные параметры запуска, как описано в разделе #Загрузка в Arch Linux после застревания в Windows.

Пользовательские инструменты не могут изменить переменные 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 "{bootmgr}" path "\EFI\путь\к\app.efi"
  • Как вариант, отключите Windows Boot Manager, выполнив efibootmgr -A -b bootnumber от имени root. Замените bootnumber на фактический номер записи Windows Boot Manager; вы можете узнать его, запустив efibootmgr без опций.
  • Ещё можно установить скрипт запуска в Windows, который обеспечивает правильную установку порядка загрузки при каждой загрузке Windows.
    1. Запустите командную строку от имени администратора. Выполните bcdedit /enum firmware и найдите нужную загрузочную запись.
    2. Скопируйте его идентификатор вместе с фигурными скобками, например {31d0d5f4-22ad-11e5-b30b-806e6f6e6963}
    3. Создайте bat-файл с командой bcdedit /set "{fwbootmgr}" DEFAULT "{скопированный-идентификатор}"
    4. Откройте gpedit.msc и в разделе Политика "Локальный компьютер" > Конфигурация компьютера > Конфигурация Windows > Сценарии (запуск/завершение) выберите пункт Автозагрузка.
    5. На вкладке Сценарии нажмите кнопку Добавить и выберите ваш bat-файл.
Примечание: Windows 10 Home официально не включает в себя gpedit.msc, хотя существуют неподдерживаемые обходные пути для его установки вручную.
  • В качестве альтернативы можно воспользоваться планировщиком заданий:
    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 и введите:

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-приложение, если использовать это стандартное имя.

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