「EFI システムパーティション」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(同期)
23行目: 23行目:
   
 
* ディスクのパーティションテーブル：パーティションテーブルが [[GPT]] の場合は {{ic|Disklabel type: gpt}} を、[[MBR]] の場合は {{ic|Disklabel type: dos}} を示します。
  
* ディスクのパーティションテーブル：パーティションテーブルが [[GPT]] の場合は {{ic|Disklabel type: gpt}} を、[[MBR]] の場合は {{ic|Disklabel type: dos}} を示します。
  +
* ディスク上のパーティションのリスト：EFIシステムパーティションは通常100MiB以上の大きさで、タイプは {{ic|EFI System}} または {{ic|EFI (FAT-12/16/32)}} になっています。これが ESP であることを確認するには、ESP を[[マウント]]し、{{ic|EFI}} という名前のディレクトリがあるかどうかをチェックします。
   
  +
{{Tip|FAT12、FAT16、FAT32のいずれかのファイルシステムかどうかを調べるには、[[FAT#どの FAT かを調べる]] に従ってください。}}
−
* ディスク上のパーティションのリスト：EFIシステムパーティションは通常100MiB以上の大きさで、タイプは {{ic|EFI System}} または {{ic|EFI (FAT-12/16/32)}} になっています。これが ESP であることを確認するには、ESP をマウントし、{{ic|EFI}} という名前のディレクトリがあるかどうかをチェックします。
  
   
  +
{{Warning|デュアルブートする場合、ESPを再フォーマットすることは避けてください。他のオペレーティングシステムの起動に必要なファイルが含まれている可能性があるからです。}}
−
{{Tip|FAT12、FAT16、FAT32のいずれかのファイルシステムかどうかを調べるには、[[FAT#どの FAT か調べる]] に従ってください。}}
  
−  
−
{{Warning|デュアルブートする場合、ESPを再フォーマットすることは避けてください。}}
  
   
 
既存の EFI システムパーティションが見つかった場合は、[[#パーティションのマウント]]に進んでください。見つからなかった場合はパーティションを作成する必要があります。[[#パーティションの作成]]に進んでください。
  
既存の EFI システムパーティションが見つかった場合は、[[#パーティションのマウント]]に進んでください。見つからなかった場合はパーティションを作成する必要があります。[[#パーティションの作成]]に進んでください。
36行目: 35行目:
 
以下のセクションでは EFI System Partition (ESP) を作成する方法を説明しています。
  
以下のセクションでは EFI System Partition (ESP) を作成する方法を説明しています。
   
  +
{{Warning|EFI システムパーティションはディスクのメインパーティションテーブル上の物理パーティションでなければなりません。LVM やソフトウェア RAID などではいけません。}}
−
{{Note|UEFI ファームウェアによっては UEFI-MBR ブートができないため UEFI ブートでは出来るだけ [[GPT]] を使うことが推奨されます。}}
  
   
  +
ESP のサイズは、起動に必要なファイルとブートローダを格納するために十分な大きさである必要があります。
−
ESP の容量は 512 MiB にすることが推奨されていますが他のサイズでも問題ありません [http://www.rodsbooks.com/efi-bootloaders/principles.html]。
  
   
  +
他のオペレーティングシステムとの相互運用上の問題を回避するには[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions#diskpartitionrules][https://superuser.com/questions/1310927/what-is-the-absolute-minimum-size-a-uefi-partition-can-be/1310938]、ESP は少なくとも 300 MiB にすることが推奨されます。初期の/バグのある UEFI 実装では、ESP は少なくとも 512 MiB が必要かもしれません。[https://www.rodsbooks.com/efi-bootloaders/principles.html] これらが問題とならない場合、パーティションのサイズは 2 MiB まで小さくできます。この場合、ブートローダ以外は格納できません。
−
Microsoft のドキュメントには ESP の容量について説明があります: Advanced Format 4K Native (4-KB-per-sector) のドライブでは、FAT32 ファイルフォーマットの制限によって、最小容量は 256 MiB となります。FAT32 のドライブの最小パーティションサイズはセクターサイズ (4KB) x 65527 = 256 MiB と計算されます。Advanced Format 512e ドライブはセクターサイズが 512 バイトだとエミュレートされているのでこの制限を受けません。512 バイト x 65527 = 32 MB、これはパーティションの最小容量 100 MB よりも少ない値です。参照: [https://technet.microsoft.com/en-us/library/hh824839.aspx#DiskPartitionRules]。
  
   
 
=== GPT でパーティションされたディスク ===
  
=== GPT でパーティションされたディスク ===
   
  +
[[GPT|GUID パーティションテーブル]]上の EFI システムパーティションは[[Wikipedia:GUID Partition Table#Partition type GUIDs|パーティションタイプ GUID]] {{ic|C12A7328-F81F-11D2-BA4B-00A0C93EC93B}} で識別されます。
−
GPT でパーティションされたディスクに ESP を作成する場合、以下の方法のどちらかを使って下さい:
  
   
  +
GPT でパーティションされたディスクに ESP を作成する場合、以下の方法の'''一つ'''を使って下さい:
−
* [[fdisk|fdisk/gdisk]]: パーティションタイプ EFI System のパーティションを作成してください (''fdisk'' では {{ic|EFI System}} ですが ''gdisk'' では {{ic|EF00}} になります)。それから[[#パーティションのフォーマット|パーティションをフォーマット]]してください。
  
  +
−
* [[GNU Parted]]: Parted では FAT32 パーティションを作成してから {{ic|boot}} フラグを設定してください ({{ic|legacy_boot}} フラグではありません)。それから[[#パーティションのフォーマット|パーティションをフォーマット]]してください。
  
  +
* [[fdisk]]: パーティションタイプ {{ic|EFI System}} のパーティションを作成してください。
  +
* [[gdisk]]: パーティションタイプ {{ic|EF00}} のパーティションを作成してください。
  +
* [[GNU Parted]]: ファイルシステム {{ic|fat32}} のパーティションを作成し、{{ic|esp}} フラグをセットしてください。
  +
  +
パーティション作成後、ファイルシステムでフォーマットする必要があります。以下の [[#パーティションのマウント]] セクションに従ってください。
   
 
=== MBR でパーティションされたディスク ===
  
=== MBR でパーティションされたディスク ===
   
  +
{{Note|
−
fdisk を使ってパーティションタイプ ''EFI System'' のパーティションを作成し、[[#パーティションのフォーマット|パーティションをフォーマット]]してください。
  
  +
* [[Windows と Arch のデュアルブート|Windows Setup]] によりサポートされていないため一部のファームウェアは UEFI/MBR の起動をサポートしていないかもしれないので、[[GPT]] を使うことが推奨されます。
  +
* ''bootctl'' は MBR でパーティショニングされたディスクへの [[systemd-boot]] のインストールをサポートしていません; [https://github.com/systemd/systemd/issues/1125 systemd issue 1125] を参照してください。
  +
  +
一般的な GPT の利点は [[パーティショニング#GPT か MBR の選択]] を参照してください。
  +
}}
  +
  +
[[Master Boot Record]] パーティションテーブル上の EFI システムパーティションは [[Wikipedia:Partition type|パーティションタイプ ID]] {{ic|EF}} により識別されます。
  +
  +
MBR でパーティションされたディスクに ESP を作成する場合、以下の方法の'''一つ'''を使って下さい:
  +
  +
* [[fdisk]]: パーティションタイプ {{ic|EFI (FAT-12/16/32)}} のプライマリパーティションを作成してください。
  +
* [[GNU Parted]]: ファイルシステム {{ic|fat32}} のプライマリパーティションを作成し、{{ic|esp}} フラグをセットしてください。
  +
  +
パーティション作成後、ファイルシステムでフォーマットする必要があります。以下の [[#パーティションのマウント]] セクションに従ってください。
   
 
== パーティションのフォーマット ==
  
== パーティションのフォーマット ==
   
  +
UEFI 仕様は FAT12、FAT16、FAT32 ファイルシステムのサポートを義務付けています([https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf#G17.1019485 UEFI specification version 2.9, section 13.3.1.1] を参照)。しかし、準拠したベンダーは任意で追加のファイルシステムをサポートできます。例えば、Apple [[Mac]] のファームウェアは HFS+ ファイルシステムをサポートします。
−
ESP を作成したら、FAT32 で[[ファイルシステム#デバイスのフォーマット|フォーマット]]します:
  
   
  +
他のオペレーティングシステムとの潜在的な問題を回避するために、また UEFI 仕様では UEFI は「システムパーティションに FAT32、リームバブルメディアに FAT12 と FAT16 の使用を包含する」[https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf#G17.1345080]とあるので、[[FAT32]] を使用することが推奨されます。{{Pkg|dosfstools}} の {{man|8|mkfs.fat}} ユーティリティを使用してください:
−
# mkfs.fat -F32 /dev/sd''xY''
  
   
  +
# mkfs.fat -F 32 /dev/sd''xY''
−
上記の GNU Parted を使用した場合、既にフォーマットされているはずです。
  
   
−
{{ic|WARNING: Not enough clusters for a 32 bit FAT!}} というエラーが表示される場合、{{ic|mkfs.fat -s2 -F32 ...}} あるいは {{ic|-s1}} を使ってクラスタのサイズを減らして下さい。エラーを放置すると UEFI からパーティションを読み取れなくなる可能性があります。
 +
{{ic|WARNING: Not enough clusters for a 32 bit FAT!}} というメッセージが発生した場合、{{ic|mkfs.fat -s2 -F32 ...}} や {{ic|-s1}} でクラスタのサイズを減らしてください。さもないと、パーティションは UEFI によって読み込めません。サポートされるクラスタサイズは {{man|8|mkfs.fat}} を見てください。
  +
  +
32 MiB よりも小さいパーティションでは、FAT32 を使うことはできません。この場合、FAT16 か FAT12 でフォーマットしてください。例えば、2 MiB の ESP は FAT12 しかサポートできません:
  +
  +
# mkfs.fat -F 12 /dev/sd''xY''
   
 
== パーティションのマウント ==
  
== パーティションのマウント ==
   
−
[[EFISTUB]] の場合、カーネルと initramfs のファイルは EFI System Partition に保存する必要があります。また、EFISTUB ブートでは {{ic|/boot}} パーティションを別に作らないで ESP を {{ic|/boot}} パーティションとして使うことでシンプルにすることも可能です。その場合、上記のように EFI システムパーティションを作成・フォーマットした後、{{ic|/boot}} に[[マウント]]してください。
 +
システムの起動に成功するには、カーネル、initramfs ファイル、そして殆どの場合プロセッサの[[マイクロコード]]は、[[ブートローダー]]か UEFI それ自体からアクセスできる必要があります。なので、セットアップをシンプルにしたい場合、EFI システムパーティションのマウントポイントはブートローダの選択により制限されます。
  +
  +
=== 典型的なマウントポイント ===
  +
  +
EFI システムパーティションのマウントにおける最もシンプルなシナリオは:
  +
  +
* ESP を {{ic|/efi}} に[[マウント]]し、他のどこか(典型的には [[パーティショニング#/boot|/boot]])にあるカーネルと initramfs にアクセスできる[[ブートローダー]]を使う。ブートローダの要件と能力に関する情報は [[Arch ブートプロセス#ブートローダー]] を見てください。
  +
* ESP を {{ic|/boot}} に[[マウント]]する。UEFI から [[EFISTUB]] カーネルを直接起動したり [[systemd-boot]] のようなブートマネージャから起動したりする際にこの方法は推奨されます。
  +
* ESP を {{ic|/efi}} に[[マウント]]し、追加で "Extended Boot Loader Partition" (XBOOTLDR)を {{ic|/boot}} にマウントする。これは、以前作成した ESP が小さすぎて複数のブートローダやカーネルが入り切らないが ESP を簡単にリサイズできない場合に役に立ちます([[デュアルブート]]するために Windows のあとに Linux をインストールした場合など)。この方法は、少なくとも [[systemd-boot#XBOOTLDR を使用したインストール|systemd-boot]] によってサポートされています。
  +
  +
{{Tip|
  +
* {{ic|/efi}} は以前よく使われていた(現在も他の Linux ディストリビューションで使われているでしょう) ESP マウントポイント {{ic|/boot/efi}} の置き換えです[https://github.com/systemd/systemd/pull/3757#issuecomment-234290236]。
  +
* {{ic|/efi}} ディレクトリはデフォルトでは存在しません。このディレクトリに ESP をマウントする前に、まず {{man|1|mkdir}} で作成する必要があります。
  +
}}
  +
  +
=== 代替のマウントポイント ===
  +
  +
[[#典型的なマウントポイント]] のシンプルな方法を使わない場合、ブートファイルを ESP にコピーする必要があります(以後、ESP は {{ic|''esp''}} と表記します)。
  +
  +
# mkdir -p ''esp''/EFI/arch
  +
# cp -a /boot/vmlinuz-linux ''esp''/EFI/arch/
  +
# cp -a /boot/initramfs-linux.img ''esp''/EFI/arch/
  +
# cp -a /boot/initramfs-linux-fallback.img ''esp''/EFI/arch/
  +
  +
{{Note|[[マイクロコード]]もブートエントリの場所にコピーする必要があります。}}
  +
  +
さらに、今後のカーネルアップデートの際に ESP 上のファイルを最新に保つ必要があります。これに失敗するとシステムが起動不能になる可能性があります。以下のセクションでは、これを自動化する方法をいくつか説明しています。
  +
  +
{{Note|ESP が {{ic|/boot}} にマウントされていない場合、[[fstab#systemd による自動マウント|systemd による自動マウントメカニズム]](そして {{man|8|systemd-gpt-auto-generator}})に頼らないようにしてください。システムやカーネルのアップデートの前に必ず ESP を手動でマウントしてください。さもないと、アップデート後に ESP をマウントできなくなり、現在実行中のカーネルから締め出されて ESP 上のカーネルのコピーをアップデートできなくなる場合があります。
  +
  +
あるいは、[[カーネルモジュール#systemd により自動モジュールロード|必要なカーネルモジュールを起動時にプリロード]]してください。例えば:
  +
  +
{{hc|/etc/modules-load.d/vfat.conf|
  +
vfat
  +
nls_cp437
  +
nls_ascii
  +
}}
  +
  +
}}
  +
  +
==== バインドマウントを使う ====
  +
  +
ESP を {{ic|/boot}} にマウントする代わりに、バインド[[マウント]]を使うことで ESP のディレクトリを {{ic|/boot}} にマウントすることができます ({{ic|mount(8)}} を参照)。これによって ESP を自由に扱えるようにしつつ [[pacman]] が直接カーネルを更新できるようにすることができます。ファイルをコピーする他の方法よりもずっとシンプルな方法になります。
  +
  +
{{Note|1=バインドマウントを利用するには FAT32 に対応する[[FAT#カーネルの設定|カーネル]]と[[ブートローダー]]が必要です。通常の Arch のインストールでは問題になりませんが、他のディストリビューションでは問題になることがあります (つまり {{ic|/boot/}} にシンボリックリンクを必要とするディストリビューション)。フォーラムの[https://bbs.archlinux.org/viewtopic.php?pid=1331867#p1331867 この投稿] を見て下さい。}}
  +
  +
[[#代替のマウントポイント]]に書かれているように、ESP のディレクトリに全てのブートファイルをコピーしますが、ESP は {{ic|/boot}} の'''外'''にマウントします。そしてディレクトリをバインドマウントします:
  +
  +
# mount --bind ''esp''/EFI/arch /boot
  +
  +
これがうまく行ったことを確認したら、[[fstab]] を編集して永続化させます:
  +
  +
{{hc|/etc/fstab|
  +
''esp''/EFI/arch /boot none defaults,bind 0 0
  +
}}
  +
  +
==== systemd を使う ====
  +
  +
[[systemd]] はイベントトリガーのタスクを特徴としています。この場合特に、パス内の変更を検出する機能は、{{ic|/boot/}} 内で EFISTUB カーネルと initramfs ファイルがアップデートされたときにそれらを同期するのに使用されます。変更を監視するファイルは {{ic|initramfs-linux-fallback.img}} です。なぜなら、このファイルは mkinitcpio により最後にビルドされるからです。なので、このファイルを監視すれば、コピーを開始する前にすべてのファイルがビルド済みであることを保証できます。作成する ''systemd'' パスとサービスファイルは:
  +
  +
{{hc|/etc/systemd/system/efistub-update.path|2=
  +
[Unit]
  +
Description=Copy EFISTUB Kernel to EFI system partition
  +
  +
[Path]
  +
PathChanged=/boot/initramfs-linux-fallback.img
  +
  +
[Install]
  +
WantedBy=multi-user.target
  +
WantedBy=system-update.target
  +
}}
  +
  +
{{hc|/etc/systemd/system/efistub-update.service|2=
  +
[Unit]
  +
Description=Copy EFISTUB Kernel to EFI system partition
  +
  +
[Service]
  +
Type=oneshot
  +
ExecStart=/usr/bin/cp -af /boot/vmlinuz-linux ''esp''/EFI/arch/
  +
ExecStart=/usr/bin/cp -af /boot/initramfs-linux.img ''esp''/EFI/arch/
  +
ExecStart=/usr/bin/cp -af /boot/initramfs-linux-fallback.img ''esp''/EFI/arch/
  +
}}
  +
  +
作成後、{{ic|efistub-update.path}} を[[有効化]]・[[起動]]してください。
  +
  +
{{Tip|自身のキーを用いる[[セキュアブート]]の場合、{{Pkg|sbsigntools}} を使ってイメージに署名するようサービスを設定できます:
  +
  +
{{bc|1=ExecStart=/usr/bin/sbsign --key ''/path/to/db.key'' --cert ''/path/to/db.crt'' --output ''esp''/EFI/arch/vmlinuz-linux /boot/vmlinuz-linux}}
  +
  +
}}
  +
  +
==== ファイルシステムイベントを使う ====
  +
  +
[[自動起動#ファイルシステムのイベントに関して|ファイルシステムイベント]]は、カーネルのアップデート後に EFISTUB カーネルを同期させるスクリプトを実行するのに利用できます。以下は [[incron]] を使った例です。
  +
  +
{{hc|/usr/local/bin/efistub-update|
  +
#!/bin/sh
  +
cp -af /boot/vmlinuz-linux ''esp''/EFI/arch/
  +
cp -af /boot/initramfs-linux.img ''esp''/EFI/arch/
  +
cp -af /boot/initramfs-linux-fallback.img ''esp''/EFI/arch/
  +
}}
  +
  +
{{Note|最初のパラメータ {{ic|/boot/initramfs-linux-fallback.img}} は監視するファイルです。2つ目のパラメータ {{ic|IN_CLOSE_WRITE}} は監視するアクションです。3つ目のパラメータ {{ic|/usr/local/bin/efistub-update}} は実行するスクリプトです。}}
  +
  +
{{hc|/etc/incron.d/efistub-update.conf|
  +
/boot/initramfs-linux-fallback.img IN_CLOSE_WRITE /usr/local/bin/efistub-update
  +
}}
  +
  +
この方法を使うには、{{ic|incrond.service}} を[[有効化]]してください。
  +
  +
==== mkinitcpio フックを使う====
  +
  +
Mkinitcpio はシステムレベルのデーモンを必要としないフックを生成できます。コピーする前に {{ic|vmlinuz}}、{{ic|initramfs-linux.img}}、{{ic|initramfs-linux-fallback.img}} の生成を待機するバックグラウンドプロセスを生成します。
  +
  +
{{ic|/etc/mkinitcpio.conf}} 内のフックのリストに {{ic|efistub-update}} を追加してください。
  +
  +
{{hc|/etc/initcpio/install/efistub-update|2=
  +
#!/usr/bin/env bash
  +
build() {
  +
/usr/local/bin/efistub-copy $$ &
  +
}
  +
  +
help() {
  +
cat <<HELPEOF
  +
This hook waits for mkinitcpio to finish and copies the finished ramdisk and kernel to the ESP
  +
HELPEOF
  +
}
  +
}}
  +
  +
{{hc|/usr/local/bin/efistub-copy|
  +
#!/bin/sh
  +
  +
if [ "$1" -gt 0 ]
  +
then
  +
while [ -e /proc/"$1" ]
  +
do
  +
sleep .5
  +
done
  +
fi
  +
  +
rsync -a /boot/ ''esp''/
  +
  +
echo "Synced /boot with ESP"
  +
}}
  +
  +
==== mkinitcpio プリセットを使う ====
  +
  +
{{ic|/etc/mkinitcpio.d/}} 内のプリセットはシェルスクリプトをサポートするので、カーネルと initramfs は、そのプリセットを編集するだけでコピーできます。
  +
  +
===== 上記の mkinitcpio フックを置き換える =====
  +
  +
{{ic|/etc/mkinitcpio.d/linux.preset}} ファイルを編集してください:
  +
  +
{{hc|/etc/mkinitcpio.d/linux.preset|2=
  +
# mkinitcpio preset file for the 'linux' package
  +
  +
# Directory to copy the kernel, the initramfs...
  +
ESP_DIR="''esp''/EFI/arch"
  +
  +
ALL_config="/etc/mkinitcpio.conf"
  +
ALL_kver="${ESP_DIR}/vmlinuz-linux"
  +
cp -af /boot/vmlinuz-linux "${ESP_DIR}/"
  +
<nowiki>[[ -e /boot/intel-ucode.img ]] && cp -af /boot/intel-ucode.img "${ESP_DIR}/"
  +
[[ -e /boot/amd-ucode.img ]] && cp -af /boot/amd-ucode.img "${ESP_DIR}/"</nowiki>
  +
  +
PRESETS=('default' 'fallback')
  +
  +
#default_config="/etc/mkinitcpio.conf"
  +
default_image="${ESP_DIR}/initramfs-linux.img"
  +
default_options=""
  +
  +
#fallback_config="/etc/mkinitcpio.conf"
  +
fallback_image="${ESP_DIR}/initramfs-linux-fallback.img"
  +
fallback_options="-S autodetect"
  +
}}
  +
  +
テストするには以下を実行してください:
  +
  +
# rm /boot/initramfs-linux-fallback.img /boot/initramfs-linux.img
  +
# mkinitcpio -p linux
  +
  +
===== もう一つの例 =====
  +
  +
{{hc|/etc/mkinitcpio.d/linux.preset|2=
  +
ESP_DIR="''esp''/EFI/arch"
  +
cp -f "/boot/vmlinuz-linux$suffix" "$ESP_DIR/"
  +
ALL_config="/etc/mkinitcpio.conf"
  +
ALL_kver="$ESP_DIR/vmlinuz-linux$suffix"
  +
PRESETS=('default')
  +
default_config="/etc/mkinitcpio.conf"
  +
default_image="$ESP_DIR/initramfs-linux$suffix.img"
  +
}}
  +
  +
{{hc|/etc/mkinitcpio.d/linux-zen.preset|2=
  +
suffix='-zen'
  +
source /etc/mkinitcpio.d/linux.preset
  +
}}
  +
  +
==== pacman フックを使う ====
  +
  +
最後の選択肢は、トランザクションの最後に実行する [[pacman フック]] です。
  +
  +
最初のファイルは、関連するファイルを監視するフックで、ファイルが前のトランザクションで変更された場合に実行されます。
  +
  +
{{hc|/etc/pacman.d/hooks/999-kernel-efi-copy.hook|2=
  +
[Trigger]
  +
Type = Path
  +
Operation = Install
  +
Operation = Upgrade
  +
Target = usr/lib/modules/*/vmlinuz
  +
Target = usr/lib/initcpio/*
  +
Target = boot/*-ucode.img
  +
  +
[Action]
  +
Description = Copying linux and initramfs to EFI directory...
  +
When = PostTransaction
  +
Exec = /usr/local/bin/kernel-efi-copy.sh
  +
}}
  +
  +
2つ目のファイルはスクリプト自体です。ファイルを作成し、[[実行可能属性]]を付与してください:
  +
  +
{{hc|/usr/local/bin/kernel-efi-copy.sh|2=
  +
#!/bin/sh
  +
#
  +
# Copy kernel and initramfs images to EFI directory
  +
#
   
  +
ESP_DIR="''esp''/EFI/arch"
−
[[#バインドマウントを使う]]も参照。
  
   
  +
for file in /boot/vmlinuz*
−
== 既知の問題 ==
  
  +
do
  +
cp -af "$file" "$ESP_DIR/$(basename "$file").efi"
  +
[ $? -ne 0 ] && exit 1
  +
done
   
  +
for file in /boot/initramfs*
−
=== RAID 上に ESP を配置 ===
  
  +
do
−
ESP を RAID1 アレイに置くことも可能ですが、データが破損する危険性があり、また、ESP を作成する際に様々な注意をする必要があります。詳しくは [https://bbs.archlinux.org/viewtopic.php?pid=1398710#p1398710] や [https://bbs.archlinux.org/viewtopic.php?pid=1390741#p1390741] を見て下さい。
  
  +
cp -af "$file" "$ESP_DIR/"
  +
[ $? -ne 0 ] && exit 1
  +
done
   
  +
[ -e /boot/intel-ucode.img ] && cp -af /boot/intel-ucode.img "$ESP_DIR/"
−
== ヒントとテクニック ==
  
  +
[ -e /boot/amd-ucode.img ] && cp -af /boot/amd-ucode.img "$ESP_DIR/"
   
  +
exit 0
−
=== バインドマウントを使う ===
  
  +
}}
   
  +
== トラブルシューティング ==
−
ESP を {{ic|/boot}} にマウントする代わりに、バインドマウントを使うことで ESP のディレクトリを {{ic|/boot}} にマウントすることができます ({{ic|mount(8)}} を参照)。これによって ESP を自由に扱えるようにしつつ pacman が直接カーネルを更新できるようにすることができます。ファイルをコピーする他の方法よりもずっとシンプルな方法になります。
  
   
  +
=== ソフトウェア RAID1 上の ESP ===
−
{{Note|1=バインドマウントを利用するには FAT32 に対応するカーネルとブートローダーが必要です。通常の Arch のインストールでは問題になりませんが、他のディストリビューションでは問題になることがあります (つまり {{ic|/boot}} にシンボリックリンクを必要とするディストリビューション)。フォーラムの[https://bbs.archlinux.org/viewtopic.php?pid=1331867#p1331867 この投稿] を見て下さい。}}
  
   
  +
ESP を RAID1 アレイに置くことも可能ですが、データが破損する危険性があり、また、ESP を作成する際に様々な注意をする必要があります。詳細は [https://bbs.archlinux.org/viewtopic.php?pid=1398710#p1398710] と [https://bbs.archlinux.org/viewtopic.php?pid=1390741#p1390741] を、解決策付きの詳細なガイドは [https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/ UEFI booting and RAID1] を見てください。
−
[[EFISTUB#カーネルと initramfs を ESP にコピーする]]に書かれているように、ESP のディレクトリに全てのブートファイルをコピーしますが、ESP は {{ic|/boot}} の外にマウントします (例: {{ic|/esp}})。そしてディレクトリをバインドマウントします:
  
   
  +
鍵となる部分は、RAID メタデータをパーティションの最後に保持するために {{ic|--metadata 1.0}} を使うことです。さもないと、ファームウェアがアクセスできなくなります:
−
# mount --bind /esp/EFI/arch/ /boot
  
   
  +
# mdadm --create --verbose --level=1 '''--metadata=1.0''' --raid-devices=2 /dev/md/ESP /dev/sda''X'' /dev/sdb''Y''
−
ファイルが {{ic|/boot}} に現れるようにしたい場合、[[fstab]] を編集して永続化させます:
  
   
  +
=== ファームウェアから EFI ディレクトリが見えない ===
−
{{hc|/etc/fstab|<nowiki>
  
−
/esp/EFI/arch /boot none defaults,bind 0 0
  
−
</nowiki>}}
  
   
  +
FAT ファイルシステムに[[永続的なブロックデバイスの命名#by-label|ボリューム名(例: ファイルシステムラベル)]]をつける場合、{{ic|EFI}} 以外の名前にしてください。(ボリューム名が EFI のディレクトリ名と一致するので)一部のファームウェアでバグを引き起こす可能性があります。その結果、ファームウェアが EFI ディレクトリが存在しないかのように振る舞います。
−
{{Warning|この方法を使って起動するには {{ic|1=root=''system_root''}} [[カーネルパラメータ#パラメータ一覧|カーネルパラメータ]]を使う必要があります。}}
  
   
 
== 参照 ==
  
== 参照 ==
   
−
* [http://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/ The EFI System Partition and the Default Boot Behavior]
 +
* [https://blog.uncooperative.org/uefi/linux/shim/efi%20system%20partition/2014/02/06/the-efi-system-partition.html The EFI system partition and the default boot behavior]
  +
* [https://ramsdenj.com/2016/04/15/multi-boot-linux-with-one-boot-partition.html Multi Boot Linux With One Boot Partition | John Ramsden]

2022年7月11日 (月) 13:32時点における版

関連記事

EFI System Partition (ESP とも呼ばれます) は UEFI ファームウェアによって起動される EFI ブートローダ、アプリケーション、ドライバの格納場所として機能する OS に依存しないパーティションです。UEFI ブートには必須です。

既存のパーティションの確認

例えば Windows 10 のようなオペレーティングシステムがインストールされている UEFI 対応のコンピュータに Arch Linux をインストールする場合、既に EFI システムパーティションがある可能性が非常に高いと言えます。

ディスクパーティションスキームとシステムパーティションを調べるには、起動したいディスクの root で fdisk を使用します。 

# fdisk -l /dev/sdx

このコマンドは以下を返します。

  • ディスクのパーティションテーブル：パーティションテーブルが GPT の場合は Disklabel type: gpt を、MBR の場合は Disklabel type: dos を示します。
  • ディスク上のパーティションのリスト：EFIシステムパーティションは通常100MiB以上の大きさで、タイプは EFI System または EFI (FAT-12/16/32) になっています。これが ESP であることを確認するには、ESP をマウントし、EFI という名前のディレクトリがあるかどうかをチェックします。
ヒント: FAT12、FAT16、FAT32のいずれかのファイルシステムかどうかを調べるには、FAT#どの FAT かを調べる に従ってください。
警告: デュアルブートする場合、ESPを再フォーマットすることは避けてください。他のオペレーティングシステムの起動に必要なファイルが含まれている可能性があるからです。

既存の EFI システムパーティションが見つかった場合は、#パーティションのマウントに進んでください。見つからなかった場合はパーティションを作成する必要があります。#パーティションの作成に進んでください。

パーティションの作成

以下のセクションでは EFI System Partition (ESP) を作成する方法を説明しています。

警告: EFI システムパーティションはディスクのメインパーティションテーブル上の物理パーティションでなければなりません。LVM やソフトウェア RAID などではいけません。

ESP のサイズは、起動に必要なファイルとブートローダを格納するために十分な大きさである必要があります。

他のオペレーティングシステムとの相互運用上の問題を回避するには[1][2]、ESP は少なくとも 300 MiB にすることが推奨されます。初期の/バグのある UEFI 実装では、ESP は少なくとも 512 MiB が必要かもしれません。[3] これらが問題とならない場合、パーティションのサイズは 2 MiB まで小さくできます。この場合、ブートローダ以外は格納できません。

GPT でパーティションされたディスク

GUID パーティションテーブル上の EFI システムパーティションはパーティションタイプ GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B で識別されます。

GPT でパーティションされたディスクに ESP を作成する場合、以下の方法の一つを使って下さい:

  • fdisk: パーティションタイプ EFI System のパーティションを作成してください。
  • gdisk: パーティションタイプ EF00 のパーティションを作成してください。
  • GNU Parted: ファイルシステム fat32 のパーティションを作成し、esp フラグをセットしてください。

パーティション作成後、ファイルシステムでフォーマットする必要があります。以下の #パーティションのマウント セクションに従ってください。

MBR でパーティションされたディスク

ノート:
  • Windows Setup によりサポートされていないため一部のファームウェアは UEFI/MBR の起動をサポートしていないかもしれないので、GPT を使うことが推奨されます。
  • bootctl は MBR でパーティショニングされたディスクへの systemd-boot のインストールをサポートしていません; systemd issue 1125 を参照してください。

一般的な GPT の利点は パーティショニング#GPT か MBR の選択 を参照してください。

Master Boot Record パーティションテーブル上の EFI システムパーティションは パーティションタイプ ID EF により識別されます。

MBR でパーティションされたディスクに ESP を作成する場合、以下の方法の一つを使って下さい:

  • fdisk: パーティションタイプ EFI (FAT-12/16/32) のプライマリパーティションを作成してください。
  • GNU Parted: ファイルシステム fat32 のプライマリパーティションを作成し、esp フラグをセットしてください。

パーティション作成後、ファイルシステムでフォーマットする必要があります。以下の #パーティションのマウント セクションに従ってください。

パーティションのフォーマット

UEFI 仕様は FAT12、FAT16、FAT32 ファイルシステムのサポートを義務付けています(UEFI specification version 2.9, section 13.3.1.1 を参照)。しかし、準拠したベンダーは任意で追加のファイルシステムをサポートできます。例えば、Apple Mac のファームウェアは HFS+ ファイルシステムをサポートします。

他のオペレーティングシステムとの潜在的な問題を回避するために、また UEFI 仕様では UEFI は「システムパーティションに FAT32、リームバブルメディアに FAT12 と FAT16 の使用を包含する」[4]とあるので、FAT32 を使用することが推奨されます。dosfstools の mkfs.fat(8) ユーティリティを使用してください: 

# mkfs.fat -F 32 /dev/sdxY

WARNING: Not enough clusters for a 32 bit FAT! というメッセージが発生した場合、mkfs.fat -s2 -F32 ... や -s1 でクラスタのサイズを減らしてください。さもないと、パーティションは UEFI によって読み込めません。サポートされるクラスタサイズは mkfs.fat(8) を見てください。

32 MiB よりも小さいパーティションでは、FAT32 を使うことはできません。この場合、FAT16 か FAT12 でフォーマットしてください。例えば、2 MiB の ESP は FAT12 しかサポートできません: 

# mkfs.fat -F 12 /dev/sdxY

パーティションのマウント

システムの起動に成功するには、カーネル、initramfs ファイル、そして殆どの場合プロセッサのマイクロコードは、ブートローダーか UEFI それ自体からアクセスできる必要があります。なので、セットアップをシンプルにしたい場合、EFI システムパーティションのマウントポイントはブートローダの選択により制限されます。

典型的なマウントポイント

EFI システムパーティションのマウントにおける最もシンプルなシナリオは:

  • ESP を /efi にマウントし、他のどこか(典型的には /boot)にあるカーネルと initramfs にアクセスできるブートローダーを使う。ブートローダの要件と能力に関する情報は Arch ブートプロセス#ブートローダー を見てください。
  • ESP を /boot にマウントする。UEFI から EFISTUB カーネルを直接起動したり systemd-boot のようなブートマネージャから起動したりする際にこの方法は推奨されます。
  • ESP を /efi にマウントし、追加で "Extended Boot Loader Partition" (XBOOTLDR)を /boot にマウントする。これは、以前作成した ESP が小さすぎて複数のブートローダやカーネルが入り切らないが ESP を簡単にリサイズできない場合に役に立ちます(デュアルブートするために Windows のあとに Linux をインストールした場合など)。この方法は、少なくとも systemd-boot によってサポートされています。
ヒント:
  • /efi は以前よく使われていた(現在も他の Linux ディストリビューションで使われているでしょう) ESP マウントポイント /boot/efi の置き換えです[5]。
  • /efi ディレクトリはデフォルトでは存在しません。このディレクトリに ESP をマウントする前に、まず mkdir(1) で作成する必要があります。

代替のマウントポイント

#典型的なマウントポイント のシンプルな方法を使わない場合、ブートファイルを ESP にコピーする必要があります(以後、ESP は esp と表記します)。 

# mkdir -p esp/EFI/arch
# cp -a /boot/vmlinuz-linux esp/EFI/arch/
# cp -a /boot/initramfs-linux.img esp/EFI/arch/
# cp -a /boot/initramfs-linux-fallback.img esp/EFI/arch/
ノート: マイクロコードもブートエントリの場所にコピーする必要があります。

さらに、今後のカーネルアップデートの際に ESP 上のファイルを最新に保つ必要があります。これに失敗するとシステムが起動不能になる可能性があります。以下のセクションでは、これを自動化する方法をいくつか説明しています。

ノート: ESP が /boot にマウントされていない場合、systemd による自動マウントメカニズム(そして systemd-gpt-auto-generator(8))に頼らないようにしてください。システムやカーネルのアップデートの前に必ず ESP を手動でマウントしてください。さもないと、アップデート後に ESP をマウントできなくなり、現在実行中のカーネルから締め出されて ESP 上のカーネルのコピーをアップデートできなくなる場合があります。

あるいは、必要なカーネルモジュールを起動時にプリロードしてください。例えば: 

/etc/modules-load.d/vfat.conf
vfat
nls_cp437
nls_ascii

バインドマウントを使う

ESP を /boot にマウントする代わりに、バインドマウントを使うことで ESP のディレクトリを /boot にマウントすることができます (mount(8) を参照)。これによって ESP を自由に扱えるようにしつつ pacman が直接カーネルを更新できるようにすることができます。ファイルをコピーする他の方法よりもずっとシンプルな方法になります。

ノート: バインドマウントを利用するには FAT32 に対応するカーネルとブートローダーが必要です。通常の Arch のインストールでは問題になりませんが、他のディストリビューションでは問題になることがあります (つまり /boot/ にシンボリックリンクを必要とするディストリビューション)。フォーラムのこの投稿 を見て下さい。

#代替のマウントポイントに書かれているように、ESP のディレクトリに全てのブートファイルをコピーしますが、ESP は /boot の外にマウントします。そしてディレクトリをバインドマウントします: 

# mount --bind esp/EFI/arch /boot

これがうまく行ったことを確認したら、fstab を編集して永続化させます: 

/etc/fstab
esp/EFI/arch /boot none defaults,bind 0 0

systemd を使う

systemd はイベントトリガーのタスクを特徴としています。この場合特に、パス内の変更を検出する機能は、/boot/ 内で EFISTUB カーネルと initramfs ファイルがアップデートされたときにそれらを同期するのに使用されます。変更を監視するファイルは initramfs-linux-fallback.img です。なぜなら、このファイルは mkinitcpio により最後にビルドされるからです。なので、このファイルを監視すれば、コピーを開始する前にすべてのファイルがビルド済みであることを保証できます。作成する systemd パスとサービスファイルは: 

/etc/systemd/system/efistub-update.path
[Unit]
Description=Copy EFISTUB Kernel to EFI system partition

[Path]
PathChanged=/boot/initramfs-linux-fallback.img

[Install]
WantedBy=multi-user.target
WantedBy=system-update.target
/etc/systemd/system/efistub-update.service
[Unit]
Description=Copy EFISTUB Kernel to EFI system partition

[Service]
Type=oneshot
ExecStart=/usr/bin/cp -af /boot/vmlinuz-linux esp/EFI/arch/
ExecStart=/usr/bin/cp -af /boot/initramfs-linux.img esp/EFI/arch/
ExecStart=/usr/bin/cp -af /boot/initramfs-linux-fallback.img esp/EFI/arch/

作成後、efistub-update.path を有効化・起動してください。

ヒント: 自身のキーを用いるセキュアブートの場合、sbsigntools を使ってイメージに署名するようサービスを設定できます: 
ExecStart=/usr/bin/sbsign --key /path/to/db.key --cert /path/to/db.crt --output esp/EFI/arch/vmlinuz-linux /boot/vmlinuz-linux

ファイルシステムイベントを使う

ファイルシステムイベントは、カーネルのアップデート後に EFISTUB カーネルを同期させるスクリプトを実行するのに利用できます。以下は incron を使った例です。 

/usr/local/bin/efistub-update
#!/bin/sh
cp -af /boot/vmlinuz-linux esp/EFI/arch/
cp -af /boot/initramfs-linux.img esp/EFI/arch/
cp -af /boot/initramfs-linux-fallback.img esp/EFI/arch/
ノート: 最初のパラメータ /boot/initramfs-linux-fallback.img は監視するファイルです。2つ目のパラメータ IN_CLOSE_WRITE は監視するアクションです。3つ目のパラメータ /usr/local/bin/efistub-update は実行するスクリプトです。
/etc/incron.d/efistub-update.conf
/boot/initramfs-linux-fallback.img IN_CLOSE_WRITE /usr/local/bin/efistub-update

この方法を使うには、incrond.service を有効化してください。

mkinitcpio フックを使う

Mkinitcpio はシステムレベルのデーモンを必要としないフックを生成できます。コピーする前に vmlinuz、initramfs-linux.img、initramfs-linux-fallback.img の生成を待機するバックグラウンドプロセスを生成します。

/etc/mkinitcpio.conf 内のフックのリストに efistub-update を追加してください。 

/etc/initcpio/install/efistub-update
#!/usr/bin/env bash
build() {
	/usr/local/bin/efistub-copy $$ &
}

help() {
	cat <<HELPEOF
This hook waits for mkinitcpio to finish and copies the finished ramdisk and kernel to the ESP
HELPEOF
}
/usr/local/bin/efistub-copy
#!/bin/sh

if [ "$1" -gt 0 ]
then
	while [ -e /proc/"$1" ]
	do
		sleep .5
	done
fi

rsync -a /boot/ esp/

echo "Synced /boot with ESP"

mkinitcpio プリセットを使う

/etc/mkinitcpio.d/ 内のプリセットはシェルスクリプトをサポートするので、カーネルと initramfs は、そのプリセットを編集するだけでコピーできます。

上記の mkinitcpio フックを置き換える

/etc/mkinitcpio.d/linux.preset ファイルを編集してください: 

/etc/mkinitcpio.d/linux.preset
# mkinitcpio preset file for the 'linux' package

# Directory to copy the kernel, the initramfs...
ESP_DIR="esp/EFI/arch"

ALL_config="/etc/mkinitcpio.conf"
ALL_kver="${ESP_DIR}/vmlinuz-linux"
cp -af /boot/vmlinuz-linux "${ESP_DIR}/"
[[ -e /boot/intel-ucode.img ]] && cp -af /boot/intel-ucode.img "${ESP_DIR}/"
[[ -e /boot/amd-ucode.img ]] && cp -af /boot/amd-ucode.img "${ESP_DIR}/"

PRESETS=('default' 'fallback')

#default_config="/etc/mkinitcpio.conf"
default_image="${ESP_DIR}/initramfs-linux.img"
default_options=""

#fallback_config="/etc/mkinitcpio.conf"
fallback_image="${ESP_DIR}/initramfs-linux-fallback.img"
fallback_options="-S autodetect"

テストするには以下を実行してください: 

# rm /boot/initramfs-linux-fallback.img /boot/initramfs-linux.img
# mkinitcpio -p linux
もう一つの例
/etc/mkinitcpio.d/linux.preset
ESP_DIR="esp/EFI/arch"
cp -f "/boot/vmlinuz-linux$suffix" "$ESP_DIR/"
ALL_config="/etc/mkinitcpio.conf"
ALL_kver="$ESP_DIR/vmlinuz-linux$suffix"
PRESETS=('default')
default_config="/etc/mkinitcpio.conf"
default_image="$ESP_DIR/initramfs-linux$suffix.img"
/etc/mkinitcpio.d/linux-zen.preset
suffix='-zen'
source /etc/mkinitcpio.d/linux.preset

pacman フックを使う

最後の選択肢は、トランザクションの最後に実行する pacman フック です。

最初のファイルは、関連するファイルを監視するフックで、ファイルが前のトランザクションで変更された場合に実行されます。 

/etc/pacman.d/hooks/999-kernel-efi-copy.hook
[Trigger]
Type = Path
Operation = Install
Operation = Upgrade
Target = usr/lib/modules/*/vmlinuz
Target = usr/lib/initcpio/*
Target = boot/*-ucode.img

[Action]
Description = Copying linux and initramfs to EFI directory...
When = PostTransaction
Exec = /usr/local/bin/kernel-efi-copy.sh

2つ目のファイルはスクリプト自体です。ファイルを作成し、実行可能属性を付与してください: 

/usr/local/bin/kernel-efi-copy.sh
#!/bin/sh
#
# Copy kernel and initramfs images to EFI directory
#

ESP_DIR="esp/EFI/arch"

for file in /boot/vmlinuz*
do
        cp -af "$file" "$ESP_DIR/$(basename "$file").efi"
        [ $? -ne 0 ] && exit 1
done

for file in /boot/initramfs*
do
        cp -af "$file" "$ESP_DIR/"
        [ $? -ne 0 ] && exit 1
done

[ -e /boot/intel-ucode.img ] && cp -af /boot/intel-ucode.img "$ESP_DIR/"
[ -e /boot/amd-ucode.img ] && cp -af /boot/amd-ucode.img "$ESP_DIR/"

exit 0

トラブルシューティング

ソフトウェア RAID1 上の ESP

ESP を RAID1 アレイに置くことも可能ですが、データが破損する危険性があり、また、ESP を作成する際に様々な注意をする必要があります。詳細は [6] と [7] を、解決策付きの詳細なガイドは UEFI booting and RAID1 を見てください。

鍵となる部分は、RAID メタデータをパーティションの最後に保持するために --metadata 1.0 を使うことです。さもないと、ファームウェアがアクセスできなくなります: 

# mdadm --create --verbose --level=1 --metadata=1.0 --raid-devices=2 /dev/md/ESP /dev/sdaX /dev/sdbY

ファームウェアから EFI ディレクトリが見えない

FAT ファイルシステムにボリューム名(例: ファイルシステムラベル)をつける場合、EFI 以外の名前にしてください。(ボリューム名が EFI のディレクトリ名と一致するので)一部のファームウェアでバグを引き起こす可能性があります。その結果、ファームウェアが EFI ディレクトリが存在しないかのように振る舞います。

参照

「https://wiki.archlinux.jp/index.php?title=EFI_システムパーティション&oldid=26356」から取得