EFI システムパーティション

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 100% complete.
Other languages:
Resources

EFI システムパーティション (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

FAT EFI パーティションをマウントするために、ISO8859-1 コードページも有効になっていなければなりません:

カーネル 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）は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 を使用していない場合):

ファイル /etc/fstabsystemd のための ESP のマウントポイントの設定
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.master'boot' ファイルを読み込むように autofs を構成する
/- /etc/autofs/auto.boot --timeout=600,sync,nodev

パス /boot および /efi へのアクセスを監視し、それらをオプション付きでデバイスからマウントするように、AutoFS に指示してください。

ファイル /etc/autofs/auto.bootESP マウントポイントを構成する
/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 を使用することもできます。

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

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

リムーバブルメディア

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

ほとんどの (U)EFI 実装では、リムーバブルメディアブートパスを内部ドライブでフォールバックとして使用することができます。[4] これは仕様には反していますが、ほとんどのシステムでフォールバックとして使用されているのみならず、バグのある (U)EFI を備えたシステムでは使用できる唯一のブートローダでもあります。そうした標準化されたブートパスとファイル名によるフォールバックブートローダーは、特定のシステム(アーキテクチャ)においてただ1つのみを使用することができます。

アーキテクチャ 略称 ファイル名 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
メモ
リムーバブルメディアからブートするには、ファームウェアがサポートされているドライブから互換性のあるハードウェアを見つけられる必要があります。多くのファームウェアではそうですが、(U)EFI は(かつて "BIOS Boot Specification" や BBS として知られていた)ブートの選択肢を表示するためのホットキーを提供しており、そうでない場合、(U)EFI は設定されているデフォルトのブートエントリを使用します。しかしながら、バグのある (U)EFI は内部ドライブについても リムーバブルブートパスをデフォルトとして使用します。

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

root #cp /efi/EFI/Grub/grubx64.efi /efi/EFI/boot/bootx64.efi
メモ
Unix は伝統的に大文字と小文字を厳格に区別するのに対し、EFI System Partition (ESP) の FAT ファイルシステムは大文字と小文字の違いを保持するものの、厳格な区別はしません。Linux カーネルの vfat では、デフォルトで大文字と小文字を区別しない (relaxed を意味する check=r マウントオプション) ため、[5] ESP では先ほどのコマンドは常に動作します。VFAT を 大文字と小文字の区別について strict としてマウントした場合に限り、/efi/EFI/BOOT や /efi/EFI/Boot (これらは大文字と小文字を厳格に区別すると別のディレクトリとなります)のように既存のファイルやディレクトリが大文字を使用している可能性があるため、/efi/EFI/boot/bootx64.efi というパスは動作しないかもしれません; これは bootx64.efi についても同様です。tree -L 3 /efi (ESP が /efi にマウントされている場合)を実行すると各システムで使用されている名前が表示されます。前述のコマンドはこれに合わせて変更する必要があります。
重要
フォールバックブートローダーは自動的に更新されません!　例えば GRUB が(セキュリティ修正が含まれるようなバージョンアップデート後などに)再インストールされるたびに、再度フォールバックブートパスにコピーして以前のバージョンを上書き(更新)する必要があります!

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

root #bootctl update

関連項目

参照

  1. ↑ https://wiki.debian.org/UEFI#Force_grub-efi_installation_to_the_removable_media_path
  2. ↑ https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/boot-to-uefi-mode-or-legacy-bios-mode
  3. ↑ UEFI 2.10 Specification, 3.5.1.1 Removable Media Boot Behavior
  4. ↑ Debian Wiki – UEFI: Force grub-efi installation to the removable media path
  5. ↑ https://www.kernel.org/doc/html/v6.0/filesystems/vfat.html
Retrieved from "https://wiki.gentoo.org/index.php?title=EFI_System_Partition/ja&oldid=1303716"