EFI System Partition

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page EFI System Partition and the translation is 45% complete.
Outdated translations are marked like this.

EFI system partition (ESP) — это раздел, сформатированный в FAT и содержащий основные EFI загрузчики или образы ядер для установленных операционных систем.


Должны быть включены параметры «Advanced partition selection» (CONFIG_PARTITION_ADVANCED) и «EFI GUID Partition support» (CONFIG_EFI_PARTITION):

ЯДРО Включение поддержки GPT
-*- Enable the block layer --->
   Partition Types --->
      [*] Advanced partition selection
      [*] EFI GUID Partition support

Также должна быть включена кодовая страница ISO8859-1 для того, чтобы монтировать FAT EFI-раздел:

ЯДРО Включение кодовой страницы ISO8859-1 и поддержка VFAT
-*- File Systems --->
   DOS/FAT/EXFAT/NT Filesystems  --->
      <*> VFAT (Windows-95) fs support
      (437) Default codepage for FAT
      (iso8859-1) Default iocharset for FAT
   Native Language support --->
      [*] NLS ISO 8859-1  (Latin 1; Western European Languages)


Для инструкций по созданию обратитесь к Руководству.

parted (sys-block/parted) отобразит раздел вместе с флагами boot, esp:

root #parted /dev/sda print
Model: ATA SAMSUNG SSD SM84 (scsi)
Disk /dev/sda: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 
Number  Start   End     Size    File system  Name                          Flags
 1      1049kB  99.6MB  98.6MB  fat32        EFI System Partition          boot, esp

gdisk (sys-apps/gptfdisk) отобразит раздел с кодом EF00:

root #gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.1
Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 500118192 sectors, 238.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 1B59C2C8-8795-4625-9718-4D636B005AC1
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 500118158
Partitions will be aligned on 2048-sector boundaries
Total free space is 2669 sectors (1.3 MiB)
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          194559   94.0 MiB    EF00  EFI System Partition

Файловая система раздела может быть создана с помощью команды mkfs.fat:

root #mkfs.fat -F 32 /dev/sda1

Соображения по размеру

Руководство пользователя Gentoo рекомендует выделить 1 ГиБ для раздела ESP, чего более чем достаточно для любого загрузчика типа ядер с EFI stub или Windows.

Точка монтирования

Mounting the ESP to /boot/efi/, as was traditionally done, is not recommended. A nested setup complicates implementation of best-practice autofs-style mounts, as establishing the inner autofs will trigger the outer one. Mounting these partitions via autofs (and by extension keeping them unmounted whenever possible) is recommended due to the data integrity and security characteristics of VFAT file systems being effectively nonexistent.

Where bootloader support is available use /boot for the XBOOTLDR partition and /efi for the ESP. If it is not possible to do so, a monolithic ESP should be mounted at /boot; autofs-style mounts should still be used.

systemd, when partitions are configured according to the Discoverable Partitions Specification, can automatically mount the ESP used for the current boot to /boot or /efi unless a different partition is mounted there [possibly via /etc/fstab] or the mount point directory is not empty. If both ESP and XBOOTLDR exist, the /efi mount point is used.

For systemd (if not using the GPT auto generator):

ФАЙЛ /etc/fstabНастройка точки монтирования ESP для systemd
UUID=56FE-81E0        /efi       vfat    defaults,noatime,uid=0,gid=0,umask=0077,x-systemd.automount,x-systemd.idle-timeout=600 0 2

For OpenRC, use AutoFS to mount on-demand:

root #emerge --ask net-fs/autofs

Setup a Direct AutoFS Mount for the ESP.

ФАЙЛ /etc/autofs/auto.masterConfiguring autofs to read the 'boot' file
/- /etc/autofs/auto.boot --timeout=600,sync,nodev

Tell AutoFS to watch for access to the paths /boot and /efi and mount them with options from device.

ФАЙЛ /etc/autofs/auto.bootНастройка точки монтирования ESP
/boot    -fstype=vfat,uid=0,gid=0,umask=0077     UUID=AB12-CD34
/efi     -fstype=vfat,uid=0,gid=0,umask=0077     UUID=EF00-000A

AutoFS needs to be running to watch mountpoints:

root #rc-update add autofs default

To use the automounter before rebooting, start it manually:

root #/etc/init.d/autofs start

There is no need to add these partitions to /etc/fstab.

Стандартная конфигурация

Существует стандартная конфигурация для ESP. Производители оборудования и операционных систем должны размещать свои файлы в каталоги, специфичные для производителя.

user $tree -L 3 /efi
 └── EFI
     ├── BOOT
     │   └── BOOTX64.EFI
     ├── Linux
     │   └── gentoo-x.y.z-dist.efi
     └── Microsoft
         ├── Boot
         └── Recovery

