「Systemd-boot」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(Kusakata がページ「Gummiboot」をリダイレクトの「Systemd-boot」に移動しました)
(→‎Unified Kernel Image を使う: ユニファイドカーネルイメージに変更)
 
(7人の利用者による、間の62版が非表示)
1行目: 1行目:
  +
{{lowercase title}}
{{DISPLAYTITLE:gummiboot}}
 
 
[[Category:ブートローダー]]
 
[[Category:ブートローダー]]
 
[[de:Gummiboot]]
 
[[de:Gummiboot]]
[[en:Gummiboot]]
+
[[en:Systemd-boot]]
[[es:Gummiboot]]
+
[[es:Systemd-boot]]
[[ru:Gummiboot]]
+
[[pt:Systemd-boot]]
  +
[[ru:Systemd-boot]]
  +
[[zh-hans:Systemd-boot]]
 
{{Related articles start}}
 
{{Related articles start}}
 
{{Related|Arch ブートプロセス}}
 
{{Related|Arch ブートプロセス}}
 
{{Related|ブートローダー}}
 
{{Related|ブートローダー}}
  +
{{Related|セキュアブート}}
 
{{Related|Unified Extensible Firmware Interface}}
 
{{Related|Unified Extensible Firmware Interface}}
 
{{Related articles end}}
 
{{Related articles end}}
  +
