EFI system partition (Русский)

Состояние перевода:
На этой странице представлен перевод статьи
EFI system partition
. Дата последней синхронизации: 17 февраля 2024. Вы можете
помочь
синхронизировать перевод, если в английской версии произошли
изменения
.
Ссылки по теме
Unified Extensible Firmware Interface (Русский)
Загрузчик
Системный раздел EFI
(EFI system partition, также называемый ESP или EFISYS) — это независимый от ОС раздел, который служит местом хранения загрузчиков UEFI и приложений, которые будут запускаться прошивкой UEFI. Он необходим для загрузки системы в режиме UEFI.
Проверка существования раздела
Если вы устанавливаете Arch Linux на компьютер с поддержкой UEFI и предустановленной ОС, например,
Windows
10, то вполне вероятно, что у вас уже есть системный раздел EFI.
Чтобы посмотреть схему разделов диска и системный раздел, запустите
fdisk
от имени root, указав диск, с которого вы хотите загрузиться:
# fdisk -l /dev/sd
x
Эта команда выведет:
Таблицу разделов диска:
GPT
будет обозначен как
Тип метки диска: gpt
, а
MBR
— как
Тип метки диска: dos
.
Список разделов на диске: поищите в списке системный раздел EFI, он обычно имеет размер не менее 100 МиБ и тип
EFI System
или
EFI (FAT-12/16/32)
. Чтобы убедиться, что это ESP,
смонтируйте
его и проверьте, содержит ли он каталог с именем
EFI
; если да, то это точно ESP.
Совет
Чтобы узнать, является ли файловая система FAT12, FAT16 или FAT32, смотрите
FAT (Русский)#Определение типа FAT
.
Важно
Если в системе уже есть другие установленные операционные системы и вы не хотите их удалять, не форматируйте существующий системный раздел EFI, так как форматирование сотрёт загрузчики других систем. Используйте существующий раздел как есть и просто
монтируйте его
.
Если вы нашли существующий системный раздел EFI, просто переходите к разделу
#Монтирование раздела
. Если раздел не нашёлся, его нужно создать:
#Создание раздела
.
Создание раздела
В следующих двух разделах показано, как создать системный раздел EFI (ESP).
Важно
Системный раздел EFI должен быть физическим разделом в основной таблице разделов диска, не под LVM или программным RAID и т. д.
Раздел должен иметь достаточно большой размер для хранения загрузчиков и других файлов, необходимых для загрузки.
Рекомендуется сделать раздел размером 1 ГиБ, чтобы в нём было достаточно места для размещения нескольких ядер или unified kernel images, загрузчика, файлов обновлений прошивки и любых других файлов операционной системы или OEM. Если всё равно есть сомнения, то 4 ГиБ должно хватить всем.
Примечание
Можно сделать размер меньше, но могут быть проблемы с совместимостью:
Для ранних и/или несовершенных реализаций UEFI может потребоваться размер не менее 512 МиБ.
[1]
Если вы планируете монтировать системный раздел EFI как
/boot
и при этом использовать только одно ядро, то 400 МиБ должно хватить.
При
двойной загрузке с Windows
размер должен составлять не менее 300 МиБ для дисков с размером логического сектора 4096 байт (диски
Advanced Format
4Kn)
[2]
или не менее 100 МиБ в других случаях.
[3]
Для форматирования в FAT32 размер раздела должен быть не менее 36 МиБ при размере сектора 512 байт и не менее 260 МиБ при размере сектора 4096 байт.
[4]
Если ни одна из этих проблем не актуальна, размер раздела может составлять всего 2 МиБ, хотя тогда в него не поместится ничего кроме загрузчика.
Разметка дисков GPT
Системный раздел EFI в
таблице разделов GUID
идентифицируется с помощью
GUID типа раздела
C12A7328-F81F-11D2-BA4B-00A0C93EC93B
.
Выберите один
из следующих способов создания ESP для диска GPT с разделами:
fdisk
: Создайте раздел и
измените тип раздела
на
EFI System
.
gdisk
: Создайте раздел с типом раздела
EF00
.
GNU Parted
: Создайте раздел
fat32
и в Parted активируйте флаг
esp
.
После создания раздел нужно отформатировать; переходите к разделу
#Форматирование раздела
.
Разметка дисков MBR
Важно
Крайне рекомендуется использовать GPT вместо MBR.
Некоторые прошивки могут не поддерживать загрузку UEFI/MBR из-за того, что она не поддерживается
установкой Windows
.
bootctl
не поддерживает установку
systemd-boot
на MBR-диск; смотрите
systemd issue 1125
.
Подробнее об ограничениях MBR и преимуществах GPT смотрите в разделе
Разметка дисков#Выбор между GPT и MBR
.
Системный раздел EFI в
главной загрузочной записи
идентифицируется с помощью
partition ID
EF
.
Выберите один
из следующих способов создания ESP для диска MBR с разделами:
fdisk
: Создайте первичный раздел и
измените тип раздела
на (
EFI (FAT-12/16/32)
.
GNU Parted
: Создайте первичный раздел
fat32
и в Parted активируйте флаг
esp
.
После создания раздел нужно отформатировать; переходите к разделу
#Форматирование раздела
.
Форматирование раздела
Спецификация UEFI предусматривает поддержку файловых систем FAT12, FAT16 и FAT32 (
UEFI specification version 2.10, section 13.3.1.1
), но производители могут по желанию добавить поддержку дополнительных файловых систем; например, прошивки компьютеров Apple
Mac
поддерживают файловую систему HFS+.
Для предотвращения возможных проблем с другими операционными системами и поскольку в спецификации UEFI говорится, что UEFI «включает использование FAT32 для системного раздела и FAT12 или FAT16 для съёмных носителей»
[5]
, рекомендуется использовать
FAT32
. Используйте утилиту
mkfs.fat(8)
из пакета
dosfstools
:
# mkfs.fat -F 32 /dev/sd
xY
Если вы получили сообщение
WARNING: Not enough clusters for a 32 bit FAT!
и у вас нет возможности увеличить размер раздела, уменьшите размер кластера с помощью команды
mkfs.fat -s2 -F32 ...
или
-s1
; иначе раздел может оказаться нечитаемым для UEFI. Поддерживаемые размеры кластера можно посмотреть в
mkfs.fat(8)
.
Для разделов размером менее 32 МиБ использовать FAT32 не получится. В этом случае отформатируйте его в FAT16 или даже FAT12. Например, ESP размером 2 МиБ будет поддерживать только FAT12:
# mkfs.fat -F 12 /dev/sd
xY
Монтирование раздела
Ядра, файлы initramfs и, в большинстве случаев,
микрокод
процессора должны быть доступны
загрузчику
или самому UEFI для успешной загрузки системы. Таким образом, если вы хотите сохранить простоту установки, выбор загрузчика ограничивает варианты выбора точки монтирования для системного раздела EFI.
Примечание
Если ESP монтируется не в
/boot
, то при обновлении ядра не полагайтесь на
механизм автоматического монтирования systemd
(в том числе
systemd-gpt-auto-generator
). Всегда монтируйте его вручную перед любым обновлением системы или ядра, иначе вы не сможете смонтировать его после обновления из-за недоступности нужных модулей ядра, что заблокирует вас в текущем запущенном ядре и приведёт к невозможности обновить копию ядра на ESP.
В качестве альтернативы можно
заранее загрузить необходимые модули ядра
, например:
/etc/modules-load.d/vfat.conf
vfat
nls_cp437
nls_ascii
Типичные точки монтирования
Есть три основных варианта монтирования системного раздела EFI.
Монтирование
ESP в
/boot
:
Это облегчает обслуживание и администрирование системы, поскольку
/boot
является путём по умолчанию, в который пакеты
микрокода
размещают файлы initramfs микрокода процессора, и в который
mkinitcpio
помещает
ядра
и образы
initramfs
.
Это обеспечивает доступ к вышеупомянутым файлам для большинства
загрузчиков
, поскольку не все из них могут обращаться к файлам на других томах.
Это предотвращает установку
прав доступа
и/или
расширенных атрибутов
отдельным файлам, поскольку FAT устанавливает глобальные права доступа во время монтирования.
Это увеличивает необходимый размер раздела, поскольку к файлам, обычно находящимся в
/boot
, добавляются файлы, связанные с EFI.
В случае двойной загрузки это приводит к тому, что специфичные для ОС загрузочные файлы могут подвергаться потенциально опасным манипуляциям со стороны других ОС.
Это делает
шифрование /boot
невозможным, так как файлы, связанные с EFI, должны быть доступны прошивке.
Монтирование
ESP в
/efi
:
Это отделяет файлы, специфичные для ОС, от файлов, связанных с EFI.
Это позволяет избежать увеличения размера ESP за счёт отказа от размещения в нём файлов, устанавливаемых в
/boot
: на ESP будут храниться только исполняемые файлы EFI (загрузчик (и, опционально, драйверы) и/или unified kernel image), что экономит место на разделе.
Позволяет использовать специфические для Linux права доступа на уровне файловой системы для файлов, находящихся в
/boot
, без специфичных для FAT ограничений.
Это позволяет монтировать ESP отдельно по необходимости,
например
, только во время обновления
загрузчика
.
При
шифровании системы
с соответствующей настройкой это позволяет оставить незашифрованными лишь несколько минимально необходимых файлов, а
/boot
будет защищён: это может быть полезно для
unified kernel image
или
загрузчиков
, имеющих драйверы файловой системы, способные прочитать ядро и прочие файлы из другого места.
Монтирование
ESP в
/efi
и дополнительно монтирование «Extended Boot Loader Partition» (XBOOTLDR) в
/boot
. Это может быть полезно, когда ранее созданный ESP слишком мал для размещения нескольких загрузчиков и/или ядер, но увеличить размер ESP проблематично (например, при установке Linux после Windows для
двойной загрузки
). Этот метод поддерживает как минимум
systemd-boot
.
Примечание
Монтирование в
/efi
является заменой
[6]
для ранее распространённой и ныне не рекомендуемой точки монтирования
/boot/efi
.
Каталог
/efi
изначально отсутствует; его нужно предварительно
создать
.
Альтернативные точки монтирования
Если вы не используете
#Типичные точки монтирования
, вам будет нужно самостоятельно скопировать файлы, необходимые для загрузки, в ESP (далее обозначается как
esp
).
# mkdir -p
esp
/EFI/arch
# cp -a /boot/vmlinuz-linux
esp
/EFI/arch/
# cp -a /boot/initramfs-linux.img
esp
/EFI/arch/
# cp -a /boot/initramfs-linux-fallback.img
esp
/EFI/arch/
Примечание
Вам также может понадобиться скопировать
микрокод
.
Кроме того, вам нужно будет поддерживать файлы на ESP в актуальном состоянии при последующих обновлениях ядра. Несоблюдение этого требования может привести к незагружаемой системе. В следующих разделах обсуждаются несколько механизмов для автоматизации этого процесса.
Использование bind-монтирования
Вместо того, чтобы монтировать целиком ESP в
/boot
, вы можете подключить отдельный каталог ESP к
/boot
с помощью bind-
монтирования
(смотрите
mount(8)
). Это позволяет
pacman
обновлять ядро напрямую, а вам — организовать файлы в ESP по своему вкусу.
Примечание
Для этого требуется, чтобы
ядро
и
загрузчик
были совместимы с FAT32. Это не является проблемой для обычной установки Arch, но может быть проблематичным для других дистрибутивов (а именно тех, которые требуют символических ссылок в
/boot/
). Смотрите сообщение на форуме
[7]
.
Как описано в
начале раздела
, скопируйте все загрузочные файлы в каталог вашего ESP, но смонтируйте ESP
вне
/boot
. Затем выполните bind-монтирование каталога:
# mount --bind
esp
/EFI/arch/ /boot
Если всё хорошо, отредактируйте свой
Fstab
, чтобы сделать изменение постоянным:
/etc/fstab
esp
/EFI/arch /boot none defaults,bind 0 0
Использование systemd
Systemd
поддерживает задачи, запускаемые по событию. В данном конкретном случае возможность обнаружения изменения пути используется для синхронизации файлов ядра EFISTUB и initramfs, когда они обновляются в
/boot/
. Файл, который проверяется на изменения, это
initramfs-linux-fallback.img
, так как это последний файл, который собирает mkinitcpio, что позволяет убедиться, что все нужные файлы были собраны перед началом копирования. Файлы path и service, которые должны быть созданы, следующие:
/etc/systemd/system/efistub-update.path
[Unit]
Description=Copy EFISTUB Kernel to EFI system partition

[Path]
PathChanged=/boot/initramfs-linux-fallback.img

[Install]
WantedBy=multi-user.target
WantedBy=system-update.target
/etc/systemd/system/efistub-update.service
[Unit]
Description=Copy EFISTUB Kernel to EFI system partition

[Service]
Type=oneshot
ExecStart=/usr/bin/cp -af /boot/vmlinuz-linux
esp
/EFI/arch/
ExecStart=/usr/bin/cp -af /boot/initramfs-linux.img
esp
/EFI/arch/
ExecStart=/usr/bin/cp -af /boot/initramfs-linux-fallback.img
esp
/EFI/arch/
Затем
запустите
и
включите
efistub-update.path
.
Совет
При использовании
Secure Boot
с собственными ключами можно настроить службу на подпись образов с помощью
sbsigntools
:
ExecStart=/usr/bin/sbsign --key
/путь/к/db.key
--cert
/путь/к/db.crt
--output
esp
/EFI/arch/vmlinuz-linux /boot/vmlinuz-linux
Использование событий файловой системы
События файловой системы
можно использовать для запуска скрипта, синхронизирующего ядро EFISTUB после обновления ядра. Ниже приведён пример с использованием
incron
.
/usr/local/bin/efistub-update
#!/bin/sh
cp -af /boot/vmlinuz-linux
esp
/EFI/arch/
cp -af /boot/initramfs-linux.img
esp
/EFI/arch/
cp -af /boot/initramfs-linux-fallback.img
esp
/EFI/arch/
Примечание
Первый параметр
/boot/initramfs-linux-fallback.img
— файл, за которым ведётся наблюдение. Второй параметр
IN_CLOSE_WRITE
— отслеживаемое действие. Третий параметр
/usr/local/bin/efistub-update
— скрипт для выполнения.
/etc/incron.d/efistub-update.conf
/boot/initramfs-linux-fallback.img IN_CLOSE_WRITE /usr/local/bin/efistub-update
Включите
службу
incrond.service
.
Использование хука mkinitcpio
Mkinitcpio
может генерировать хук, для работы которого не нужен демон системного уровня. Он порождает фоновый процесс, который ожидает генерации
vmlinuz
,
initramfs-linux.img
и
initramfs-linux-fallback.img
перед копированием файлов.
Добавьте
efistub-update
в список хуков в
/etc/mkinitcpio.conf
.
/etc/initcpio/install/efistub-update
#!/usr/bin/env bash
build() {
	/usr/local/bin/efistub-copy $$ &
}

help() {
	cat <<HELPEOF
This hook waits for mkinitcpio to finish and copies the finished ramdisk and kernel to the ESP
HELPEOF
}
/usr/local/bin/efistub-copy
#!/bin/sh

if [ "$1" -gt 0 ]
then
	while [ -e /proc/"$1" ]
	do
		sleep .5
	done
fi

rsync -a /boot/
esp
/

echo "Synced /boot with ESP"
Использование предустановки mkinitcpio
Поскольку предустановки в
/etc/mkinitcpio.d/
поддерживают shell-скрипты, ядро и initramfs могут быть скопированы простым редактированием предустановок.
Замена хука mkinitcpio
Измените файл
/etc/mkinitcpio.d/linux.preset
:
/etc/mkinitcpio.d/linux.preset
# mkinitcpio preset file for the 'linux' package

# Directory to install the kernel, the initramfs...
ESP_DIR="
esp
/EFI/arch"

#ALL_config="/etc/mkinitcpio.conf"
ALL_kver="${ESP_DIR}/vmlinuz-linux"
[[ -e /boot/intel-ucode.img ]] && cp -af /boot/intel-ucode.img "${ESP_DIR}/"
[[ -e /boot/amd-ucode.img ]] && cp -af /boot/amd-ucode.img "${ESP_DIR}/"

PRESETS=('default' 'fallback')

#default_config="/etc/mkinitcpio.conf"
default_image="${ESP_DIR}/initramfs-linux.img"
default_options=""

#fallback_config="/etc/mkinitcpio.conf"
fallback_image="${ESP_DIR}/initramfs-linux-fallback.img"
fallback_options="-S autodetect"
Для тестирования выполните:
# rm /boot/initramfs-linux-fallback.img /boot/initramfs-linux.img
# mv /boot/vmlinuz-linux
esp
/EFI/arch/
# mkinitcpio -p linux
Другой пример
/etc/mkinitcpio.d/linux.preset
ESP_DIR="
esp
/EFI/arch"
#ALL_config="/etc/mkinitcpio.conf"
ALL_kver="$ESP_DIR/vmlinuz-linux$suffix"
PRESETS=('default')
default_config="/etc/mkinitcpio.conf"
default_image="$ESP_DIR/initramfs-linux$suffix.img"
/etc/mkinitcpio.d/linux-zen.preset
suffix='-zen'
source /etc/mkinitcpio.d/linux.preset
Использование хука pacman
Последний вариант полагается на
хуки pacman
, которые запускаются в конце транзакции.
Первый файл — это хук, который отслеживает соответствующие файлы и запускается, если они были изменены в прошедшей транзакции.
/etc/pacman.d/hooks/999-kernel-efi-copy.hook
[Trigger]
Type = Path
Operation = Install
Operation = Upgrade
Target = usr/lib/modules/*/vmlinuz
Target = usr/lib/initcpio/*
Target = boot/*-ucode.img

[Action]
Description = Copying linux and initramfs to EFI directory...
When = PostTransaction
Exec = /usr/local/bin/kernel-efi-copy.sh
Второй файл — собственно копирующий скрипт. Создайте его и сделайте
исполняемым
:
/usr/local/bin/kernel-efi-copy.sh
#!/bin/sh
#
# Copy kernel and initramfs images to EFI directory
#

ESP_DIR="
esp
/EFI/arch"

for file in /boot/vmlinuz*
do
        cp -af "$file" "$ESP_DIR/$(basename "$file").efi"
        [ $? -ne 0 ] && exit 1
done

for file in /boot/initramfs*
do
        cp -af "$file" "$ESP_DIR/"
        [ $? -ne 0 ] && exit 1
done

[ -e /boot/intel-ucode.img ] && cp -af /boot/intel-ucode.img "$ESP_DIR/"
[ -e /boot/amd-ucode.img ] && cp -af /boot/amd-ucode.img "$ESP_DIR/"

exit 0
Решение проблем
ESP в программном RAID1
Можно сделать ESP частью массива RAID1, но при этом возникает риск повреждения данных, и при создании ESP необходимо принять дополнительные меры. Смотрите
[8]
,
[9]
и
UEFI booting and RAID1
для подробностей.
Ключевым моментом является использование параметра
--metadata 1.0
, чтобы сохранить метаданные RAID в конце раздела, иначе прошивка не сможет получить к ним доступ:
# mdadm --create --verbose --level=1
--metadata=1.0
--raid-devices=2 /dev/md/ESP /dev/sda
X
/dev/sdb
Y
Прошивка не видит каталог EFI
Если вы задаёте файловой системе FAT
имя тома (то есть метку файловой системы)
, убедитесь, что оно не совпадает с именем
EFI
. Это может вызвать ошибку в некоторых прошивках (из-за совпадения имени тома с именем каталога EFI), которая заставит прошивку вести себя так, как будто каталог EFI не существует.
Смотрите также
Системный раздел EFI и поведение загрузки по умолчанию
Multi Boot Linux With One Boot Partition | John Ramsden