EFI システムパーティション
EFI システムパーティション (EFI system partition, ESP) は FAT 形式のパーティションで、インストールされているオペレーティングシステムのためのプライマリ EFI ブートローダを含んでいます。
カーネル
Advanced partition selection(CONFIG_PARTITION_ADVANCED)と、EFI GUID Partition support(CONFIG_EFI_PARTITION)が有効になっていなければなりません:
-*- Enable the block layer --->
Partition Types --->
[*] Advanced partition selection
[*] EFI GUID Partition support
FAT EFI パーティションをマウントするために、ISO8859-1 コードページも有効になっていなければなりません:
-*- 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)はEFIパーティションを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)はEFIパーティションを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 ハンドブックは ESP のために 1 GiB を割り当てることを推奨していますが、これは EFI スタブカーネルまたは Windows などの、どんなブートローダペイロードにとっても十分過ぎる量です。
マウントポイント
伝統的に行われていたような、ESP を /boot/efi/ にマウントするやり方は、今は推奨されません。ネストされた構成を使用すると、ベストプラクティスの autofs スタイルのマウントの実装が複雑になります。内側の autofs を確立させようとすると、外側の autofs が発動してしまうからです。データの完全性のため、そして VFAT ファイルシステムにはセキュリティ特性が実質的に存在しないため、これらのパーティションを autofs 経由でマウントする (転じて、可能なときはいつでもマウントされていない状態にしておく) ことが推奨されます。
ブートローダのサポートが利用可能な場合、XBOOTLDR パーティションとして /boot を、ESP として /efi を使用してください。もしそうすることができない場合は、モノリシック ESP を /boot にマウントすべきです; その場合でも autofs スタイルマウントが使用されるべきです。
パーティションが Discoverable Partitions Specification に従って構成されている場合、systemd は現在のブートのために使用されている ESP を /boot または /efi に自動的にマウントすることができます。ただし、別のパーティションがそこにマウントされている [/etc/fstab などによって] 場合や、マウントポイントのディレクトリが空でない場合はできません。ESP と XBOOTLDR の両方が存在する場合は、/efi マウントポイントが使用されます。
systemd では (GPT auto generator を使用していない場合):
UUID=56FE-81E0 /efi vfat defaults,noatime,uid=0,gid=0,umask=0077,x-systemd.automount,x-systemd.idle-timeout=600 0 2
OpenRC では、オンデマンドでマウントするために AutoFS を使用してください:
root #
emerge --ask net-fs/autofs
ESP のための直接 AutoFS マウントをセットアップしてください。
/- /etc/autofs/auto.boot --timeout=600,sync,nodev
パス /boot および /efi へのアクセスを監視し、それらをオプション付きでデバイスからマウントするように、AutoFS に指示してください。
/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 が実行中である必要があります:
root #
rc-update add autofs default
オートマウンタを再起動前に使用するために、手動で開始してください:
root #
/etc/init.d/autofs start
/etc/fstab にこれらのパーティションを追加する必要はありません。
標準レイアウト
ESPの標準的なレイアウトです。ベンダやディストーションは、それらが使用するファイルなどをベンダ固有ディレクトリに保存していると見なされます。
user $
tree -L 3 /efi
/efi └── EFI ├── BOOT │ └── BOOTX64.EFI ├── Gentoo │ ├── grubx64.efi │ ├── initramfs-x.y.z.img │ ├── kernel-x.y.z.efi │ ├── mmx64.efi │ └── shimx64.efi ├── Linux │ └── gentoo-x.y.z.efi ├── Microsoft │ ├── Boot │ └── Recovery ├── refind │ └── refind_x64.efi └── systemd └── systemd-bootx64.efi
ここでは、Microsoft サブツリー (そして Boot サブツリー[1]) は、以前の Windows10 で作成されました。Boot サブツリーはフォールバックディレクトリです。もし UEFI がどのベンダ固有ディレクトリも見つけることができなかった場合、このフォールバックディレクトリから起動されます。適切にベンダ固有サブツリーが設定されたマルチブート環境では、Boot サブツリーは削除することができます。
UEFI ブートアイテム
UEFI 搭載のコンピュータは、ESP 上のブートローダのためのブートメニューを提供します。このブートメニューはファームウェアの機能であり、デフォルトでは表示されません。さらに、ブートメニューに入る方法の標準もありませんが、最もよくある方法は UEFI ファームウェア初期化 (POST (power-on self test) とも) 中にあるキーを押し続けることです。ほとんどの UEFI ファームウェアベンダは、接続されているキーボード上のファンクションキーのいずれかが押されていると、ブートメニューを表示するでしょう。ブートメニューは、同じく何らかの定義済みのキーを押すことでアクセスできる、ファームウェアセットアップ ("BIOS セットアップ") 内からでも利用できることがあります。最も一般的には、Esc、Del、F1、F2、F10、F11 および F12、そしてタブレットでは音量アップ/ダウンキーも、ファームウェアセットアップに入るため、またはブートメニューを表示するために、使用されます。[2] 正確にどのキーなのか、およびさらなる詳細については、使用中のシステムまたはメインボードのマニュアルを参照してください。
インストールツールは、ブートローダおよびその他の ESP 上に必要なファイルを管理するだけでなく、「EFI ブートエントリ」の追加も管理します。EFI ブートエントリは NVRAM 内に保存され、ファームウェアへのブートローダの登録のようなものです。EFI は通常は、ブートエントリを持つブートローダのみをブートメニュー内に一覧表示するでしょうから、ブートローダまたは EFI 実行可能形式を ESP にコピーするだけでは十分ではないでしょう。Linux ブートローダは通常は、例えば GRUB などの (U)EFI ブートローダを grub-install でインストールする時に、自動的に EFI ブートエントリを追加するでしょう。
代わりに、ブートアイテムの作成、並べ替え、削除のための構成設定ツールが、UEFI に対応した OS に含まれていることが多いです。ESP の内容ははこれらのツールから見ることができ、ブートアイテムの作成は、与えられた選択からメディアを選び、ESP を探査して、例えば bzImage-4.9.76-r1-gentoo.efi などのアイテムを選択するようなものです。Linux 上では、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.
リムーバブルメディア
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.[3]
Most (U)EFI implementations support the use of the removable media boot path as a fallback on internal drives.[4] 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.
アーキテクチャ | 略称 | ファイル名 | PE 実行可能形式のマシンタイプ |
---|---|---|---|
x86 32 ビット | 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 ビット | AArch32 | \efi\boot\bootarm.efi | 0x01c2 |
ARM 64 ビット | AArch64 | \efi\boot\bootaa64.efi | 0xAA64 |
RISC-V 32 ビット | \efi\boot\bootriscv32.efi | 0x5032 | |
RISC-V 64 ビット | \efi\boot\bootriscv64.efi | 0x5064 | |
RISC-V 128 ビット | \efi\boot\bootriscv128.efi | 0x5128 | |
Loongson 32 ビット | LoongArch32 | \efi\boot\bootloongarch32.efi | 0x6232 |
Loongson 64 ビット | 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),[5] 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
関連項目
- Handbook:AMD64/Installation/Disks/ja#EFI システムパーティション (ESP) とは
- UEFI — a firmware standard for boot ROM designed to provide a stable API for interacting with system hardware. On x86 it replaced the legacy BIOS.
- EFI stub — カーネルを設定して、EFI モードで実行中のコンピュータの EFI システムパーティション (ESP) にインストールするための手順を提供します
- efibootmgr — UEFI ブートエントリを管理するためのツールです。
- REFInd — rEFIt からフォークした後継の EFI および UEFI プラットフォーム向けブートマネージャ
参照
- ↑ https://wiki.debian.org/UEFI#Force_grub-efi_installation_to_the_removable_media_path
- ↑ https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/boot-to-uefi-mode-or-legacy-bios-mode
- ↑ UEFI 2.10 Specification, 3.5.1.1 Removable Media Boot Behavior
- ↑ Debian Wiki – UEFI: Force grub-efi installation to the removable media path
- ↑ https://www.kernel.org/doc/html/v6.0/filesystems/vfat.html