'''systemd-boot''' (旧名 '''gummiboot'''。ドイツ語で「ゴムボート」)は、 設定された EFI イメージを実行するシンプルな [[UEFI]] [[ブートマネージャー]]です。デフォルトのエントリは設定されたパターン (glob) または矢印キーで操作する画面上のメニューによって選択されます。{{Pkg|systemd}} に含まれており、Arch システムにデフォルトでインストールされます。
[http://freedesktop.org/wiki/Software/gummiboot/ gummiboot のホームページ] より:
 
:''gummiboot は設定済みの EFI イメージを実行できるシンプルな UEFI ブートマネージャです。デフォルトのエントリは設定したパターン (glob) または画面上のメニューで選択されます。''
 
   
  +
systemd-boot は EFI 実行可能ファイル ([[EFISTUB]]、[[UEFI シェル]]、[[GRUB]]、[https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/boot-and-uefi#understanding-the-windows-boot-manager Windows ブートマネージャ]) のみを起動できることに注意してください。
gummiboot は簡単に設定することができ、Linux カーネルの [[EFISTUB]] や UEFI シェル、grub.efi などの EFI 実行可能ファイルだけを起動できます。
 
   
  +
== サポートされているファイルシステム ==
{{Warning|gummiboot は EFISTUB カーネルのブートメニューを提供します。{{Bug|33745}} にあるように EFISTUB カーネルの起動に問題が起こる場合は、[[GRUB]] や [[Syslinux]]、または [[ブートローダー#ELILO|ELILO]] といった EFISTUB を使用しないブートローダーを使ってください。}}
 
   
  +
systemd-boot はファイルシステムのサポートを [[Arch ブートプロセス#UEFI|ファームウェア]] から引き継ぎます (少なくとも FAT12、FAT16、FAT32) さらに、{{ic|''esp''/EFI/systemd/drivers/}} にある [[Unified Extensible Firmware Interface#UEFI ドライバ|UEFI ドライバ]] を全てロードします。
{{Note|この記事では [[UEFI#EFI System Partition|EFI System Partition]] (ESP) のマウントポイントを {{ic|$esp}} で示します。}}
 
 
{{Note|systemd 220-2 から Gummiboot は systemd-boot として [[systemd]] にマージされています。{{ic|bootctl install}} を使ってインストールしてください。}}
 
   
 
== インストール ==
 
== インストール ==
{{Pkg|gummiboot}} をインストールしてから次のコマンドを実行して gummiboot をあなたのブートローダとしてインストールしてください:
 
   
  +
''systemd-boot'' は、{{Pkg|base}} メタパッケージの依存関係である {{Pkg|systemd}} パッケージとともに出荷されるため、追加のパッケージを手動でインストールする必要はありません。
# gummiboot install
 
  +
  +
== EFI ブートマネージャのインストール ==
  +
  +
''systemd-boot'' の EFI ブートマネージャをインストールする場合、まず UEFI モードでシステムが起動しているかどうか、[[Unified Extensible Firmware Interface#UEFI 変数|UEFI 変数]] が利用できるかどうか確かめてください。{{ic|efivar --list}} コマンドを実行することでチェックできます。または、efivar がインストールされていない場合は、{{ic|ls /sys/firmware/efi/efivars}} を実行してください (ディレクトリが存在する場合、システムは UEFI モードにブートされます)
  +
  +
このページでは ESP のマウントポイントを {{ic|''esp''}} として表します (大抵の場合は {{ic|/efi}} か {{ic|/boot}} です) これは、システムのマウントポイントに [[chroot]] していることを前提としています。
  +
  +
{{man|1|bootctl}} を使用して EFI システムパーティションに ''systemd-boot'' をインストールします:
  +
  +
# bootctl install
  +
  +
これにより、''systemd-boot'' UEFI ブートマネージャーが ESP にコピーされ、その UEFI ブートエントリが作成され、UEFI ブート順序の最初に設定されます。
  +
  +
* x64 UEFI では、{{ic|/usr/lib/systemd/boot/efi/systemd-bootx64.efi}} は {{ic|''esp''/EFI/systemd/systemd-bootx64.efi}} と {{ic|''esp''/EFI/BOOT/BOOTX64.EFI}} にコピーされます。
  +
* IA32 UEFI では、{{ic|/usr/lib/systemd/boot/efi/systemd-bootia32.efi}} は {{ic|''esp''/EFI/systemd/systemd-bootia32.efi}} と {{ic|''esp''/EFI/BOOT/BOOTIA32.EFI}} にコピーされます。
   
  +
UEFI ブートエントリは "Linux Boot Manager" と呼ばれ、UEFI のビット数によって、ESP 上の {{ic|EFI}systemd-bootx64.efi}} か {{ic|EFI}systemd-bootia32.efi}} を指します。
上のコマンドで自動的に gummiboot のバイナリがあなたの EFI System Partition にコピーされ EFI Boot Manager にブートエントリが作成されます。EFI で起動していない場合、ブートエントリの作成は失敗します。ただし gummiboot のバイナリを ESP 内にある EFI バイナリのデフォルトの配置場所 (x64 環境では {{ic|/boot/EFI/Boot/BOOTX64.EFI}}) にコピーすれば gummiboot を起動することは可能です。インストール作業を一度でも完了すれば、パッケージのアップデート中 {{Pkg|gummiboot}} の post_install スクリプトによって自動で更新がなされます。
 
   
 
{{Note|
 
{{Note|
  +
* {{ic|bootctl install}} を実行すると、''systemd-boot'' は ESP を {{ic|/efi}},{{ic|/boot}},{{ic|/boot/efi}} に配置しようとします。{{ic|''esp''}} を別の場所に設定するには、{{ic|1=--esp-path=''esp''}} オプションを渡す必要があります。(詳細は {{man|1|bootctl|OPTIONS}} を参照)
* gummiboot コマンドはあなたの EFI System Partition が {{ic|/boot}} にマウントされているとみなします。あなたの ESP が {{ic|/boot/efi}} にマウントされているときは {{ic|--path}} スイッチを追加して gummiboot のインストールコマンドを呼び出して下さい。また、マウントポイントが異なると gummiboot は自動で更新できないので、パッケージを更新した後は {{ic|1=gummiboot --path=/boot/efi update}} を実行する必要があります。さらにカーネルや initramfs が ESP にコピーされているか確認してください、gummiboot は他のパーティションから EFI バイナリをロードすることができません。以上のことから gummiboot を使う時は ESP を {{ic|/boot}} にマウントすることを強く推奨します。この記事ではあなたの ESP が {{ic|/boot}} にマウントされていると仮定しています。
 
  +
* systemd-boot'' をインストールすると既存の {{ic|''esp''/EFI/BOOT/BOOTX64.EFI}} は上書きされます。(または、{{ic|''esp''/EFI/BOOT/BOOTIA32.EFI}} の IA32 UEFI)、例えば Microsoft 版のファイルなどです。
  +
}}
   
  +
インストールを完了するには、''systemd-boot'' を[[systemd-boot#設定|設定]]します。
* {{ic|gummiboot}} がブートエントリの作成に失敗したときは、[[Unified_Extensible_Firmware_Interface#Requirements_for_UEFI_Variables_support_to_work_properly|ここ]]に記述されている要件が全て満たされているか確認してください。}}
 
   
  +
=== XBOOTLDR を使用したインストール ===
== 設定 ==
 
   
  +
カーネルと initramfs を ESP から分離するために、"Linux extended boot" タイプ (XBOOTLDR) の別の [[パーティショニング#/boot|/boot パーティション]]を作成することができます。これは、既存の [[EFI システムパーティション|ESP]] が小さすぎる [[Windows と Arch のデュアルブート]] 時に特に役立ちます。
基本的な設定は {{ic|/boot/loader/loader.conf}} に記述します、2つの設定オプションが使えます:
 
   
  +
通常どおり ESP を作成し、同じ物理ドライブに XBOOTLDR 用の別のパーティションを作成します。XBOOTLDR のパーティションタイプ GUID は {{ic|"bc13c2ff-59e6-4262-a352-b275fd6f7172}} である必要があります。XBOOTLDR パーティションのサイズは、インストールする全てのカーネルを収納できる 十分な大きさが必要です。
* {{ic|default}} – 選択するデフォルトエントリ ({{ic|.conf}} を付けない); {{ic|arch-*}} のようにワイルドカードを使うことができます
 
   
  +
{{Note|
* {{ic|timeout}} – メニューのタイムアウト秒数。この値が設定されていない場合、起動中にスペースキーを押した時だけメニューが表示されます。
 
  +
* systemd-boot は、 ESP の場合のようにファイルシステムチェックを行いません。 したがって、他のファイルシステムを使用することは可能ですが、 UEFI 実装が起動中にそれを読み取ることができる場合に限ります。
  +
* "fast boot" モードが有効の場合、UEFI ファームウェアは ESP 以外のパーティションのロードをスキップすることがあります。これにより、''システム起動'' が XBOOTLDR パーティション上のエントリを見つけられなくなる可能性があります。XBOOTLDRを使用するには、"fast boot" を無効にする必要があります。
  +
* XBOOTLDR パーティションは、system-boot が認識できるように ESP と同じ物理ディスク上になければならない場合があります。
  +
}}
  +
  +
インストール中に、ESP を {{ic|/mnt/efi}} にマウントし、 {{ic|''boot''}} を {{ic|/mnt/boot}} にマウントします。
  +
  +
chroot になったら、次のコマンドを使用します:
  +
  +
# bootctl --esp-path=/efi --boot-path=/boot install
  +
  +
インストールを完了するには ''systemd-boot'' を[[#設定|設定]]します。
  +
  +
=== EFI ブートマネージャの更新 ===
  +
  +
''systemd-boot'' の新しいバージョンがある場合は、ユーザーが任意でブートマネージャを再インストールできます。手動で実行することも、pacman フックを使用して更新を自動的にトリガすることもできます。その後、2つのアプローチについて説明します。
  +
  +
{{Note|ブートマネージャーはスタンドアロン EFI 実行可能ファイルで、任意のバージョンを使用してシステムをブートできます (pacman は systemd-boot 自体ではなく、systemd-boot インストーラーのみをインストールするため、部分的な更新は適用されません。) ただし、新しいバージョンでは新しい機能が追加されたりバグが修正されたりする可能性があるため、いずれにしても更新することをお勧めします。}}
  +
  +
==== 手動で更新 ====
  +
  +
''bootctl'' を使用して ''systemd-boot'' を更新:
  +
  +
# bootctl update
  +
  +
{{Note|{{ic|bootctl install}} と同様に、''systemd-boot''は ESP を {{ic|/efi}}、{{ic|/boot}}、{{ic|/boot/efi}} に配置しようとします。{{ic|''esp''}} を別の場所に設定するには、{{ic|1=--esp-path=''esp''}} オプションを渡す必要があります。}}
  +
  +
==== 自動で更新 ====
  +
  +
===== systemd サービス =====
  +
  +
バージョン 250 以降、{{Pkg|systemd}} には {{ic|systemd-boot-update.service}} が同梱されています。このサービスを [[有効]] にすると、次回の起動時にブートローダーが更新されます。
  +
  +
{{Warning|[[セキュアブート]] を有効にしている場合、アップデート後にブートローダに署名する必要があります。その方法の例は以下の [[systemd-boot#pacman フック|pacman フック]] を見て下さい。}}
  +
{{Tip|{{ic|bootctl install}} と {{ic|bootctl update}} は {{ic|.efi}} ファイルよりも先に {{ic|/usr/lib/systemd/boot/efi/}} 配下の {{ic|.efi.signed}} ファイルを検索します。{{ic|/usr/lib/systemd/boot/efi/}} 配下の {{ic|.efi.signed}} ブートローダーにより、{{ic|systemd-boot-update.service}} はセキュアブート署名ツールを起動せずにブートローダを更新できます。(詳細は {{man|1|bootctl|SIGNED .EFI FILES}} を参照してください。)}}
  +
  +
===== Pacman フック =====
  +
  +
{{AUR|systemd-boot-pacman-hook}} パッケージは {{Pkg|systemd}} がアップグレードされる度に実行される pacman フックを追加します。
  +
  +
systemd-boot-pacman-hook をインストールするのではなく、次のファイルを {{ic|/etc/pacman.d/hooks/}} に手動で配置することをお勧めします:
  +
  +
{{hc|/etc/pacman.d/hooks/95-systemd-boot.hook|2=
  +
[Trigger]
  +
Type = Package
  +
Operation = Upgrade
  +
Target = systemd
  +
  +
[Action]
  +
Description = Gracefully upgrading systemd-boot...
  +
When = PostTransaction
  +
Exec = /usr/bin/systemctl restart systemd-boot-update.service
  +
}}
  +
  +
[[セキュアブート]] を有効にしている場合は、パッケージのアップグレードのたびにブートマネージャーに自動的に署名する pacman フックを追加するとよいでしょう:
  +
  +
{{hc|/etc/pacman.d/hooks/80-secureboot.hook|2=
  +
[Trigger]
  +
Operation = Install
  +
Operation = Upgrade
  +
Type = Path
  +
Target = usr/lib/systemd/boot/efi/systemd-boot*.efi
  +
  +
[Action]
  +
Description = Signing systemd-boot EFI binary for Secure Boot
  +
When = PostTransaction
  +
Exec = /bin/sh -c 'while read -r i; do sbsign --key ''/path/to/keyfile.key'' --cert ''/path/to/certificate.crt'' "$i"; done;'
  +
Depends = sh
  +
Depends = sbsigntools
  +
NeedsTargets
  +
}}
  +
  +
{{ic|''/path/to/keyfile.key''}} と {{ic|''/path/to/certificate.crt''}} をそれぞれ署名鍵と証明書に置き換えてください。このフックのより良い理解については、{{man|1|sbsign}} を参照してください。
  +
  +
{{Tip|{{Pkg|sbctl}} を使用している場合、データベースに登録されているファイルの再登録は {{ic|/usr/share/libalpm/hooks/zz-sbctl.hook}} で提供されているフックを使って自動的に行われます。ブートチェインに必要なファイルを最初に登録することを忘れないでください。}}
  +
  +
== 設定 ==
  +
  +
=== ローダー設定 ===
  +
  +
ローダーの設定は {{ic|''esp''/loader/loader.conf}} ファイルに保存されます。詳細は、{{man|5|loader.conf|OPTIONS}} を参照してください。
   
  +
ローダーの設定例を以下に示します:
例:
 
   
{{hc|/boot/loader/loader.conf|
+
{{hc|''esp''/loader/loader.conf|
default arch
+
default arch.conf
 
timeout 4
 
timeout 4
  +
console-mode max
  +
editor no
 
}}
 
}}
   
  +
{{Tip|
オプションは両方ともブートメニューで変更するこができ、EFI 変数として保存されます。
 
  +
* systemd-boot はインデント用のタブを受け入れません。代わりにスペースを使用してください。
  +
* {{ic|default}} と {{ic|timeout}} はブートメニューで変更することができ、変更した場合は EFI 変数として保存されます。上記のオプションよりも優先して設定されます。
  +
* ​{{ic|bootctl set-default ""}} を使用すると、 {{ic|default}} オプションに優先して EFI 変数をクリアできます。
  +
* 基本的なローダーの設定ファイルは {{ic|/usr/share/systemd/bootctl/loader.conf}} に存在します。
  +
* {{ic|timeout 0}} を設定している場合、{{ic|Space}} を押すことでブートメニューにアクセスできます。
  +
* 基本的なローダー設定ファイルは、{{ic|/usr/share/systemd/bootctl/loader.conf}} にあります。
  +
* ブートローダー(エントリ選択中)が歪んで表示される場合や、誤った解像度が使用されている場合は、{{ic|console-mode}} を {{ic|auto}}(最適な解像度を選択するためのヒューリスティックスを使用)、{{ic|keep}}(ファームウェアが提供する解像度を維持)、または {{ic|2}}(最初の非 UEFI 標準解像度を選択しようと試みる)に設定してみることができます。}}
   
== トエントリの追加 ==
+
=== ローダーの追加 ===
Gummiboot は {{ic|/boot/loader/entries/*.conf}} にあるブートメニューのアイテムを検索します – それぞれのファイルにはひとつのブートエントリを含めなくてはなりません。利用できるオプションは:
 
   
  +
''bootctl'' は {{ic|''esp''/loader/entries/*.conf}} からブートメニューのアイテムを検索します – 各ファイルにそれぞれひとつだけローダーを記述してください。利用可能なオプション:
* {{ic|title}} – オペレーティングシステムの名前。'''必須。'''
 
   
  +
* {{ic|title}} – オペレーティングシステムの名前。'''必須。'''
 
* {{ic|version}} – カーネルバージョン、同じ title のエントリが複数存在する場合にのみ表示されます。任意。
 
* {{ic|version}} – カーネルバージョン、同じ title のエントリが複数存在する場合にのみ表示されます。任意。
 
 
* {{ic|machine-id}} – {{ic|/etc/machine-id}} のマシン識別子、title と version が同じエントリが複数存在する場合にのみ表示されます。任意。
 
* {{ic|machine-id}} – {{ic|/etc/machine-id}} のマシン識別子、title と version が同じエントリが複数存在する場合にのみ表示されます。任意。
  +
* {{ic|efi}} – 起動する EFI プログラム、ESP ({{ic|/boot}}) からの相対パス。例: {{ic|/vmlinuz-linux}}。このオプションか {{ic|linux}} (下を参照) のどちらか一方が'''必須'''です。
  +
* {{ic|options}} – EFI プログラムに渡すコマンドラインオプションまたは[[カーネルパラメータ]]。任意ですが、Linux を起動する場合 {{ic|1=initrd=''efipath''}} と {{ic|1=root=''dev''}} が最低限必要になります。
   
* {{ic|efi}} – 起動する EFI プログラムESP ({{ic|/boot}}) からの相対パス; 例: {{ic|/vmlinuz-linux}}。このオプションか {{ic|linux}} (下を参照) のどちらか一方'''必須'''です
+
Linux 起動する場合、{{ic|efi}} {{ic|options}} を使う代わりに以下のオプションが使用きま:
  +
* {{ic|linux}} と {{ic|initrd}} で ESP の適切なファイルの相対パスを指定します。例: {{ic|/vmlinuz-linux}}。この値は自動で {{ic|efi ''path''}} と {{ic|1=options initrd=''path''}} に翻訳されます – この文法は利便性のためにサポートされており機能に違いはありません。
   
  +
''arch_os'' というラベルが付いたパーティションから Arch を起動して Intel CPU の[[マイクロコード]]をロードするローダーファイルの例:
* {{ic|options}} – EFI プログラムに渡すコマンドラインオプション。任意ですが、Linux を起動する場合 {{ic|1=initrd=''efipath''}} と {{ic|1=root=''dev''}} が最低限必要になります。
 
  +
{{hc|''esp''/loader/entries/arch.conf|2=
  +
title Arch Linux
  +
linux /vmlinuz-linux
  +
initrd /intel-ucode.img
  +
initrd /initramfs-linux.img
  +
options root="LABEL=''arch_os''" rw}}
   
  +
{{hc|''esp''/loader/entries/arch-fallback.conf|2=
Linux では、{{ic|linux ''path-to-vmlinuz''}} と {{ic|initrd ''path-to-initramfs''}} を指定することができます。この値は自動で {{ic|efi ''path''}} と {{ic|1=options initrd=''path''}} に翻訳されます – この文法は利便性のためにサポートされており機能に違いはありません。
 
  +
title Arch Linux (fallback initramfs)
  +
linux /vmlinuz-linux
  +
initrd /intel-ucode.img
  +
initrd /initramfs-linux-fallback.img
  +
options root="LABEL=''arch_os''" rw
  +
}}
   
  +
''bootctl'' は自動的に "Windows Boot Manager" ({{ic|/EFI/Microsoft/Boot/Bootmgfw.efi}}), "EFI Shell" ({{ic|/shellx64.efi}}), "EFI Default Loader" ({{ic|/EFI/BOOT/bootx64.efi}}) をチェックします。また、{{ic|/EFI/Linux}} にカーネルファイルが存在しないかもチェックされます。これらが検出された場合、自動的に適切なエントリが生成されます ({{ic|auto-windows}}, {{ic|auto-efi-shell}}, {{ic|auto-efi-default}})。これらのエントリを手動でローダー設定する必要はありません。ただし、([[rEFInd]] など) 他の EFI アプリケーションは自動検出されないため、Linux カーネルを起動するには、手動で設定してエントリを作成する必要があります。
Arch Linux のエントリのサンプル:
 
   
  +
{{Note|
{{hc|/boot/loader/entries/arch.conf|2=
 
  +
* Windows とデュアルブートする場合、Windows のデフォルトオプションである[[Windows と Arch のデュアルブート#高速スタートアップ|高速スタートアップ]]を無効にすることを強く推奨します。
title Arch Linux
 
  +
* 必要な場合は {{ic|initrd}} で Intel のマイクロコードをロードしてください。例は[[マイクロコード#systemd-boot]] を参照。
linux /vmlinuz-linux
 
  +
* {{ic|1=blkid -s PARTUUID -o value /dev/sd''xY''}} コマンドを使うことで root パーティションの PARTUUID を確認できます。{{ic|''x''}} はデバイス文字、{{ic|''Y''}} はパーティション番号に置き換えて下さい。確認するのは root パーティションだけで大丈夫です。{{ic|''esp''}} は確認する必要がありません。
initrd /initramfs-linux.img
 
options root=PARTUUID=14420948-2cea-4de7-b042-40f67c618660 rw
 
 
}}
 
}}
   
  +
{{Tip|
上の例にある PARTUUID/PARTLABEL は GPT パーティションを識別しています。ファイルシステムを識別する UUID/LABEL とは異なっていることに注意してください。PARTUUID/PARTLABEL には他のファイルシステムでパーティションをフォーマットしなおしても値が変わらないという利点があります。またパーティションにファイルシステムがない (もしくは LABEL をサポートしていない LUKS を使っている) 場合などにも有用です。
 
  +
* 設定済みのブートエントリは {{ic|bootctl list}} コマンドで確認できます。
  +
* サンプルエントリファイルが {{ic|/usr/share/systemd/bootctl/arch.conf}} に存在します。
  +
* [[LVM]], [[LUKS]], [[dm-crypt]] などで必要な[[カーネルパラメータ]]についてはそれぞれのページを確認してください。
  +
}}
   
  +
==== EFI シェルや他の EFI アプリ ====
また、{{ic|\EFI\arch\grub.efi}} など他の EFI プログラムを追加することもできます。
 
   
  +
[https://wiki.archlinux.jp/index.php/Unified_Extensible_Firmware_Interface#UEFI_.E3.82.B7.E3.82.A7.E3.83.AB EFI シェル] と [https://wiki.archlinux.jp/index.php/REFInd#.E3.83.84.E3.83.BC.E3.83.AB 他のEFIアプリケーション] を ESP にインストールした場合は、次のスニペットを使用できます。
{{Note|Gummiboot は Windows のインストール ({{ic|\EFI\Microsoft\Boot\Bootmgfw.efi}}) や UEFI Shell ({{ic|\shellx64.efi}}) のバイナリを自動でチェックして表示します。従って手動でこれらのエントリを作成する必要はありません。}}
 
   
  +
{{Note|{{ic|efi}} 行のファイルパスパラメータは、"esp" マウントポイントを基準にしています。 {{ic|/boot}} にマウントされていて、EFI バイナリが {{ic|/boot/EFI/xx.efi}} と {{ic|/boot/yy.efi}} にある場合は、次のようになります。 パラメータをそれぞれ {{ic|efi/EFI/xx.efi}} および {{ic|efi/yy.efi}} として指定します。}}
== ブートメニュー ==
 
   
  +
カスタム UEFI シェルローダーのロード例:
=== キー一覧 ===
 
   
  +
{{hc|''esp''/loader/entries/uefi-shell-v1-x86_64.conf|2=
メニューの中では以下のキーが使われます:
 
  +
title UEFI Shell x86_64 v1
* {{ic|Up/Down}} - エントリの選択
 
  +
efi /EFI/shellx64_v1.efi
* {{ic|Enter}} - 選択したエントリの起動
 
  +
}}
* {{ic|d}} - (不揮発の EFI 変数に保存された) デフォルトエントリを選択して起動
 
  +
* {{ic|t/T}} - (不揮発の EFI 変数に保存された) タイムアウトを調整
 
  +
{{hc|''esp''/loader/entries/uefi-shell-v2-x86_64.conf|2=
* {{ic|e}} - カーネルコマンドラインを編集
 
  +
title UEFI Shell x86_64 v2
* {{ic|q}} - 終了
 
  +
efi /EFI/shellx64_v2.efi
* {{ic|v}} - gummiboot と UEFI のバージョンを表示
 
  +
}}
* {{ic|p}} - 現在の設定を表示
 
  +
* {{ic|h}} - キーマップを表示
 
  +
==== 別のディスクから起動 ====
  +
  +
''systemd-boot'' は ESP や XBOOTLDR パーティション以外のパーティションからバイナリを起動することはできませんが、外部スクリプトを実行して起動することは可能です。
  +
  +
まず、{{Pkg|edk2-shell}} をインストールする必要があります。(使用するインタプリタ) をインストールし、EFI シェル (上記で説明) を使用して、''map'' コマンドで '''FS alias''' (例: HD0a66666a2) と保存先の EFI ファイルのフルパス (例:EFIMicroBoot\Bootmgfw.efi) を控えておきます。
  +
  +
その後、'exit' コマンドを使用して、Linux にブートバックし、新しいエントリを作成することができます。
  +
これを行うには、まずマウントポイント ''esp'' のルートに、FS alias、コロン、EFI パスを含む ''.nsh'' ファイル名を作成する必要があります(例)
  +
  +
{{hc|''esp''/windows.nsh|
  +
HD0a66666a2:EFI\Microsoft\Boot\Bootmgfw.efi
  +
}}
  +
  +
このファイルを作成したら、スクリプトを実行するためのローダーエントリの作成に進むことができます。
  +
  +
{{hc|''esp''/loader/entries/windows.conf|
  +
title Windows
  +
efi /shellx64.efi
  +
options -nointerrupt -noconsolein -noconsoleout windows.nsh
  +
}}
  +
  +
''efi'' パスが ''esp'' パーティション内の edk2-shell がコピーされた場所と一致し、オプションの最後の引数が ''esp'' パーティションのルート内の ''.nsh'' ファイル名と一致することが重要です。また、edk2-shell の EFI ファイルを移動して、 ''systemd-boot'' のエントリ自動作成を回避できることにも注意してください。
  +
  +
=== EFI ファームウェア・セットアップの起動 ===
  +
  +
EFI ブート用に設定されたほとんどのシステムファームウェアは、UEFI ファームウェアセットアップでブートするために独自の [[efibootmgr]] エントリを追加します。
  +
  +
=== ハイバネーション ===
  +
  +
[[サスペンドとハイバネート]]の記事を参照してください。
  +
  +
=== パスワードで保護されたカーネルパラメータエディタ ===
  +
  +
{{ic|password}} 設定オプションをサポートしている {{AUR|systemd-boot-password}} をインストールすることもできます。{{ic|sbpctl generate}} を使ってオプションで指定する値を生成できます。
  +
  +
''systemd-boot-password'' は以下のコマンドでインストールしてください:
  +
  +
{{bc|1=# sbpctl install ''esp''}}
  +
  +
カーネルパラメータを編集する前にパスワードの入力が求められるようになります。
  +
  +
== ヒントとテクニック ==
  +
  +
=== ブートメニューで使用できるキー ===
  +
  +
ブートメニューで使用できるキー割り当てについては、{{man|7|systemd-boot|KEY BINDINGS}} を参照してください。
  +
  +
=== 再起動後の起動対象を選択する ===
  +
  +
ブートマネージャーは systemctl コマンドに統合されており、再起動後に起動させるオプションを選択できます。例えば、カスタムカーネルのエントリファイルが {{ic|''esp''/loader/entries/arch-custom.conf}} にあるとき、次のようにするとデフォルト設定はそのままにカスタムカーネルが起動します:
  +
  +
$ systemctl reboot --boot-loader-entry=arch-custom
  +
<!-- To see a list of possible entries pass the {{ic|--help}} option. -->
  +
  +
マザーボードのファームウェアを起動させるときは次のようにします:
  +
  +
$ systemctl reboot --firmware-setup
  +
  +
=== ユニファイドカーネルイメージ を使う ===
  +
  +
systemd-boot は {{ic|''esp''/EFI/Linux/}} 内の unified kernel image を検索します。
  +
[https://systemd.io/BOOT_LOADER_SPECIFICATION#type-2-efi-unified-kernel-images unified kernel image] はカーネル、initrd、カーネルのコマンドライン、{{ic|/etc/os-release}} およびスプラッシュスクリーンを単一ファイルに格納したもので、[[セキュアブート]] のための署名が容易に可能です。
  +
  +
作成するには、カーネルコマンドラインを指定した上で次のようにします:
  +
  +
{{bc|1=
  +
$ objcopy \
  +
--add-section .osrel="/usr/lib/os-release" --change-section-vma .osrel=0x20000 \
  +
--add-section .cmdline="kernel-command-line.txt" --change-section-vma .cmdline=0x30000 \
  +
--add-section .splash="/usr/share/systemd/bootctl/splash-arch.bmp" --change-section-vma .splash=0x40000 \
  +
--add-section .linux="vmlinuz-file" --change-section-vma .linux=0x2000000 \
  +
--add-section .initrd="initrd-file" --change-section-vma .initrd=0x3000000 \
  +
"/usr/lib/systemd/boot/efi/linuxx64.efi.stub" "''linux''.efi"
  +
}}
  +
  +
作成した {{ic|''linux''.efi}} を [https://wiki.archlinux.jp/index.php/%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2%E3%83%96%E3%83%BC%E3%83%88#.E8.87.AA.E5.88.86.E3.81.A7.E7.BD.B2.E5.90.8D.E3.81.97.E3.81.9F.E9.8D.B5.E3.82.92.E4.BD.BF.E3.81.86 署名] することもできます。
  +
  +
{{ic|''linux''.efi}} を {{ic|''esp''/EFI/Linux/}} にコピーしてください。
  +
  +
=== Grml on ESP ===
  +
  +
{{Note|以下の手順は、Grml 専用ではありません。​若干の調整で他のソフト (例: [http://www.system-rescue-cd.org/ SystemRescueCD]) のインストールも可能です。}}
  +
  +
[https://grml.org/ Grml] ​は、システム管理とレスキュー用のソフトウェアを集めた小さなライブシステムです。
  +
  +
​Grml を ESP にインストールするには、カーネル {{ic|vmlinuz}}、 initramfs {{ic|initrd.img}}、 圧縮イメージ {{ic|grml64-small.squashfs}} を iso ファイルから ESP にコピーするだけです。そのためには、まず [https://grml.org/grml64-small.iso] ファイルをダウンロードして(マウントポイントは以降 ''mnt'' と表記される) ファイルをマウントします。​カーネルと initramfs は {{ic|''mnt''/boot/grml6 small/}} にあり、圧縮されたイメージは {{ic|''mnt''/live/grml64-small/}} にあります。
  +
  +
​次に、Grml 用のディレクトリを ESP に作成します:
  +
  +
# mkdir -p ''esp''/grml
  +
  +
​上記のファイルをコピーします:
  +
  +
# cp ''mnt''/boot/grml64small/vmlinuz ''esp''/grml
  +
# cp ''mnt''/boot/grml64small/initrd.img ''esp''/grml
  +
# cp ''mnt''/live/grml64-small/grml64-small.squashfs ''esp''/grml
  +
  +
​最後のステップで、システムブートローダー用のエントリを作成します。 {{ic|''esp''/loader/entries}} 次の内容の {{ic|grml.conf}} ファイルを作成します:
  +
  +
{{hc|''esp''/loader/entries/grml.conf|2=
  +
title Grml Live Linux
  +
linux /grml/vmlinuz
  +
initrd /grml/initrd.img
  +
options apm=power-off boot=live live-media-path=/grml/ nomce net.ifnames=0}}
  +
  +
​使用可能なブートオプションの概要については、 [http://git.grml.org/?p=grml-live.git;a=blob_plain;f=templates/GRML/grml-cheatcodes.txt;hb=HEAD cheatcode for Grml]
  +
  +
=== BIOS システムでの systemd-boot ===
   
  +
[https://systemd.io/BOOT_LOADER_SPECIFICATION/ ブートローダーの仕様] に従う BIOS システム用のブートローダーが必要な場合は、 BIOS システムで systemd-boot を押してサービスを開始できます。 [[Clover]] ブートローダーは BIOS システムからの起動をサポートし、シミュレートされた EFI 環境を提供します。
以下のホットキーを、起動中やメニューで押すことで、特定のエントリを直接起動します:
 
* {{ic|l}} - Linux
 
* {{ic|w}} - Windows
 
* {{ic|a}} - OS X
 
* {{ic|s}} - EFI Shell
 
* {{ic|1-9}} - エントリの数字
 
   
 
== トラブルシューティング ==
 
== トラブルシューティング ==
   
==== efibootmgr を使って手ントリを追加する ====
+
=== BIOS モードで起後にイール ===
   
  +
{{Warning|こちらの起動方法は推奨されません。}}
{{ic|gummiboot install}} コマンドが失敗した場合、{{ic|efibootmgr}} ユーティリティを使って EFI ブートエントリを手動で作成することができます:
 
   
  +
BIOS モードで OS を起動したいときも ''systemd-boot'' をインストールすることは可能です。ただし、起動時に ''systemd-boot'' の EFI ファイルを実行するようにファームウェアを設定する必要があります:
# efibootmgr -c -d /dev/sdX -p Y -l /EFI/gummiboot/gummibootx64.efi -L "Gummiboot"
 
  +
* EFI シェルを使用する。
  +
* ファームウェアのインターフェイスから起動時にロードされる EFI ファイルを設定する。
  +
  +
設定できる場合、インストールは簡単です: EFI シェルやファームウェアの設定インターフェイスを開いて、マシンのデフォルトの EFI ファイルを {{ic|''esp''/EFI/systemd/systemd-bootx64.efi}} (32ビット環境の場合 {{ic|systemd-bootia32.efi}}) に変更してください。
  +
  +
{{Note|Dell の Latitude シリーズなどでは、EFI ブートを設定するために必要な全てがファームウェアのインターフェイスに揃っており、EFI シェルではコンピュータの ROM に書き込みを行えません。}}
  +
  +
=== efibootmgr を使って手動エントリを追加する ===
  +
  +
{{ic|bootctl install}} コマンドが失敗した場合、{{Pkg|efibootmgr}} ユーティリティを使って EFI ブートエントリを手動で作成することができます:
  +
  +
# efibootmgr -c -d /dev/sdX -p Y -l "\EFI\systemd\systemd-bootx64.efi" -L "Linux Boot Manager"
  +
  +
{{ic|/dev/sdXY}} は [[EFI システムパーティション]]に置き換えてください。
  +
  +
{{Note|EFI イメージのパスでは区切り文字としてバックスラッシュ ({{ic|\}}) を使用します。}}
  +
  +
=== Windows の bcdedit を使用した手動入力 ===
  +
  +
何らかの理由で Windows から EFI ブートエントリを作成する必要がある場合は、管理者プロンプトから次のコマンドを使用してください。
  +
  +
# bcdedit /copy {bootmgr} /d "Linux Boot Manager"
  +
# bcdedit /set {guid} path \EFI\systemd\systemd-bootx64.efi
  +
  +
{{ic|{guid} }} を最初のコマンドによってリターンされた ID に置き換えます。これをデフォルトのエントリとして設定するには:
  +
  +
# bcdedit /default {guid}
   
 
=== Windows をアップグレードした後にメニューが表示されない ===
 
=== Windows をアップグレードした後にメニューが表示されない ===
   
  +
[[Unified Extensible Firmware Interface#Windows によってブート順序が変わってしまう]]を見てください。
Windows 8 から Windows 8.1 にアップグレードした場合などに、ブートメニューが表示されなくなることがあります:
 
  +
* Secure Boot (UEFI 設定) と Fast Startup (Windows の電源オプション設定) が両方とも無効になっていることを確認してください。
 
  +
=== Windows BitLocker TPM ロック解除のサポートを追加 ===
* Windows Boot Manager よりも Linux Boot Manager が UEFI で優先されていることを確認してください (Hard Drive Disk Priority などの UEFI 設定)。
 
  +
  +
BitLocker による回復キーの要求を停止するには、次の行を ''loader.conf'' に追加します。
  +
  +
{{hc|''esp''/loader/loader.conf|
  +
reboot-for-bitlocker yes
  +
}}
  +
  +
これにより、''BootNext'' UEFI 変数が設定され、BitLocker が回復キーを必要とせずに ''Windows ブートマネージャー'' がロードされます。これは 1 回限りの変更であり、''systemd-boot'' がデフォルトのブートローダーのままです。Windows が自動検出された場合は、エントリとして指定する必要はありません。
  +
  +
これは実験的な機能なので、必ず {{man|5|loader.conf}} を参照してください。
   
 
== 参照 ==
 
== 参照 ==
   
* http://freedesktop.org/wiki/Software/gummiboot/
+
* https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/
  +
* https://github.com/systemd/systemd/tree/master/src/boot/efi
  +
* https://bbs.archlinux.org/viewtopic.php?id=254374
  +
* https://systemd.io/BOOT_LOADER_SPECIFICATION/

2024年4月24日 (水) 20:20時点における最新版

関連記事

systemd-boot (旧名 gummiboot。ドイツ語で「ゴムボート」)は、 設定された EFI イメージを実行するシンプルな UEFI ブートマネージャーです。デフォルトのエントリは設定されたパターン (glob) または矢印キーで操作する画面上のメニューによって選択されます。systemd に含まれており、Arch システムにデフォルトでインストールされます。

systemd-boot は EFI 実行可能ファイル (EFISTUBUEFI シェルGRUBWindows ブートマネージャ) のみを起動できることに注意してください。

サポートされているファイルシステム

systemd-boot はファイルシステムのサポートを ファームウェア から引き継ぎます (少なくとも FAT12、FAT16、FAT32) さらに、esp/EFI/systemd/drivers/ にある UEFI ドライバ を全てロードします。

インストール

systemd-boot は、base メタパッケージの依存関係である systemd パッケージとともに出荷されるため、追加のパッケージを手動でインストールする必要はありません。

EFI ブートマネージャのインストール

systemd-boot の EFI ブートマネージャをインストールする場合、まず UEFI モードでシステムが起動しているかどうか、UEFI 変数 が利用できるかどうか確かめてください。efivar --list コマンドを実行することでチェックできます。または、efivar がインストールされていない場合は、ls /sys/firmware/efi/efivars を実行してください (ディレクトリが存在する場合、システムは UEFI モードにブートされます)

このページでは ESP のマウントポイントを esp として表します (大抵の場合は /efi/boot です) これは、システムのマウントポイントに chroot していることを前提としています。

bootctl(1) を使用して EFI システムパーティションに systemd-boot をインストールします:

# bootctl install

これにより、systemd-boot UEFI ブートマネージャーが ESP にコピーされ、その UEFI ブートエントリが作成され、UEFI ブート順序の最初に設定されます。

  • x64 UEFI では、/usr/lib/systemd/boot/efi/systemd-bootx64.efiesp/EFI/systemd/systemd-bootx64.efiesp/EFI/BOOT/BOOTX64.EFI にコピーされます。
  • IA32 UEFI では、/usr/lib/systemd/boot/efi/systemd-bootia32.efiesp/EFI/systemd/systemd-bootia32.efiesp/EFI/BOOT/BOOTIA32.EFI にコピーされます。

UEFI ブートエントリは "Linux Boot Manager" と呼ばれ、UEFI のビット数によって、ESP 上の EFI}systemd-bootx64.efiEFI}systemd-bootia32.efi を指します。

ノート:
  • bootctl install を実行すると、systemd-boot は ESP を /efi,/boot,/boot/efi に配置しようとします。esp を別の場所に設定するには、--esp-path=esp オプションを渡す必要があります。(詳細は bootctl(1) § OPTIONS を参照)
  • systemd-boot をインストールすると既存の esp/EFI/BOOT/BOOTX64.EFI は上書きされます。(または、esp/EFI/BOOT/BOOTIA32.EFI の IA32 UEFI)、例えば Microsoft 版のファイルなどです。

インストールを完了するには、systemd-boot設定します。

XBOOTLDR を使用したインストール

カーネルと initramfs を ESP から分離するために、"Linux extended boot" タイプ (XBOOTLDR) の別の /boot パーティションを作成することができます。これは、既存の ESP が小さすぎる Windows と Arch のデュアルブート 時に特に役立ちます。

通常どおり ESP を作成し、同じ物理ドライブに XBOOTLDR 用の別のパーティションを作成します。XBOOTLDR のパーティションタイプ GUID は "bc13c2ff-59e6-4262-a352-b275fd6f7172 である必要があります。XBOOTLDR パーティションのサイズは、インストールする全てのカーネルを収納できる 十分な大きさが必要です。

ノート:
  • systemd-boot は、 ESP の場合のようにファイルシステムチェックを行いません。 したがって、他のファイルシステムを使用することは可能ですが、 UEFI 実装が起動中にそれを読み取ることができる場合に限ります。
  • "fast boot" モードが有効の場合、UEFI ファームウェアは ESP 以外のパーティションのロードをスキップすることがあります。これにより、システム起動 が XBOOTLDR パーティション上のエントリを見つけられなくなる可能性があります。XBOOTLDRを使用するには、"fast boot" を無効にする必要があります。
  • XBOOTLDR パーティションは、system-boot が認識できるように ESP と同じ物理ディスク上になければならない場合があります。

インストール中に、ESP を /mnt/efi にマウントし、 boot/mnt/boot にマウントします。

chroot になったら、次のコマンドを使用します:

# bootctl --esp-path=/efi --boot-path=/boot install

インストールを完了するには systemd-boot設定します。

EFI ブートマネージャの更新

systemd-boot の新しいバージョンがある場合は、ユーザーが任意でブートマネージャを再インストールできます。手動で実行することも、pacman フックを使用して更新を自動的にトリガすることもできます。その後、2つのアプローチについて説明します。

ノート: ブートマネージャーはスタンドアロン EFI 実行可能ファイルで、任意のバージョンを使用してシステムをブートできます (pacman は systemd-boot 自体ではなく、systemd-boot インストーラーのみをインストールするため、部分的な更新は適用されません。) ただし、新しいバージョンでは新しい機能が追加されたりバグが修正されたりする可能性があるため、いずれにしても更新することをお勧めします。

手動で更新

bootctl を使用して systemd-boot を更新:

# bootctl update
ノート: bootctl install と同様に、systemd-bootは ESP を /efi/boot/boot/efi に配置しようとします。esp を別の場所に設定するには、--esp-path=esp オプションを渡す必要があります。

自動で更新

systemd サービス

バージョン 250 以降、systemd には systemd-boot-update.service が同梱されています。このサービスを 有効 にすると、次回の起動時にブートローダーが更新されます。

警告: セキュアブート を有効にしている場合、アップデート後にブートローダに署名する必要があります。その方法の例は以下の pacman フック を見て下さい。
ヒント: bootctl installbootctl update.efi ファイルよりも先に /usr/lib/systemd/boot/efi/ 配下の .efi.signed ファイルを検索します。/usr/lib/systemd/boot/efi/ 配下の .efi.signed ブートローダーにより、systemd-boot-update.service はセキュアブート署名ツールを起動せずにブートローダを更新できます。(詳細は bootctl(1) § SIGNED .EFI FILES を参照してください。)
Pacman フック

systemd-boot-pacman-hookAUR パッケージは systemd がアップグレードされる度に実行される pacman フックを追加します。

systemd-boot-pacman-hook をインストールするのではなく、次のファイルを /etc/pacman.d/hooks/ に手動で配置することをお勧めします:

/etc/pacman.d/hooks/95-systemd-boot.hook
[Trigger]
Type = Package
Operation = Upgrade
Target = systemd

[Action]
Description = Gracefully upgrading systemd-boot...
When = PostTransaction
Exec = /usr/bin/systemctl restart systemd-boot-update.service

セキュアブート を有効にしている場合は、パッケージのアップグレードのたびにブートマネージャーに自動的に署名する pacman フックを追加するとよいでしょう:

/etc/pacman.d/hooks/80-secureboot.hook
[Trigger]
Operation = Install
Operation = Upgrade
Type = Path
Target = usr/lib/systemd/boot/efi/systemd-boot*.efi

[Action]
Description = Signing systemd-boot EFI binary for Secure Boot
When = PostTransaction
Exec = /bin/sh -c 'while read -r i; do sbsign --key /path/to/keyfile.key --cert /path/to/certificate.crt "$i"; done;'
Depends = sh
Depends = sbsigntools
NeedsTargets

/path/to/keyfile.key/path/to/certificate.crt をそれぞれ署名鍵と証明書に置き換えてください。このフックのより良い理解については、sbsign(1) を参照してください。

ヒント: sbctl を使用している場合、データベースに登録されているファイルの再登録は /usr/share/libalpm/hooks/zz-sbctl.hook で提供されているフックを使って自動的に行われます。ブートチェインに必要なファイルを最初に登録することを忘れないでください。

設定

ローダー設定

ローダーの設定は esp/loader/loader.conf ファイルに保存されます。詳細は、loader.conf(5) § OPTIONS を参照してください。

ローダーの設定例を以下に示します:

esp/loader/loader.conf
default  arch.conf
timeout  4
console-mode max
editor   no
ヒント:
  • systemd-boot はインデント用のタブを受け入れません。代わりにスペースを使用してください。
  • defaulttimeout はブートメニューで変更することができ、変更した場合は EFI 変数として保存されます。上記のオプションよりも優先して設定されます。
  • bootctl set-default "" を使用すると、 default オプションに優先して EFI 変数をクリアできます。
  • 基本的なローダーの設定ファイルは /usr/share/systemd/bootctl/loader.conf に存在します。
  • timeout 0 を設定している場合、Space を押すことでブートメニューにアクセスできます。
  • 基本的なローダー設定ファイルは、/usr/share/systemd/bootctl/loader.conf にあります。
  • ブートローダー(エントリ選択中)が歪んで表示される場合や、誤った解像度が使用されている場合は、console-modeauto(最適な解像度を選択するためのヒューリスティックスを使用)、keep(ファームウェアが提供する解像度を維持)、または 2(最初の非 UEFI 標準解像度を選択しようと試みる)に設定してみることができます。

ローダーの追加

bootctlesp/loader/entries/*.conf からブートメニューのアイテムを検索します – 各ファイルにそれぞれひとつだけローダーを記述してください。利用可能なオプション:

  • title – オペレーティングシステムの名前。必須。
  • version – カーネルバージョン、同じ title のエントリが複数存在する場合にのみ表示されます。任意。
  • machine-id/etc/machine-id のマシン識別子、title と version が同じエントリが複数存在する場合にのみ表示されます。任意。
  • efi – 起動する EFI プログラム、ESP (/boot) からの相対パス。例: /vmlinuz-linux。このオプションか linux (下を参照) のどちらか一方が必須です。
  • options – EFI プログラムに渡すコマンドラインオプションまたはカーネルパラメータ。任意ですが、Linux を起動する場合 initrd=efipathroot=dev が最低限必要になります。

Linux を起動する場合、efioptions を使う代わりに以下のオプションが使用できます:

  • linuxinitrd で ESP の適切なファイルの相対パスを指定します。例: /vmlinuz-linux。この値は自動で efi pathoptions initrd=path に翻訳されます – この文法は利便性のためにサポートされており機能に違いはありません。

arch_os というラベルが付いたパーティションから Arch を起動して Intel CPU のマイクロコードをロードするローダーファイルの例:

esp/loader/entries/arch.conf
title   Arch Linux
linux   /vmlinuz-linux
initrd  /intel-ucode.img
initrd  /initramfs-linux.img
options root="LABEL=arch_os" rw
esp/loader/entries/arch-fallback.conf
title   Arch Linux (fallback initramfs)
linux   /vmlinuz-linux
initrd  /intel-ucode.img
initrd  /initramfs-linux-fallback.img
options root="LABEL=arch_os" rw

bootctl は自動的に "Windows Boot Manager" (/EFI/Microsoft/Boot/Bootmgfw.efi), "EFI Shell" (/shellx64.efi), "EFI Default Loader" (/EFI/BOOT/bootx64.efi) をチェックします。また、/EFI/Linux にカーネルファイルが存在しないかもチェックされます。これらが検出された場合、自動的に適切なエントリが生成されます (auto-windows, auto-efi-shell, auto-efi-default)。これらのエントリを手動でローダー設定する必要はありません。ただし、(rEFInd など) 他の EFI アプリケーションは自動検出されないため、Linux カーネルを起動するには、手動で設定してエントリを作成する必要があります。

ノート:
  • Windows とデュアルブートする場合、Windows のデフォルトオプションである高速スタートアップを無効にすることを強く推奨します。
  • 必要な場合は initrd で Intel のマイクロコードをロードしてください。例はマイクロコード#systemd-boot を参照。
  • blkid -s PARTUUID -o value /dev/sdxY コマンドを使うことで root パーティションの PARTUUID を確認できます。x はデバイス文字、Y はパーティション番号に置き換えて下さい。確認するのは root パーティションだけで大丈夫です。esp は確認する必要がありません。
ヒント:
  • 設定済みのブートエントリは bootctl list コマンドで確認できます。
  • サンプルエントリファイルが /usr/share/systemd/bootctl/arch.conf に存在します。
  • LVM, LUKS, dm-crypt などで必要なカーネルパラメータについてはそれぞれのページを確認してください。

EFI シェルや他の EFI アプリ

EFI シェル他のEFIアプリケーション を ESP にインストールした場合は、次のスニペットを使用できます。

ノート: efi 行のファイルパスパラメータは、"esp" マウントポイントを基準にしています。 /boot にマウントされていて、EFI バイナリが /boot/EFI/xx.efi/boot/yy.efi にある場合は、次のようになります。 パラメータをそれぞれ efi/EFI/xx.efi および efi/yy.efi として指定します。

カスタム UEFI シェルローダーのロード例:

esp/loader/entries/uefi-shell-v1-x86_64.conf
title  UEFI Shell x86_64 v1
efi    /EFI/shellx64_v1.efi
esp/loader/entries/uefi-shell-v2-x86_64.conf
title  UEFI Shell x86_64 v2
efi    /EFI/shellx64_v2.efi

別のディスクから起動

systemd-boot は ESP や XBOOTLDR パーティション以外のパーティションからバイナリを起動することはできませんが、外部スクリプトを実行して起動することは可能です。

まず、edk2-shell をインストールする必要があります。(使用するインタプリタ) をインストールし、EFI シェル (上記で説明) を使用して、map コマンドで FS alias (例: HD0a66666a2) と保存先の EFI ファイルのフルパス (例:EFIMicroBoot\Bootmgfw.efi) を控えておきます。

その後、'exit' コマンドを使用して、Linux にブートバックし、新しいエントリを作成することができます。 これを行うには、まずマウントポイント esp のルートに、FS alias、コロン、EFI パスを含む .nsh ファイル名を作成する必要があります(例)

esp/windows.nsh
HD0a66666a2:EFI\Microsoft\Boot\Bootmgfw.efi

このファイルを作成したら、スクリプトを実行するためのローダーエントリの作成に進むことができます。

esp/loader/entries/windows.conf
title  Windows
efi     /shellx64.efi
options -nointerrupt -noconsolein -noconsoleout windows.nsh

efi パスが esp パーティション内の edk2-shell がコピーされた場所と一致し、オプションの最後の引数が esp パーティションのルート内の .nsh ファイル名と一致することが重要です。また、edk2-shell の EFI ファイルを移動して、 systemd-boot のエントリ自動作成を回避できることにも注意してください。

EFI ファームウェア・セットアップの起動

EFI ブート用に設定されたほとんどのシステムファームウェアは、UEFI ファームウェアセットアップでブートするために独自の efibootmgr エントリを追加します。

ハイバネーション

サスペンドとハイバネートの記事を参照してください。

パスワードで保護されたカーネルパラメータエディタ

password 設定オプションをサポートしている systemd-boot-passwordAUR をインストールすることもできます。sbpctl generate を使ってオプションで指定する値を生成できます。

systemd-boot-password は以下のコマンドでインストールしてください:

# sbpctl install esp

カーネルパラメータを編集する前にパスワードの入力が求められるようになります。

ヒントとテクニック

ブートメニューで使用できるキー

ブートメニューで使用できるキー割り当てについては、systemd-boot(7) § KEY BINDINGS を参照してください。

再起動後の起動対象を選択する

ブートマネージャーは systemctl コマンドに統合されており、再起動後に起動させるオプションを選択できます。例えば、カスタムカーネルのエントリファイルが esp/loader/entries/arch-custom.conf にあるとき、次のようにするとデフォルト設定はそのままにカスタムカーネルが起動します:

$ systemctl reboot --boot-loader-entry=arch-custom

マザーボードのファームウェアを起動させるときは次のようにします:

$ systemctl reboot --firmware-setup

ユニファイドカーネルイメージ を使う

systemd-boot は esp/EFI/Linux/ 内の unified kernel image を検索します。 unified kernel image はカーネル、initrd、カーネルのコマンドライン、/etc/os-release およびスプラッシュスクリーンを単一ファイルに格納したもので、セキュアブート のための署名が容易に可能です。

作成するには、カーネルコマンドラインを指定した上で次のようにします:

$ objcopy \
    --add-section .osrel="/usr/lib/os-release" --change-section-vma .osrel=0x20000 \
    --add-section .cmdline="kernel-command-line.txt" --change-section-vma .cmdline=0x30000 \
    --add-section .splash="/usr/share/systemd/bootctl/splash-arch.bmp" --change-section-vma .splash=0x40000 \
    --add-section .linux="vmlinuz-file" --change-section-vma .linux=0x2000000 \
    --add-section .initrd="initrd-file" --change-section-vma .initrd=0x3000000 \
    "/usr/lib/systemd/boot/efi/linuxx64.efi.stub" "linux.efi"

作成した linux.efi署名 することもできます。

linux.efiesp/EFI/Linux/ にコピーしてください。

Grml on ESP

ノート: 以下の手順は、Grml 専用ではありません。​若干の調整で他のソフト (例: SystemRescueCD) のインストールも可能です。

Grml ​は、システム管理とレスキュー用のソフトウェアを集めた小さなライブシステムです。

​Grml を ESP にインストールするには、カーネル vmlinuz、 initramfs initrd.img、 圧縮イメージ grml64-small.squashfs を iso ファイルから ESP にコピーするだけです。そのためには、まず [1] ファイルをダウンロードして(マウントポイントは以降 mnt と表記される) ファイルをマウントします。​カーネルと initramfs は mnt/boot/grml6 small/ にあり、圧縮されたイメージは mnt/live/grml64-small/ にあります。

​次に、Grml 用のディレクトリを ESP に作成します:

# mkdir -p esp/grml

​上記のファイルをコピーします:

# cp mnt/boot/grml64small/vmlinuz esp/grml
# cp mnt/boot/grml64small/initrd.img esp/grml
# cp mnt/live/grml64-small/grml64-small.squashfs esp/grml

​最後のステップで、システムブートローダー用のエントリを作成します。 esp/loader/entries 次の内容の grml.conf ファイルを作成します:

esp/loader/entries/grml.conf
title   Grml Live Linux
linux   /grml/vmlinuz
initrd  /grml/initrd.img
options apm=power-off boot=live live-media-path=/grml/ nomce net.ifnames=0

​使用可能なブートオプションの概要については、 cheatcode for Grml

BIOS システムでの systemd-boot

ブートローダーの仕様 に従う BIOS システム用のブートローダーが必要な場合は、 BIOS システムで systemd-boot を押してサービスを開始できます。 Clover ブートローダーは BIOS システムからの起動をサポートし、シミュレートされた EFI 環境を提供します。

トラブルシューティング

BIOS モードで起動後にインストール

警告: こちらの起動方法は推奨されません。

BIOS モードで OS を起動したいときも systemd-boot をインストールすることは可能です。ただし、起動時に systemd-boot の EFI ファイルを実行するようにファームウェアを設定する必要があります:

  • EFI シェルを使用する。
  • ファームウェアのインターフェイスから起動時にロードされる EFI ファイルを設定する。

設定できる場合、インストールは簡単です: EFI シェルやファームウェアの設定インターフェイスを開いて、マシンのデフォルトの EFI ファイルを esp/EFI/systemd/systemd-bootx64.efi (32ビット環境の場合 systemd-bootia32.efi) に変更してください。

ノート: Dell の Latitude シリーズなどでは、EFI ブートを設定するために必要な全てがファームウェアのインターフェイスに揃っており、EFI シェルではコンピュータの ROM に書き込みを行えません。

efibootmgr を使って手動エントリを追加する

bootctl install コマンドが失敗した場合、efibootmgr ユーティリティを使って EFI ブートエントリを手動で作成することができます:

# efibootmgr -c -d /dev/sdX -p Y -l "\EFI\systemd\systemd-bootx64.efi" -L "Linux Boot Manager"

/dev/sdXYEFI システムパーティションに置き換えてください。

ノート: EFI イメージのパスでは区切り文字としてバックスラッシュ (\) を使用します。

Windows の bcdedit を使用した手動入力

何らかの理由で Windows から EFI ブートエントリを作成する必要がある場合は、管理者プロンプトから次のコマンドを使用してください。

# bcdedit /copy {bootmgr} /d "Linux Boot Manager"
# bcdedit /set {guid} path \EFI\systemd\systemd-bootx64.efi

{guid} を最初のコマンドによってリターンされた ID に置き換えます。これをデフォルトのエントリとして設定するには:

# bcdedit /default {guid}

Windows をアップグレードした後にメニューが表示されない

Unified Extensible Firmware Interface#Windows によってブート順序が変わってしまうを見てください。

Windows BitLocker TPM ロック解除のサポートを追加

BitLocker による回復キーの要求を停止するには、次の行を loader.conf に追加します。

esp/loader/loader.conf
reboot-for-bitlocker yes

これにより、BootNext UEFI 変数が設定され、BitLocker が回復キーを必要とせずに Windows ブートマネージャー がロードされます。これは 1 回限りの変更であり、systemd-boot がデフォルトのブートローダーのままです。Windows が自動検出された場合は、エントリとして指定する必要はありません。

これは実験的な機能なので、必ず loader.conf(5) を参照してください。

参照