EFI system partition (Русский)
Системный раздел EFI (также называемый ESP или EFISYS) представляет собой физический раздел в формате FAT32 (в основной таблице разделов диска, а не под LVM или программным RAID и т.д.), откуда прошивка UEFI запускает загрузчик и приложение UEFI.
Это независимый от ОС раздел, который служит местом хранения загрузочных устройств EFI и приложений, которые будут запускаться с помощью прошивки EFI. Это необходимо для загрузки UEFI.
Проверка существования раздела
Если вы устанавливаете Arch Linux на компьютер с поддержкой UEFI и предустановленной ОС, например, Windows 10, то вполне вероятно, что у вас уже есть системный раздел EFI.
Чтобы посмотреть схему разделов диска и системный раздел, запустите fdisk от имени root, указав диск, с которого вы хотите загрузиться:
# fdisk -l /dev/sdx
Эта команда выведет:
- Таблицу разделов диска: GPT будет обозначен как
Тип метки диска: gpt, а MBR — какТип метки диска: dos. - Список разделов на диске: поищите в списке системный раздел EFI, он обычно имеет размер не менее 100 МиБ и тип
EFI SystemилиEFI (FAT-12/16/32). Чтобы убедиться, что это ESP, смонтируйте его и проверьте, содержит ли он каталог с именемEFI; если да, то это точно ESP.
Если вы нашли существующий системный раздел EFI, просто переходите к разделу #Монтирование раздела. Если раздел не нашёлся, его нужно создать: #Создание раздела.
Создание раздела
В следующих двух разделах показано, как создать системный раздел EFI (ESP).
Размер раздела должен давать достаточно места для хранения загрузчиков и других файлов, необходимых для загрузки.
Для предотвращения проблем совместимости с другими операционными системами[1][2] рекомендуется делать его не менее 300 МиБ. Для ранних и/или несовершенных реализаций UEFI может потребоваться размер не менее 512 МиБ.[3] Если ни одна из этих проблем не актуальна, размер раздела может составлять всего 2 МиБ, хотя тогда в него не поместится ничего кроме загрузчика.
Разметка дисков GPT
Системный раздел EFI в таблице разделов GUID идентифицируется с помощью GUID типа раздела C12A7328-F81F-11D2-BA4B-00A0C93EC93B.
Выберите один из следующих способов создания ESP для диска GPT с разделами:
-
fdisk: Создайте раздел с типом раздела
EFI System. -
gdisk: Создайте раздел с типом раздела
EF00. -
GNU Parted: Создайте раздел
fat32и в Parted установите/активируйте флагesp.
После создания раздел нужно отформатировать; переходите к разделу #Форматирование раздела.
Разметка дисков MBR
- Рекомендуется использовать GPT, так как некоторые прошивки могут не поддерживать загрузку UEFI/MBR из-за того, что она не поддерживается установкой Windows.
- bootctl не поддерживает установку systemd-boot на MBR-диск. [4]
Смотрите также Разметка дисков#Выбор между 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.9, section 13.3.1.1), но производители могут по желанию добавить поддержку дополнительных файловых систем; например, прошивки компьютеров Apple Mac поддерживают файловую систему HFS+.
Для предотвращения возможных проблем с другими операционными системами и поскольку в спецификации UEFI говорится, что UEFI "включает использование FAT32 для системного раздела и FAT12 или FAT16 для съемных носителей"[5], рекомендуется использовать FAT32. Используйте утилиту mkfs.fat(8) из пакета dosfstools:
# mkfs.fat -F32 /dev/sdxY
Если вы получили сообщение 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/sdxY
Монтирование раздела
Ядра, файлы initramfs и, в большинстве случаев, микрокод процессора должны быть доступны загрузчику или самому UEFI для успешной загрузки системы. Таким образом, если вы хотите сохранить простоту установки, выбор загрузчика ограничивает варианты выбора точки монтирования для системного раздела EFI.
Типичные точки монтирования
Самыми простыми вариантами системного раздела EFI являются:
-
Монтирование ESP в
/efiи использование такого загрузчика, который способен прочитать файл ядра и initramfs откуда-то ещё (обычно из/boot). Информацию о требованиях и возможностях загрузчиков можно почитать в статье Процесс загрузки Arch#Загрузчик. -
Монтирование ESP в
/boot. Это предпочтительный метод при загрузке EFISTUB ядра напрямую из UEFI или загрузке через менеджер загрузки вроде systemd-boot. -
Монтирование ESP в
/efiи дополнительно монтирование "Extended Boot Loader Partition" (XBOOTLDR) в/boot. Это может быть полезно, когда ранее созданный ESP слишком мал для размещения нескольких загрузчиков и/или ядер, но увеличить размер ESP проблематично (например, при установке Linux после Windows для двойной загрузки). Этот метод поддерживает как минимум systemd-boot.
Альтернативные точки монтирования
Если вы не используете #Типичные точки монтирования, вам нужно скопировать файлы загрузки в 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 в актуальном состоянии при последующих обновлениях ядра. Несоблюдение этого требования может привести к незагружаемой системе. В следующих разделах обсуждаются несколько механизмов для автоматизации этого процесса.
/boot, не полагайтесь на механизм автоматического монтирования systemd (в том числе systemd-gpt-auto-generator(8)). Всегда монтируйте его вручную перед любым обновлением системы или ядра, иначе вы не сможете смонтировать его после обновления, что приведёт к блокировке текущего ядра и невозможности обновить копию ядра на ESP.
В качестве альтернативы предварительно загрузите необходимые модули ядра при загрузке, например:
/etc/modules-load.d/vfat.conf
vfat nls_cp437 nls_ascii
Использование bind монтирования
Вместо того, чтобы устанавливать ESP на /boot, вы можете подключить каталог ESP к /boot с помощью bind монтирования (смотрите mount(8)). Это позволяет pacman обновлять ядро напрямую, сохраняя при этом организацию ESP по своему вкусу.
/boot/). Смотрите сообщение на форуме [7].Как описано в начале раздела, скопируйте все загрузочные файлы в каталог вашего ESP, но смонтируйте ESP вне /boot. Затем привяжите смонтированный раздел к каталогу:
# 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.
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
#!/usr/bin/env bash 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 copy the kernel, the initramfs...
ESP_DIR="esp/EFI/arch"
ALL_config="/etc/mkinitcpio.conf"
ALL_kver="${ESP_DIR}/vmlinuz-linux"
cp -af /boot/vmlinuz-linux "${ESP_DIR}/"
[[ -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 # mkinitcpio -p linux
Другой пример
/etc/mkinitcpio.d/linux.preset
ESP_DIR="esp/EFI/arch"
cp -f "/boot/vmlinuz-linux$suffix" "$ESP_DIR/"
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
#!/usr/bin/env bash
#
# 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/sdaX /dev/sdbY
Прошивка не видит каталог EFI
Если вы задаёте файловой системе FAT имя тома (то есть метку файловой системы), убедитесь, что оно не совпадает с именем EFI. Это может вызвать ошибку в некоторых прошивках (из-за совпадения имени тома с именем каталога EFI), которая заставит прошивку вести себя так, как будто каталог EFI не существует.