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 87% complete.
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)

特徴

作成方法については、ハンドブックを参照してください。

partedsys-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

gdisksys-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 などによって] 場合や、マウントポイントのディレクトリが空でない場合はできません。ESPXBOOTLDR の両方が存在する場合は、/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 を使用することもできます。

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

関連項目

参照