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

提供: ArchWiki
ナビゲーションに移動 検索に移動
(→‎ソフトウェア RAID1 上の ESP: セクション名を変更)
 
(同じ利用者による、間の7版が非表示)
39行目: 39行目:
 
ESP のサイズは、起動に必要なファイルとブートローダを格納するために十分な大きさである必要があります。
  
ESP のサイズは、起動に必要なファイルとブートローダを格納するために十分な大きさである必要があります。
   
  +
複数のカーネルや複数の unified カーネルイメージ、ブートローダー、ファームウェアのアップデートファイル、他のオペレーティングシステムのファイル、OEM のファイルを格納するのに十分なスペースを確保するために、ESP のサイズは 1 GiB にすることが推奨されます。これでも十分であるか疑問である場合は、4 GiB を割り当てておけばいかなる場合でも十分であるはずです。
−
他のオペレーティングシステムとの相互運用上の問題を回避し[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions#diskpartitionrules]、[[Advanced Format]] ドライブとの互換性を確保するには[https://superuser.com/questions/1310927/what-is-the-absolute-minimum-size-a-uefi-partition-can-be/1310938]、ESP は少なくとも 300 MiB にすることが推奨されます。
  
   
  +
{{Note|小さい ESP を使うこともできますが、互換性の問題が発生する可能性があることに注意してください:
−
{{Note|
  
−
* 初期の、あるいはバグのある UEFI 実装では、ESP は少なくとも 512 MiB が必要かもしれません。[https://www.rodsbooks.com/efi-bootloaders/principles.html]
 +
* 初期の UEFI 実装やバグのある実装では、ESP は少なくとも 512 MiB が必要かもしれません。[https://www.rodsbooks.com/efi-bootloaders/principles.html]
  +
* ESP を [[パーティショニング#/boot|/boot]] にマウントするつもりであり、かつ、複数のカーネルをインストールしないのであれば、400 MiB で十分でしょう。
  +
* [[Windows とのデュアルブート|Windows とデュアルブートする]]場合、論理セクタサイズが 4096 バイトのドライブ ([[Advanced Format]] 4Kn ドライブ) では ESP のサイズは少なくとも 300 MiB は必要です。[https://superuser.com/questions/1310927/what-is-the-absolute-minimum-size-a-uefi-partition-can-be/1310938] その他のドライブでは少なくとも 100 MiB 必要です。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions#diskpartitionrules]
 
* EFI システムパーティションが FAT32 でフォーマットできることを保証するには、パーティションのサイズは、論理セクタサイズが 512 バイトのドライブでは 36 MiB 以上、論理セクタサイズが 4096 バイトのドライブでは 260 MiB 以上である必要があります。[https://superuser.com/a/1717643]
  
* EFI システムパーティションが FAT32 でフォーマットできることを保証するには、パーティションのサイズは、論理セクタサイズが 512 バイトのドライブでは 36 MiB 以上、論理セクタサイズが 4096 バイトのドライブでは 260 MiB 以上である必要があります。[https://superuser.com/a/1717643]
−
* 複数のカーネルをインストールする予定であり、かつ、EFI システムパーティションを [[パーティショニング#/boot|/boot]] 上にマウントするかそれらのカーネルを [[unified カーネルイメージ]]にパックする場合、1 GiB を使用することで安全を期することができます。
  
 
* これらが問題とならない場合、パーティションのサイズは 2 MiB まで小さくできます。この場合、ブートローダ以外は格納できません。
  
* これらが問題とならない場合、パーティションのサイズは 2 MiB まで小さくできます。この場合、ブートローダ以外は格納できません。
 
}}
  
}}
54行目: 55行目:
 
GPT でパーティションされたディスクに ESP を作成する場合、以下の方法の'''一つ'''を使って下さい:
  
GPT でパーティションされたディスクに ESP を作成する場合、以下の方法の'''一つ'''を使って下さい:
   
−
* [[fdisk]]: パーティションタイプ {{ic|EFI System}} のパーティションを作成してください。
 +
* [[fdisk]]: パーティションを1つ作成し、{{ic|t}} コマンドでパーティションタイプを {{ic|EFI System}} に[[fdisk#パーティションタイプの変更|変更]]してください。
 
* [[gdisk]]: パーティションタイプ {{ic|EF00}} のパーティションを作成してください。
  
* [[gdisk]]: パーティションタイプ {{ic|EF00}} のパーティションを作成してください。
 
* [[GNU Parted]]: ファイルシステム {{ic|fat32}} のパーティションを作成し、{{ic|esp}} フラグをセットしてください。
  
* [[GNU Parted]]: ファイルシステム {{ic|fat32}} のパーティションを作成し、{{ic|esp}} フラグをセットしてください。
74行目: 75行目:
 
MBR でパーティションされたディスクに ESP を作成する場合、以下の方法の'''一つ'''を使って下さい:
  
MBR でパーティションされたディスクに ESP を作成する場合、以下の方法の'''一つ'''を使って下さい:
   
−
* [[fdisk]]: パーティションタイプ {{ic|EFI (FAT-12/16/32)}} のプライマリパーティションを作成してください。
 +
* [[fdisk]]: パーティションを1つ作成し、{{ic|t}} コマンドでパーティションタイプを {{ic|EFI (FAT-12/16/32)}} に[[fdisk#パーティションタイプの変更|変更]]してください。
 
* [[GNU Parted]]: ファイルシステム {{ic|fat32}} のプライマリパーティションを作成し、{{ic|esp}} フラグをセットしてください。
  
* [[GNU Parted]]: ファイルシステム {{ic|fat32}} のプライマリパーティションを作成し、{{ic|esp}} フラグをセットしてください。
   
113行目: 114行目:
 
EFI システムパーティションのマウントに関しては、3つの典型的なシナリオがあります:
  
EFI システムパーティションのマウントに関しては、3つの典型的なシナリオがあります:
   
−
* ESP を {{ic|/boot}} にマウントする:
 +
* ESP を {{ic|/boot}} に[[マウント]]する:
 
** システムのメンテナンスと管理が容易になります。{{ic|/boot}} は、[[マイクロコード]]のパッケージが CPU のマイクロコード initramfs ファイルを配置し、[[mkinitcpio]] が[[カーネル]]と [[initramfs]] イメージを配置するデフォルトのパスだからです。
  
** システムのメンテナンスと管理が容易になります。{{ic|/boot}} は、[[マイクロコード]]のパッケージが CPU のマイクロコード initramfs ファイルを配置し、[[mkinitcpio]] が[[カーネル]]と [[initramfs]] イメージを配置するデフォルトのパスだからです。
 
** 上記のファイルがほとんどの[[ブートローダー]]からアクセスできることを保証できます。というのも、すべてのブートローダーが他のボリューム上のファイルにアクセスできるわけではないからです。
  
** 上記のファイルがほとんどの[[ブートローダー]]からアクセスできることを保証できます。というのも、すべてのブートローダーが他のボリューム上のファイルにアクセスできるわけではないからです。
120行目: 121行目:
 
** この方法では、デュアルブートの場合に OS 固有のブートファイルを他の OS からの潜在的に危険な操作に晒してしまいます。
  
** この方法では、デュアルブートの場合に OS 固有のブートファイルを他の OS からの潜在的に危険な操作に晒してしまいます。
 
** この方法では、[[GRUB#暗号化された /boot|/boot の暗号化]]が不可能です。EFI 関連のファイルはファームウェアからアクセス可能でなければならないからです。
  
** この方法では、[[GRUB#暗号化された /boot|/boot の暗号化]]が不可能です。EFI 関連のファイルはファームウェアからアクセス可能でなければならないからです。
−
* ESP を {{ic|/efi}} にマウントする:
 +
* ESP を {{ic|/efi}} に[[マウント]]する:
 
** OS 関連のファイルと EFI 関連のファイルの懸念事項が分離されます。これらのファイルには他の OS のファイルが含まれている場合があり、放っておいたほうが良いでしょう。
  
** OS 関連のファイルと EFI 関連のファイルの懸念事項が分離されます。これらのファイルには他の OS のファイルが含まれている場合があり、放っておいたほうが良いでしょう。
 
** {{ic|/boot}} にインストールされるファイルが ESP に入らないので、ESP のサイズ要件が大きくなってしまうことを防ぐことができます。EFI バイナリ (ブートローダ (とオプションでドライバ) や unified カーネルイメージ) のみが ESP に格納されることになるので、ストレージスペースを節約できます。
  
** {{ic|/boot}} にインストールされるファイルが ESP に入らないので、ESP のサイズ要件が大きくなってしまうことを防ぐことができます。EFI バイナリ (ブートローダ (とオプションでドライバ) や unified カーネルイメージ) のみが ESP に格納されることになるので、ストレージスペースを節約できます。
−
** {{ic|/boot}} 内のファイルに Linux 固有のファイルシステムを設定することができ、FAT の制限に悩まされることはありません。
 +
** {{ic|/boot}} 内のファイルに Linux 固有のファイルシステムのパーミッションを保持することができ、FAT の制限に悩まされることはありません。
 
** 必要に応じて ESP を別途マウントできます。例えば、[[ブートローダー]]をアップグレードするときにだけマウントするなどができます。
  
** 必要に応じて ESP を別途マウントできます。例えば、[[ブートローダー]]をアップグレードするときにだけマウントするなどができます。
 
** 適切なセットアップで[[dm-crypt/システム全体の暗号化|システムの暗号化]]を行っている場合、{{ic|/boot}} は保護される一方、いくつかの必要なファイルは暗号化されていない状態にできます。これは、他の場所に保存されているカーネルやファイルにアクセスできるファイルシステムドライバを持っている [[ブートローダー]]や [[unified カーネルイメージ]]を使用する場合に便利です。
  
** 適切なセットアップで[[dm-crypt/システム全体の暗号化|システムの暗号化]]を行っている場合、{{ic|/boot}} は保護される一方、いくつかの必要なファイルは暗号化されていない状態にできます。これは、他の場所に保存されているカーネルやファイルにアクセスできるファイルシステムドライバを持っている [[ブートローダー]]や [[unified カーネルイメージ]]を使用する場合に便利です。
142行目: 143行目:
 
# cp -a /boot/initramfs-linux-fallback.img ''esp''/EFI/arch/
  
# cp -a /boot/initramfs-linux-fallback.img ''esp''/EFI/arch/
   
−
{{Note|[[マイクロコード]]もブートエントリの場所にコピーする必要があります。}}
 +
{{Note|(マイクロコード initramfs をメインの initramfs イメージと統合せずに) [[マイクロコード#別個のマイクロコード initramfs ファイルを使う|外部のマイクロコード initramfs イメージ]]を使う場合、ブートエントリの場所にそのマイクロコードファイルをコピーしておく必要があります。}}
   
 
さらに、今後のカーネルアップデートの際に ESP 上のファイルを最新に保つ必要があります。これに失敗するとシステムが起動不能になる可能性があります。以下のセクションでは、これを自動化する方法をいくつか説明しています。
  
さらに、今後のカーネルアップデートの際に ESP 上のファイルを最新に保つ必要があります。これに失敗するとシステムが起動不能になる可能性があります。以下のセクションでは、これを自動化する方法をいくつか説明しています。
267行目: 268行目:
 
#ALL_config="/etc/mkinitcpio.conf"
  
#ALL_config="/etc/mkinitcpio.conf"
 
ALL_kver="${ESP_DIR}/vmlinuz-linux"
  
ALL_kver="${ESP_DIR}/vmlinuz-linux"
−
<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')
  
PRESETS=('default' 'fallback')
291行目: 290行目:
 
{{hc|/etc/mkinitcpio.d/linux.preset|2=
  
{{hc|/etc/mkinitcpio.d/linux.preset|2=
 
ESP_DIR="''esp''/EFI/arch"
  
ESP_DIR="''esp''/EFI/arch"
  +
#ALL_config="/etc/mkinitcpio.conf"
−
cp -f "/boot/vmlinuz-linux$suffix" "$ESP_DIR/"
  
−
ALL_config="/etc/mkinitcpio.conf"
  
 
ALL_kver="$ESP_DIR/vmlinuz-linux$suffix"
  
ALL_kver="$ESP_DIR/vmlinuz-linux$suffix"
 
PRESETS=('default')
  
PRESETS=('default')
302行目: 300行目:
 
suffix='-zen'
  
suffix='-zen'
 
source /etc/mkinitcpio.d/linux.preset
  
source /etc/mkinitcpio.d/linux.preset
  +
}}
  +
  +
==== mkinitcpio のポストフックを使う ====
  +
  +
[[mkinitcpio#ポストフック|mkinitcpio のポストフック]]を使うことで、initramfs の生成後にカーネルと initramfs のイメージを所望のディレクトリに自動でコピーさせることができます。
  +
  +
以下のファイルを[[作成]]し、そのファイルに[[実行可能属性]]を付与してください:
  +
  +
{{hc|/etc/initcpio/post/copy-kernel-and-initramfs|2=
  +
#!/usr/bin/env bash
  +
  +
kernel="$1"
  +
initrd="$2"
  +
target_dir="''esp''/EFI/arch"
  +
files_to_copy=()
  +
  +
for file in "$kernel" "$initrd"; do
  +
if <nowiki>[[ -n "$file" ]]</nowiki> && ! cmp -s -- "$file" "${target_dir}/${file##*/}"; then
  +
files_to_copy+=("$file")
  +
fi
  +
done
  +
  +
(( ! ${#files_to_copy[@]} )) && exit 0
  +
  +
cp -af -- "${files_to_copy[@]}" "${target_dir}/"
 
}}
  
}}
   
352行目: 375行目:
 
exit 0
  
exit 0
 
}}
  
}}
  +
  +
== ヒントとテクニック ==
  +
  +
=== ESP をより大きなパーティションに取り替える ===
  +
  +
既存のオペレーティングシステムが載っているディスクでは、EFI システムパーティションが [[#パーティションの作成]] 章で推奨されているサイズよりも小さいことがあります。例えば、Windows Setup は 4Kn でないドライブ上にはたった 100 MiB の EFI システムパーティションしか作成しません。
  +
  +
そのような場合では、ESP のスペースを使い切らないようにより大きな新しい EFI システムパーティションを作成したほうが良いかもしれません。
  +
  +
==== Windows から新しいパーティション用に領域を空ける ====
  +
  +
Windows からは、グラフィカルな「ディスクの管理」({{ic|diskmgmr.msc}}) やコマンドラインインターフェイスの {{ic|diskpart.exe}} ユーティリティでパーティションを管理できます。
  +
  +
{{ic|diskmgmr.msc}} を管理者として実行してください。
  +
  +
# "(C:)" パーティション (Windows によってデフォルトで作成されるパーティションのうち、これが唯一オンライン状態でリサイズ可能です) を右クリックし、''ボリュームの縮小...'' を選択してください。
  +
# 縮小する領域のサイズとして {{ic|4096}} を入力し、''縮小'' をクリックしてください。
  +
  +
これで、"(C:)" パーティションの後ろに 4 GiB の未割り当てのスペースが空くはずです。
  +
  +
Arch Linux か Arch Linux のインストールメディアを起動し、新しいパーティションの作成作業に移ります。
  +
  +
==== 古い ESP を削除し、新規に作成する ====
  +
  +
まず、EFI システムパーティション内のコンテンツをバックアップしておいてください。例えば、''esp'' が ESP のマウントポイントである場合:
  +
  +
# cp -a ''esp'' /esp_backup
  +
  +
EFI システムパーティションをアンマウントしてください:
  +
  +
# umount ''esp''
  +
  +
{{Note|インストール済みのシステム上で行う場合は、システムが自動的に ESP をマウントしないようするために、{{ic|''esp''.mount}} ユニットと {{ic|''esp''.automount}} ユニットを[[停止]]しておく必要がある場合があります。}}
  +
  +
''blkid'' を実行し、ESP の UUID と PARTUUID の値をメモしてください。これらは後に新しい ESP で再利用します。
  +
  +
{{hc|# blkid|2=
  +
/dev/sd''xY'': UUID="'''''XXXX-XXXX'''''" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="'''''YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY'''''"
  +
}}
  +
  +
{{Pkg|gptfdisk}} パッケージの [[sgdisk]] を使って古い ESP を削除してください:
  +
  +
# sgdisk --delete=''Y'' /dev/sd''x''
  +
  +
最大の未割り当てスペースに新しいパーティションを作成します。ここで先の古い PARTUUID と PARTLABEL を利用します:
  +
  +
# sgdisk --align-end --largest-new=0 --typecode=0:ef00 --change-name=0:'EFI system partition' --partition-guid=0:''YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY'' /dev/sd''x''
  +
  +
''fdisk'' でパーティションの一覧を表示し、新しい 4 GiB の EFI システムパーティションが作成されたことを確認してください:
  +
  +
{{hc|# fdisk -l /dev/sd''x''|
  +
...
  +
Device Start End Sectors Size Type
  +
/dev/sd''x''1 158099456 166488063 8388608 4G EFI System
  +
/dev/sd''x''2 206848 239615 32768 16M Microsoft reserved
  +
/dev/sd''x''3 239616 158099455 157859840 75.3G Microsoft basic data
  +
/dev/sd''x''4 166488064 167768063 1280000 625M Windows recovery environment
  +
  +
Partition table entries are not in disk order.
  +
}}
  +
  +
パーティション番号はパーティションの削除と作成の際にソートされません。なので、EFI システムパーティションの番号は以前と同じである可能性が高いです。
  +
  +
パーティションを FAT32 でフォーマットし、先ほどメモした古い UUID をここで再利用します (ただし、UUID からはダッシュ記号を抜いてください):
  +
  +
# mkfs.fat -F 32 -i ''XXXXXXXX'' /dev/sd''xY''
  +
  +
最後に、新しいパーティションをマウントし、バックアップしたコンテンツを保存してください:
  +
  +
# mount /dev/sd''xY'' ''esp''
  +
# cp -a /esp_backup/. ''esp''/
  +
  +
{{ic|''esp''.automount}} を停止していた場合は、再び[[開始]]してください。
  +
  +
==== 隣接するスワップパーティションを犠牲にして ESP を大きくする ====
  +
  +
EFI システムパーティションのすぐ後ろにスワップパーティションが存在する場合、それを犠牲にして EFI システムパーティションを大きくすることができます。例えば、以下と似たようなパーティションレイアウトの場合です:
  +
  +
{{hc|# fdisk -l /dev/sd''x''|
  +
...
  +
Device Start End Sectors Size Type
  +
/dev/sd''x''1 2048 616447 614400 300M EFI System
  +
/dev/sd''x''2 616448 9005055 8388608 4G Linux swap
  +
/dev/sd''x''3 9005056 125827071 116822016 55.7G Linux root (x86-64)
  +
}}
  +
  +
まず、[[スワップ# スワップの無効化|スワップパーティションを無効化]]し、[[fstab]] から削除してください。
  +
  +
[[fdisk]] を使ってスワップパーティションを削除し、EFI システムパーティションを拡大してください:
  +
  +
# 次を実行してください: {{bc|# fdisk -l /dev/sd''x''}}
  +
# {{ic|d}} コマンドを使ってスワップパーティション (上記のレイアウト例ではパーティション番号 {{ic|2}} です) を削除してください。
  +
# {{ic|e}} コマンドを使って EFI システムパーティション (上記の例ではパーティション番号 {{ic|1}} です) を拡大してください。提案された新しいサイズをそのまま使い、{{ic|Enter}} を押してください。
  +
# {{ic|w}} コマンドで変更をディスクに書き込んで、fdisk を終了してください。
  +
  +
パーティションをリサイズしたら、パーティション内のファイルシステムもリサイズする必要があります。{{man|1|fatresize}} は[https://github.com/ya-mouse/fatresize/issues/18 動作しない]うえ、libparted は [https://superuser.com/a/1717415 特定のサイズの FAT ボリュームをリサイズできない]ため、唯一の手段は既存の ESP ファイルシステムからファイルをバックアップしておいて、より大きな新しくファイルシステムを作成することです。
  +
  +
新しいファイルシステムで再利用するために ESP の [[UUID]] をメモしてください:
  +
  +
{{hc|$ lsblk -dno UUID /dev/sd''xY''|
  +
'''''XXXX-XXXX'''''
  +
}}
  +
  +
EFI システムパーティションのコンテンツをバックアップしてください。例えば、''esp'' が ESP のマウントポイントである場合:
  +
  +
# cp -a ''esp'' /esp_backup
  +
  +
EFI システムパーティションをアンマウントしてください:
  +
  +
# umount ''esp''
  +
  +
{{Note|インストール済みのシステム上で行う場合は、システムが自動的に ESP をマウントしないようするために、{{ic|''esp''.mount}} ユニットと {{ic|''esp''.automount}} ユニットを[[停止]]しておく必要がある場合があります。}}
  +
  +
古いファイルシステムから残留物を残さないようにするために、ESP からファイルシステムのシグネチャを削除してください:
  +
  +
# wipefs -af /dev/sd''xY''
  +
  +
パーティションを FAT32 でフォーマットし、先ほどメモした古い UUID をここで再利用します (ただし、UUID からはダッシュ記号を抜いてください):
  +
  +
# mkfs.fat -F 32 -i ''XXXXXXXX'' /dev/sd''xY''
  +
  +
最後に、新しいパーティションをマウントし、バックアップしたコンテンツを保存してください:
  +
  +
# mount /dev/sd''xY'' ''esp''
  +
# cp -a /esp_backup/. ''esp''/
  +
  +
{{ic|''esp''.automount}} を停止していた場合は、再び[[開始]]してください。
  +
  +
スワップパーティションは無くなってしまったので、[[スワップファイル]]でスワップをセットアップしてください。
   
 
== トラブルシューティング ==
  
== トラブルシューティング ==
   
−
=== ソフトウェア RAID1 上の ESP ===
 +
=== ソフトウェア RAID1 上に ESP を配置する ===
   
 
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] を見てください。
  
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] を見てください。
370行目: 522行目:
   
 
* [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://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]
 +
* [https://ramsdenj.com/posts/2016-04-15-multi-boot-linux-with-one-boot-partition/ Multi Boot Linux With One Boot Partition | John Ramsden]
   
−
{{TranslationStatus|EFI system partition|2023-04-01|773912}}
 +
{{TranslationStatus|EFI system partition|2024-06-15|810376}}

2024年8月30日 (金) 21:17時点における最新版

関連記事

EFI System Partition (ESP とも呼ばれます) は UEFI ファームウェアによって起動される UEFI ブートローダ、アプリケーション、ドライバの格納場所として機能する 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 のサイズは、起動に必要なファイルとブートローダを格納するために十分な大きさである必要があります。

複数のカーネルや複数の unified カーネルイメージ、ブートローダー、ファームウェアのアップデートファイル、他のオペレーティングシステムのファイル、OEM のファイルを格納するのに十分なスペースを確保するために、ESP のサイズは 1 GiB にすることが推奨されます。これでも十分であるか疑問である場合は、4 GiB を割り当てておけばいかなる場合でも十分であるはずです。

ノート: 小さい ESP を使うこともできますが、互換性の問題が発生する可能性があることに注意してください:
  • 初期の UEFI 実装やバグのある実装では、ESP は少なくとも 512 MiB が必要かもしれません。[1]
  • ESP を /boot にマウントするつもりであり、かつ、複数のカーネルをインストールしないのであれば、400 MiB で十分でしょう。
  • Windows とデュアルブートする場合、論理セクタサイズが 4096 バイトのドライブ (Advanced Format 4Kn ドライブ) では ESP のサイズは少なくとも 300 MiB は必要です。[2] その他のドライブでは少なくとも 100 MiB 必要です。[3]
  • EFI システムパーティションが FAT32 でフォーマットできることを保証するには、パーティションのサイズは、論理セクタサイズが 512 バイトのドライブでは 36 MiB 以上、論理セクタサイズが 4096 バイトのドライブでは 260 MiB 以上である必要があります。[4]
  • これらが問題とならない場合、パーティションのサイズは 2 MiB まで小さくできます。この場合、ブートローダ以外は格納できません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# mkfs.fat -F 32 /dev/sdxY

WARNING: Not enough clusters for a 32 bit FAT! というメッセージが表示され、大きい ESP を作成できない場合、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 システムパーティションのマウントポイントはブートローダの選択により制限されます。

ノート: ESP を /boot にマウントしない場合、カーネルアップデートの時に (systemd-gpt-auto-generator を含む) systemd の自動マウント機構に頼らないようにしてください。必ずシステムやカーネルのアップデートの前に手動で ESP をマウントしてください。さもないと、アップデート後に ESP をマウントできず、ESP 上のカーネルのコピーをアップデートできなくなり、現在実行中のカーネルから移行できなくなります。

あるいは、必要なカーネルモジュールをブート時に予め読み込んでください。例: 

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

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

EFI システムパーティションのマウントに関しては、3つの典型的なシナリオがあります:

  • ESP を /boot にマウントする:
    • システムのメンテナンスと管理が容易になります。/boot は、マイクロコードのパッケージが CPU のマイクロコード initramfs ファイルを配置し、mkinitcpio がカーネルと initramfs イメージを配置するデフォルトのパスだからです。
    • 上記のファイルがほとんどのブートローダーからアクセスできることを保証できます。というのも、すべてのブートローダーが他のボリューム上のファイルにアクセスできるわけではないからです。
    • この方法では、各ファイルに対してパーミッションや拡張属性を設定できません。FAT ファイルシステムはグローバルなパーミッションをマウント時に設定するからです。
    • この方法では、ESP のサイズ要件が大きくなります。EFI 関連のファイルに加えて、通常 /boot にインストールされるファイルが加わるからです。
    • この方法では、デュアルブートの場合に OS 固有のブートファイルを他の OS からの潜在的に危険な操作に晒してしまいます。
    • この方法では、/boot の暗号化が不可能です。EFI 関連のファイルはファームウェアからアクセス可能でなければならないからです。
  • ESP を /efi にマウントする:
    • OS 関連のファイルと EFI 関連のファイルの懸念事項が分離されます。これらのファイルには他の OS のファイルが含まれている場合があり、放っておいたほうが良いでしょう。
    • /boot にインストールされるファイルが ESP に入らないので、ESP のサイズ要件が大きくなってしまうことを防ぐことができます。EFI バイナリ (ブートローダ (とオプションでドライバ) や unified カーネルイメージ) のみが ESP に格納されることになるので、ストレージスペースを節約できます。
    • /boot 内のファイルに Linux 固有のファイルシステムのパーミッションを保持することができ、FAT の制限に悩まされることはありません。
    • 必要に応じて ESP を別途マウントできます。例えば、ブートローダーをアップグレードするときにだけマウントするなどができます。
    • 適切なセットアップでシステムの暗号化を行っている場合、/boot は保護される一方、いくつかの必要なファイルは暗号化されていない状態にできます。これは、他の場所に保存されているカーネルやファイルにアクセスできるファイルシステムドライバを持っている ブートローダーや unified カーネルイメージを使用する場合に便利です。
  • ESP を /efi にマウントし、さらに "Extended Boot Loader Partition" (XBOOTLDR) を /boot にマウントする。これは、先に作成しておいた ESP が、複数のブートローダーやカーネルを保存するには小さすぎるが、ESP を容易には拡張できない場合に便利です (そのような場合として、デュアルブートするために Windows のあとに Linux をインストールした場合などがあります)。この方法は、少なくとも systemd-boot によってサポートされています。
ノート:
  • /efi は、歴史的で現在は推奨されていない ESP マウントポイント /boot/efi の代替[6]です。
  • /efi ディレクトリはデフォルトで存在しません。そこへ ESP をマウントする前に、先にそのディレクトリを作成する必要があります。

代替のマウントポイント

#典型的なマウントポイント を使わない場合、ブートファイルを 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/
ノート: (マイクロコード initramfs をメインの initramfs イメージと統合せずに) 外部のマイクロコード initramfs イメージを使う場合、ブートエントリの場所にそのマイクロコードファイルをコピーしておく必要があります。

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

バインドマウントを使う

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 install the kernel, the initramfs...
ESP_DIR="esp/EFI/arch"

#ALL_config="/etc/mkinitcpio.conf"
ALL_kver="${ESP_DIR}/vmlinuz-linux"

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
# mv /boot/vmlinuz-linux esp/EFI/arch/
# mkinitcpio -p linux
もう一つの例
/etc/mkinitcpio.d/linux.preset
ESP_DIR="esp/EFI/arch"
#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

mkinitcpio のポストフックを使う

mkinitcpio のポストフックを使うことで、initramfs の生成後にカーネルと initramfs のイメージを所望のディレクトリに自動でコピーさせることができます。

以下のファイルを作成し、そのファイルに実行可能属性を付与してください: 

/etc/initcpio/post/copy-kernel-and-initramfs
#!/usr/bin/env bash

kernel="$1"
initrd="$2"
target_dir="esp/EFI/arch"
files_to_copy=()

for file in "$kernel" "$initrd"; do
	if [[ -n "$file" ]] && ! cmp -s -- "$file" "${target_dir}/${file##*/}"; then
		files_to_copy+=("$file")
	fi
done

(( ! ${#files_to_copy[@]} )) && exit 0

cp -af -- "${files_to_copy[@]}" "${target_dir}/"

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

ヒントとテクニック

ESP をより大きなパーティションに取り替える

既存のオペレーティングシステムが載っているディスクでは、EFI システムパーティションが #パーティションの作成 章で推奨されているサイズよりも小さいことがあります。例えば、Windows Setup は 4Kn でないドライブ上にはたった 100 MiB の EFI システムパーティションしか作成しません。

そのような場合では、ESP のスペースを使い切らないようにより大きな新しい EFI システムパーティションを作成したほうが良いかもしれません。

Windows から新しいパーティション用に領域を空ける

Windows からは、グラフィカルな「ディスクの管理」(diskmgmr.msc) やコマンドラインインターフェイスの diskpart.exe ユーティリティでパーティションを管理できます。

diskmgmr.msc を管理者として実行してください。

  1. "(C:)" パーティション (Windows によってデフォルトで作成されるパーティションのうち、これが唯一オンライン状態でリサイズ可能です) を右クリックし、ボリュームの縮小... を選択してください。
  2. 縮小する領域のサイズとして 4096 を入力し、縮小 をクリックしてください。

これで、"(C:)" パーティションの後ろに 4 GiB の未割り当てのスペースが空くはずです。

Arch Linux か Arch Linux のインストールメディアを起動し、新しいパーティションの作成作業に移ります。

古い ESP を削除し、新規に作成する

まず、EFI システムパーティション内のコンテンツをバックアップしておいてください。例えば、esp が ESP のマウントポイントである場合: 

# cp -a esp /esp_backup

EFI システムパーティションをアンマウントしてください: 

# umount esp
ノート: インストール済みのシステム上で行う場合は、システムが自動的に ESP をマウントしないようするために、esp.mount ユニットと esp.automount ユニットを停止しておく必要がある場合があります。

blkid を実行し、ESP の UUID と PARTUUID の値をメモしてください。これらは後に新しい ESP で再利用します。 

# blkid
/dev/sdxY: UUID="XXXX-XXXX" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY"

gptfdisk パッケージの sgdisk を使って古い ESP を削除してください: 

# sgdisk --delete=Y /dev/sdx

最大の未割り当てスペースに新しいパーティションを作成します。ここで先の古い PARTUUID と PARTLABEL を利用します: 

# sgdisk --align-end --largest-new=0 --typecode=0:ef00 --change-name=0:'EFI system partition' --partition-guid=0:YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY /dev/sdx

fdisk でパーティションの一覧を表示し、新しい 4 GiB の EFI システムパーティションが作成されたことを確認してください: 

# fdisk -l /dev/sdx
...
Device         Start       End   Sectors  Size Type
/dev/sdx1  158099456 166488063   8388608    4G EFI System
/dev/sdx2     206848    239615     32768   16M Microsoft reserved
/dev/sdx3     239616 158099455 157859840 75.3G Microsoft basic data
/dev/sdx4  166488064 167768063   1280000  625M Windows recovery environment

Partition table entries are not in disk order.

パーティション番号はパーティションの削除と作成の際にソートされません。なので、EFI システムパーティションの番号は以前と同じである可能性が高いです。

パーティションを FAT32 でフォーマットし、先ほどメモした古い UUID をここで再利用します (ただし、UUID からはダッシュ記号を抜いてください): 

# mkfs.fat -F 32 -i XXXXXXXX /dev/sdxY

最後に、新しいパーティションをマウントし、バックアップしたコンテンツを保存してください: 

# mount /dev/sdxY esp
# cp -a /esp_backup/. esp/

esp.automount を停止していた場合は、再び開始してください。

隣接するスワップパーティションを犠牲にして ESP を大きくする

EFI システムパーティションのすぐ後ろにスワップパーティションが存在する場合、それを犠牲にして EFI システムパーティションを大きくすることができます。例えば、以下と似たようなパーティションレイアウトの場合です: 

# fdisk -l /dev/sdx
...
Device       Start       End   Sectors  Size Type
/dev/sdx1     2048    616447    614400  300M EFI System
/dev/sdx2   616448   9005055   8388608    4G Linux swap
/dev/sdx3  9005056 125827071 116822016 55.7G Linux root (x86-64)

まず、スワップパーティションを無効化し、fstab から削除してください。

fdisk を使ってスワップパーティションを削除し、EFI システムパーティションを拡大してください:

  1. 次を実行してください: 
    # fdisk -l /dev/sdx
  2. d コマンドを使ってスワップパーティション (上記のレイアウト例ではパーティション番号 2 です) を削除してください。
  3. e コマンドを使って EFI システムパーティション (上記の例ではパーティション番号 1 です) を拡大してください。提案された新しいサイズをそのまま使い、Enter を押してください。
  4. w コマンドで変更をディスクに書き込んで、fdisk を終了してください。

パーティションをリサイズしたら、パーティション内のファイルシステムもリサイズする必要があります。fatresize(1) は動作しないうえ、libparted は 特定のサイズの FAT ボリュームをリサイズできないため、唯一の手段は既存の ESP ファイルシステムからファイルをバックアップしておいて、より大きな新しくファイルシステムを作成することです。

新しいファイルシステムで再利用するために ESP の UUID をメモしてください: 

$ lsblk -dno UUID /dev/sdxY
XXXX-XXXX

EFI システムパーティションのコンテンツをバックアップしてください。例えば、esp が ESP のマウントポイントである場合: 

# cp -a esp /esp_backup

EFI システムパーティションをアンマウントしてください: 

# umount esp
ノート: インストール済みのシステム上で行う場合は、システムが自動的に ESP をマウントしないようするために、esp.mount ユニットと esp.automount ユニットを停止しておく必要がある場合があります。

古いファイルシステムから残留物を残さないようにするために、ESP からファイルシステムのシグネチャを削除してください: 

# wipefs -af /dev/sdxY

パーティションを FAT32 でフォーマットし、先ほどメモした古い UUID をここで再利用します (ただし、UUID からはダッシュ記号を抜いてください): 

# mkfs.fat -F 32 -i XXXXXXXX /dev/sdxY

最後に、新しいパーティションをマウントし、バックアップしたコンテンツを保存してください: 

# mount /dev/sdxY esp
# cp -a /esp_backup/. esp/

esp.automount を停止していた場合は、再び開始してください。

スワップパーティションは無くなってしまったので、スワップファイルでスワップをセットアップしてください。

トラブルシューティング

ソフトウェア RAID1 上に ESP を配置する

ESP を RAID1 アレイに置くことも可能ですが、データが破損する危険性があり、また、ESP を作成する際に様々な注意をする必要があります。詳細は [7] と [8] を、解決策付きの詳細なガイドは 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 ディレクトリが存在しないかのように振る舞います。

参照

翻訳ステータス: このページは en:EFI system partition の翻訳バージョンです。最後の翻訳日は 2024-06-15 です。もし英語版に 変更 があれば、翻訳の同期を手伝うことができます。
「https://wiki.archlinux.jp/index.php?title=EFI_システムパーティション&oldid=38792」から取得