Здесь представлены подкаталоги Microsoft и Boot[1] — они были созданы ранее при установке ОС Windows 10. Подкаталог Boot является каталогом для сценариев по умолчанию. Если UEFI не может найти специфичных для производителя каталогов, он попытается загрузить систему отсюда. В мультизагрузочном окружении с корректно созданными подкаталогами производителей каталог Boot может быть удален.

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

Компьютеры с поддержкой UEFI обычно предоставляют меню загрузки и конфигурационную утилиту для создания, сортировки и удаления загрузочных записей. Содержимое ESP доступно этим инструментам, поэтому создание загрузочной записи является ничем иным как выбор доступного носителя, просмотр ESP и выбор необходимой записи, например bzImage-4.9.76-r1-gentoo.efi.

An installation tool will not only manage the bootloader and other required files on the ESP, it will also manage the addition of an "EFI boot entry". EFI boot entries, stored in NVRAM, are like the registration of the bootloader to the firmware. EFI will normally only list bootloaders with a boot entry in the boot menu, therefore it is not sufficient to only copy a bootloader or EFI executable to the ESP. Linux bootloaders will normally automatically add an EFI boot entry on installation of an (U)EFI bootloader, like e.g. GRUB with grub-install.

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

In case a bootloader is deleted from the ESP, UEFI will normally delete the EFI boot entry as well on startup, and the bootloader will no longer be available from the boot menu, even when the file is afterwards restored, i.e. copied to the same path on the ESP.

One single exception, where no EFI boot entry is required, is the removable media boot path. On internal (fixed) media, such as the internal HDD or SDD, it is also used as the fallback boot path on most UEFI systems.

Removable media

EFI bootloaders on removable media are not configured as boot entries, so tools like efibootmgr are not required. Instead the computer firmware identifies removable boot options by looking for a predefined file name unique to the system architecture in use, in a predefined path.[2]

Most (U)EFI implementations support the use of the removable media boot path as a fallback on internal drives.[3] Even though this is against specification, most systems use it as a fallback and it may even be the only usable bootloader on a system with a buggy (U)EFI. Only one such fallback bootloader is possible on a specific system (i.e. architecture), due to the standardized boot path and file names.

Architecture Abbreviation File name PE executable machine type
x86 32-bit IA-32 \efi\boot\bootia32.efi 0x14c
x86-64 (amd64) x64 \efi\boot\bootx64.efi 0x8664
Itanium IA-64 \efi\boot\bootia64.efi 0x200
ARM 32-bit AArch32 \efi\boot\bootarm.efi 0x01c2
ARM 64-bit AArch64 \efi\boot\bootaa64.efi 0xAA64
RISC-V 32-bit \efi\boot\bootriscv32.efi 0x5032
RISC-V 64-bit \efi\boot\bootriscv64.efi 0x5064
RISC-V 128-bit \efi\boot\bootriscv128.efi 0x5128
Loongson 32-bit LoongArch32 \efi\boot\bootloongarch32.efi 0x6232
Loongson 64-bit LoongArch64 \efi\boot\bootloongarch64.efi 0x6264
To boot from removable media, the firmware has to look for compatible bootloaders on supported devices, which can be configured in the firmware setup. Like most firmwares, (U)EFI provides a hotkey to show a boot selection (formally known as "BIOS Boot Specification" or BBS), otherwise (U)EFI will use the configured default boot entry. However, a buggy (U)EFI may default to the removable media boot path even on internal drives.

To use the removable media boot path it is sufficient to copy the EFI bootloader to the required path and file name. Should the firmware make use of this fallback, this may also remove the ability to select between configured boot entries, meaning that boot options (as listed with efibootmgr) through (U)EFI will not work. Even though every EFI bootloader can be used as fallback, it may be advisable to use a boot manager that itself has the ability to select between boot options, such as GRUB. From the above example for x64 (amd64):

root #cp /efi/EFI/Grub/grubx64.efi /efi/EFI/boot/bootx64.efi
The FAT file system of the EFI System Partition (ESP) is not case-sensitive, but case-preserving (VFAT), while Unix is traditionally strictly case-sensitive. In the Linux kernel, vfat defaults to treating names case-insensitive (mount option check=r for relaxed),[4] so the above command on the ESP will always work. Only when VFAT has been mounted with strict case checking, check=s, the path /efi/EFI/boot/bootx64.efi may not work, as the existing files and directories could be using capital letters, e.g. /efi/EFI/BOOT or /efi/EFI/Boot (which would be different directories with strict case-sensitivity); the same goes for bootx64.efi. Running tree -L 3 /efi (when the ESP is mounted under /efi) will show the names in use on the individual system, to which the above command has to be changed accordingly.
The fallback bootloader is not automatically updated! Every time e.g. GRUB is re-installed (like after a version update, which may contain security fixes), it has to be copied to the fallback boot path again, overwriting (updating) the previous version!

The boot manager included in systemd, systemd-boot (formally Gummiboot), will automatically install to the removable media boot path. When sys-apps/systemd with the boot USE flag is updated, it is necessary to run bootctl again in order to update both bootloader files.

root #bootctl update

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