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 フラグとともに表示します：

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 コードとともに表示します：

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 コマンドを使用して 作成することができます:

サイズの考慮

Gentoo ハンドブック は ESP のために 1 GiB を割り当てることを推奨していますが、これは EFI スタブ カーネルまたは Windows などの、どんなブートローダペイロードにとっても十分過ぎる量です。

省略可能: マウントポイント

/etc/fstab に項目があると ESP をマウントする 際に便利ですが、ブートするために必須ではありません。

省略可能: autofs

伝統的に行われていたような、ESP を /boot/efi/ にマウントするやり方は、今は推奨されません。ネストされた構成を使用すると、ベストプラクティスの autofs スタイルのマウントの実装が複雑になります。内側の autofs を確立させようとすると、外側の autofs が発動してしまうからです。データの完全性のため、そして VFAT ファイルシステムにはセキュリティ特性が実質的に存在しないため、これらのパーティションを autofs 経由でマウントする (転じて、可能なときはいつでもマウントされていない状態にしておく) ことが推奨されます。

ブートローダのサポート が利用可能な場合、 XBOOTLDR パーティションとして /boot を、 ESP として /efi を使用してください。もしそうすることができない場合は、 モノリシック ESP を /boot にマウントすべきです; その場合でも autofs スタイル マウントが使用されるべきです。

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 を使用してください:

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 が実行中である必要があります:

オートマウンタを再起動前に使用するために、手動で開始してください:

/etc/fstab にこれらのパーティションを追加する必要はありません。

標準レイアウト

ESPの標準的なレイアウトです。ベンダやディストーションは、それらが使用するファイルなどをベンダ固有ディレクトリに保存していると見なされます。

 /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 および 12 、そしてタブレットでは 音量アップ および 音量ダウン キーも、ファームウェアセットアップに入るため、またはブートメニューを表示するために、使用されます。 ^[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 を使用することもできます。

BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0000,2001,2002,2003
Boot0000* Windows Boot Manager  HD(1,GPT,6d98f360-cb3e-4727-8fed-5ce0c040365d,0x800,0x1400000)/\EFI\Microsoft\Boot\bootmgfw.efiRC
Boot0001* Linux Boot Manager    HD(1,GPT,6d98f360-cb3e-4727-8fed-5ce0c040365d,0x800,0x1400000)/\EFI\systemd\systemd-bootx64.efi
Boot2001* EFI USB Device        RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network   RC

ブートローダーが ESP から削除された場合、 UEFI は通常、起動時に EFI ブートエントリも同様に削除するため、その後そのファイルが ESP の同じパスへコピーされるなどして復元された場合でもブートローダーはもはやブートメニューに表示されません。

EFI ブートエントリが不要になる唯一の例外は、リムーバブルメディアブートパスです。多くの UEFI システムの内部 HDD や SSD などの内部(固定)メディア上では、フォールバックブートパスとしても使われます。

リムーバブルメディア

リムーバブルメディア の EFI ブートローダーはブートエントリとして設定されないため、 efibootmgr のようなツールは不要です。それに代わって、コンピューターのファームウェアは、使用中のシステムアーキテクチャ特有のあらかじめ定義されているファイル名を、あらかじめ定義されているパス内で探すことによってリムーバブルブートオプションを識別します。 ^[3]

ほとんどの (U)EFI 実装では、 リムーバブルメディアブートパス を内部ドライブでフォールバックとして使用することができます。 ^[4] これは仕様には反していますが、ほとんどのシステムで、ブートエントリが(ファイルが存在しなくなったことなどにより)消滅したりして EFI ブートエントリが動作しない場合や、("CMOS バッテリー"の故障の際に起こる NVRAM のリセット、クリアまたは破損などにより) 永続ストアのエラーが生じたりして EFI 変数(Linux では efivarfs を使用してアクセスできます)が喪失した場合に、(フォールバックとして)使用されています。さらに、バグのある (U)EFI においては、これがそのシステムで使用できる唯一のブートローダでもあります。ブートパスとファイル名が標準化されているため、こうしたフォールバックブートローダーは、あるシステム(アーキテクチャ)においてただ1つのみを使用することができます。

リムーバブルメディアブートパスを使用する手順は、EFI ブートローダーを適切なパス・ファイル名にコピーするだけです。ファームウェアでこのフォールバックを使用する場合、設定済みのブートエントリから選択することはできなくなります。すなわち、( efibootmgr でリストアップされる) (U)EFI 経由のブートオプションは機能しないことになります。フォールバックにはあらゆる EFI ブートローダーを使用できますが、 GRUB や rEFInd のようにそれ自体がブートオプションから選択する機能を持つブートマネージャを使用するのがよいでしょう。x64(amd64) 用の上述の例:

systemd に含まれているブートローダー systemd-boot (かつての Gummiboot) は自動的に リムーバブルメディアブートパス へインストールされます。 boot USE フラグが有効な状態で sys-apps/systemd を更新した際には、再度 bootctl を実行してブートローダーファイルも更新する必要があります。

関連項目

• 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 スタブカーネル、つまり、UEFI から直接実行可能なカーネルについて記載します。
• efibootmgr — UEFI ブートエントリを管理するためのツールです。
• REFInd — rEFIt からフォークした後継の EFI および UEFI プラットフォーム向けブートマネージャ

参照