コンテンツにスキップ

「Systemd-boot」の版間の差分

提供: ArchWiki
← 古い編集
削除された内容 追加された内容
ビジュアルウィキテキスト
同期
N (トーク | 投稿記録)
11 回編集
 
(10人の利用者による、間の72版が非表示)
3行目: 3行目:
[[de:Gummiboot]]
[[de:Gummiboot]]
[[en:Systemd-boot]]
[[en:Systemd-boot]]
[[es:Gummiboot]]
[[es:Systemd-boot]]
[[pt:Systemd-boot]]
[[ru:Systemd-boot]]
[[ru:Systemd-boot]]
[[zh-cn: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) または画面上のメニューで選択されます。systemd-boot は systemd 220-2 から [[systemd]] に同梱されるようになりました。
'''systemd-boot''' (旧名 '''gummiboot'''。ドイツ語で「ゴムボート」)は、 設定された EFI イメージを実行するシンプルな [[UEFI]] [[ブートマネージャー]]です。デフォルトのエントリは設定されたパターン (glob) または矢印キーで操作する画面上のメニューによって選択されます。{{Pkg|systemd}} に含まれており、Arch システムにデフォルトでインストールされます。


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 ブートマネージャ]) のみを起動できることに注意してください。
systemd-boot は簡単に設定することができ、Linux カーネルの [[EFISTUB]] や UEFI シェル、grub.efi などの EFI 実行可能ファイルだけを起動できます。


== サポートされているファイルシステム ==
{{Warning|systemd-boot は 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}} で示します。}}


== インストール ==
== インストール ==


''systemd-boot'' は、{{Pkg|base}} メタパッケージの依存関係である {{Pkg|systemd}} パッケージとともに出荷されるため、追加のパッケージを手動でインストールする必要はありません。
=== EFI ブート ===
まず、[[Unified_Extensible_Firmware_Interface#UEFI 変数のサポートを正しく動作させるための必要条件|EFI 変数にアクセスできるかチェック]]して UEFI モードで起動していることを確認してください。また、EFI System Partition が正しくマウントされて、カーネルと initramfs が ESP にコピーされていないと、systemd-boot は他のパーティションから EFI バイナリをロードすることができません。以上のことから systemd-boot を使う時は ESP を {{ic|/boot}} にマウントすることを強く推奨します。ESP を {{ic|/boot}} 以外に作りたい場合、[[#アップデート]] を見て下さい。


== EFI ブートマネージャのインストール ==
以下のコマンドを実行することで systemd-boot のバイナリがあなたの EFI System Partition にコピーされ、EFI Boot Manager によってロードされるデフォルトの EFI アプリケーション (デフォルトブートエントリ) として systemd-boot が追加されます。UEFI モードで起動していない場合、また、EFI 変数にアクセスできないときは、ブートエントリの作成は失敗します。ただし systemd-boot のバイナリは ESP 内にある EFI バイナリのデフォルトの配置場所 (x64 環境では {{ic|$esp//EFI/systemd/systemd-bootx64.efi}} あるいは {{ic|$esp/EFI/Boot/BOOTX64.EFI}}) にコピーされるので systemd-boot を起動すること自体は可能です。


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


このページでは ESP のマウントポイントを {{ic|''esp''}} として表します (大抵の場合は {{ic|/efi}} か {{ic|/boot}} です) これは、システムのマウントポイントに [[chroot]] していることを前提としています。
=== レガシーブート ===
{{Warning|こちらの起動方法は推奨されません。}}
レガシーな OS を起動したいときも systemd-boot をインストールすることは可能です。ただし、起動時に systemd-boot の EFI ファイルを実行するようにファームウェアを設定する必要があります:
* EFI シェルを使用する。
* ファームウェアのインターフェイスから起動時にロードされる EFI ファイルを設定する。
{{Note|Dell の Latitude シリーズなどでは、EFI ブートを設定するために必要な全てがファームウェアのインターフェイスに揃っており、EFI シェルではコンピュータの ROM に書き込みを行えません。}}
設定できる場合、インストールは簡単です: EFI シェルやファームウェアの設定インターフェイスを開いて、マシンのデフォルトの EFI ファイルを {{ic|$esp/EFI/systemd/systemd-bootx64.efi}} (i686 環境の場合 {{ic|systemd-bootia32.efi}}) に変更してください。


{{man|1|bootctl}} を使用して EFI システムパーティションに ''systemd-boot'' をインストールします:
=== アップデート ===


# bootctl install
systemd-boot (bootctl(1), systemd-efi-boot-generator(8)) はあなたの EFI System Partition が {{ic|/boot}} にマウントされていると予め事前設定されています。新しいパッケージがリリースされたら {{ic|post_install}} スクリプトによって自動的にアップデートされていた、昔の ''gummiboot'' パッケージと違って、systemd-boot では手動でアップデートするようになっています:


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


* x64 UEFI では、{{ic|/usr/lib/systemd/boot/efi/systemd-bootx64.efi}} は {{ic|''esp''/EFI/systemd/systemd-bootx64.efi}} と {{ic|''esp''/EFI/BOOT/BOOTX64.EFI}} にコピーされます。
ESP が {{ic|/boot}} にマウントされていない場合、{{ic|1=--path=}} オプションで指定します。例:
* 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}} を指します。
# bootctl --path=''$esp'' update


{{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}} を参照)
* ''systemd-boot'' をインストールすると既存の {{ic|''esp''/EFI/BOOT/BOOTX64.EFI}} は上書きされます。(または、{{ic|''esp''/EFI/BOOT/BOOTIA32.EFI}} の IA32 UEFI)、例えば Microsoft 版のファイルなどです。
}}


インストールを完了するには、''systemd-boot'' を[[systemd-boot#設定|設定]]します。
=== 基本設定 ===


=== XBOOTLDR を使用したインストール ===
基本的な設定は {{ic|/boot/loader/loader.conf}} に記述します、3つの設定オプションが使えます:


カーネルと initramfs を ESP から分離するために、"Linux extended boot" タイプ (XBOOTLDR) の別の [[パーティショニング#/boot|/boot パーティション]]を作成することができます。これは、既存の [[EFI システムパーティション|ESP]] が小さすぎる [[Windows と Arch のデュアルブート]] 時に特に役立ちます。
* {{ic|default}} – 選択するデフォルトエントリ ({{ic|.conf}} を付けない); {{ic|arch-*}} のようにワイルドカードを使うことができます


通常どおり ESP を作成し、同じ物理ドライブに XBOOTLDR 用の別のパーティションを作成します。XBOOTLDR のパーティションタイプ GUID は {{ic|"bc13c2ff-59e6-4262-a352-b275fd6f7172}} である必要があります。XBOOTLDR パーティションのサイズは、インストールする全てのカーネルを収納できる 十分な大きさが必要です。
* {{ic|timeout}} – メニューのタイムアウト秒数。この値が設定されていない場合、起動中にスペースキーを押した時だけメニューが表示されます。


{{Note|
* {{ic|editor}} - カーネルパラメータの編集を可能にするかどうか設定。{{ic|1}} (デフォルト) は可能になり、{{ic|0}} は無効になります。{{ic|1=init=/bin/bash}} を加えることで root パスワードを回避して root 権限を得ることが出来てしまうため、このオプションは {{ic|0}} に設定することが強く推奨されています。
* 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 になったら、次のコマンドを使用します:
{{hc|$esp/loader/loader.conf|
default arch
timeout 4
editor 0
}}


# bootctl --esp-path=/efi --boot-path=/boot install
最初の2つのオプションは両方ともブートメニューで変更するこができ、EFI 変数として保存されます。


インストールを完了するには ''systemd-boot'' を[[#設定|設定]]します。
{{Note|タイムアウトが設定されてなかった場合、デフォルトのエントリがすぐさま起動します。}}


=== ブートエントリの追加 ===
=== UEFI ブートマネージャの更新 ===
{{Note|bootctl は自動的に "Windows Boot Manager" ({{ic|\EFI\Microsoft\Boot\Bootmgfw.efi}}), "EFI Shell" ({{ic|\shellx64.efi}}), "EFI Default Loader" ({{ic|\EFI\Boot\bootx64.efi}}) をチェックします。これらが検出された場合、自動的に適切なエントリが生成されます。ただし、([[rEFInd]] など) 他の EFI アプリケーションは自動検出されないため、カーネルを起動するには、手動で設定してエントリを作成する必要があります。Windows とデュアルブートする場合、Windows のデフォルトオプションである[[Windows と Arch のデュアルブート#高速スタートアップ|高速スタートアップ]]を無効にすることを強く推奨します。}}


新しいバージョンの ''systemd-boot'' がリリースされるたびに、UEFI ブートマネージャはオプションでユーザーによって再インストールできます。これは手動または自動で行うことができ、以下にその2つの方法を説明します。
{{Tip|{{ic|1=blkid -s PARTUUID -o value /dev/sdxY}} コマンドを使うことで root パーティションの PARTUUID を確認できます。'x' はデバイス文字、'Y' はパーティション番号に置き換えて下さい。確認するのは root パーティションだけで大丈夫です。$esp は確認する必要がありません。}}


{{Note|UEFI ブートマネージャは独立した EFI 実行可能ファイルであり、任意のバージョンを使用してシステムをブートできます(部分的な更新は適用されません。pacman は ''systemd-boot'' インストーラーのみをインストールし、''systemd-boot'' 本体はインストールしません)ただし、新しいバージョンは新機能を追加したり、バグを修正したりする可能性があるため、''systemd-boot'' の更新はおそらく良いアイデアです。}}
bootctl は {{ic|$esp/loader/entries/*.conf}} にあるブートメニューのアイテムを検索します – 1つのファイルに1つのブートエントリを記述します。利用できるオプションは:


{{Warning|[[セキュアブート]] が有効な場合、ブートローダーの更新に署名する必要があります。詳細は [[#セキュアブートのための署名]] を参照してください。}}
* {{ic|title}} – オペレーティングシステムの名前。'''必須。'''


==== 手動で更新 ====
* {{ic|version}} – カーネルバージョン、同じ title のエントリが複数存在する場合にのみ表示されます。任意。


''bootctl'' を使用して ''systemd-boot'' を更新:
* {{ic|machine-id}} – {{ic|/etc/machine-id}} のマシン識別子、title と version が同じエントリが複数存在する場合にのみ表示されます。任意。


# bootctl update
* {{ic|efi}} – 起動する EFI プログラム、ESP ({{ic|/boot}}) からの相対パス; 例: {{ic|/vmlinuz-linux}}。このオプションか {{ic|linux}} (下を参照) のどちらか一方が'''必須'''です。


{{Note|{{ic|bootctl install}} と同様に、''systemd-boot''は ESP を {{ic|/efi}}、{{ic|/boot}}、{{ic|/boot/efi}} に配置しようとします。{{ic|''esp''}} を別の場所に設定するには、{{ic|1=--esp-path=''esp''}} オプションを渡す必要があります。}}
* {{ic|options}} – EFI プログラムに渡すコマンドラインオプション。任意ですが、Linux を起動する場合 {{ic|1=initrd=''efipath''}} と {{ic|1=root=''dev''}} が最低限必要になります。


==== 自動で更新 ====
Linux では、{{ic|linux ''path-to-vmlinuz''}} と {{ic|initrd ''path-to-initramfs''}} を指定することができます。この値は自動で {{ic|efi ''path''}} と {{ic|1=options initrd=''path''}} に翻訳されます – この文法は利便性のためにサポートされており機能に違いはありません。


''systemd-boot'' を自動的に更新するには、[[systemd#ユニットを使う|systemd サービス]] または [[pacman フック]] を使用してください。これらの2つの方法については、以下に説明します。
==== 標準的な root インストール ====


===== systemd サービス =====
LVM や LUKS がない root パーティションを使用するエントリの例:


バージョン 250 以降、{{Pkg|systemd}} には {{ic|systemd-boot-update.service}} が同梱されています。このサービスを [[有効化]] すると、次回の起動時にブートローダーが更新されます。
{{hc|/boot/loader/entries/arch.conf|2=

title Arch Linux
===== Pacman フック =====
linux /vmlinuz-linux

initrd /initramfs-linux.img
{{AUR|systemd-boot-pacman-hook}} パッケージは {{Pkg|systemd}} がアップグレードされる度に実行される pacman フックを追加します。
options root=PARTUUID=14420948-2cea-4de7-b042-40f67c618660 rw

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


=== セキュアブートのための署名 ===
上の例にある PARTUUID/PARTLABEL は GPT パーティションを識別しています。ファイルシステムを識別する UUID/LABEL とは異なっていることに注意してください。PARTUUID/PARTLABEL には他のファイルシステムでパーティションをフォーマットしなおしても値が変わらないという利点があります。またパーティションにファイルシステムがない (もしくは LABEL をサポートしていない LUKS を使っている) 場合などにも有用です。


[[セキュアブート]] が有効な場合、パッケージのアップグレード時にブートマネージャを自動的に署名するために、pacmanフックを追加したい場合:
==== LVM root インストール ====


{{hc|/etc/pacman.d/hooks/80-secureboot.hook|2=
{{Warning|LVM の外に {{ic|/boot}} ファイルシステムを分割しないと systemd-boot を使用することはできません。}}
[Trigger]
Operation = Install
Operation = Upgrade
Type = Path
Target = usr/lib/systemd/boot/efi/systemd-boot*.efi


[Action]
[[LVM|論理ボリュームマネージャ]]を使う root パーティションのエントリ例:
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}} を参照してください。
{{hc|$esp/loader/entries/arch-lvm.conf|2=

title Arch Linux (LVM)
作成された {{ic|/usr/lib/systemd/boot/efi/systemd-boot*.efi.signed}} は、{{ic|bootctl install}} または {{ic|bootctl update}} によって自動的に認識されます。詳細は {{man|1|bootctl|SIGNED .EFI FILES}} を参照してください。
linux /vmlinuz-linux

initrd /initramfs-linux.img
別の方法としてこちらも参照、[[Unified Extensible Firmware Interface/セキュアブート#pacman フックを使って自動的に署名する|sbctl]]
options root=/dev/mapper/<VolumeGroup-LogicalVolume> rw

== 設定 ==

=== ローダー設定 ===

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

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

{{hc|''esp''/loader/loader.conf|
default arch.conf
timeout 4
console-mode max
editor no
}}
}}


{{Tip|
{{ic|<VolumeGroup-LogicalVolume>}} は実際の VG や LV の名前に置き換えて下さい (例: {{ic|1=root=/dev/mapper/volgroup00-lvolroot}})。また、UUID を使うこともできます:
* systemd-boot はインデント用のタブを受け入れません。代わりにスペースを使用してください。
....
* {{ic|default}} と {{ic|timeout}} はブートメニューで変更することができ、変更した場合は EFI 変数として保存されます。上記のオプションよりも優先して設定されます。
options root=UUID=<UUID identifier> rw
* ​{{ic|bootctl set-default ""}} を使用すると、 {{ic|default}} オプションに優先して EFI 変数をクリアできます。
* 基本的なローダーの設定ファイルは {{ic|/usr/share/systemd/bootctl/loader.conf}} に存在します。
* {{ic|timeout 0}} を設定している場合、{{ic|Space}} を押すことでブートメニューにアクセスできます。
* ブートローダー(エントリ選択中)が歪んで表示される場合や、誤った解像度が使用されている場合は、{{ic|console-mode}} を {{ic|auto}}(最適な解像度を選択するためのヒューリスティックスを使用)、{{ic|keep}}(ファームウェアが提供する解像度を維持)、または {{ic|2}}(最初の非 UEFI 標準解像度を選択しようと試みる)に設定してみることができます。}}


=== ローダーの追加 ===
LVM や LUKS がない root パーティションで使っていた {{ic|1=root='''PARTUUID'''=}} の代わりに {{ic|1=root='''UUID'''=}} を使っていることに注意してください。


''systemd-boot''は、起動元の[[EFI システムパーティション]]上の{{ic|/loader/entries/}}ディレクトリ内にある''.conf''ファイルおよび同一ディスク上の[[Systemd-boot#XBOOTLDR_を使用したインストール|XBOOTDR]]パーティションも検索対象とします。
==== 暗号化 root インストール ====


{{Note|
root パーティションを暗号化している場合の設定ファイルの例 ([[Dm-crypt|DM-Crypt / LUKS]]):
* {{ic|''esp''/loader/entries/*.conf}}内のエントリーは{{ic|''esp/''}}ディレクトリ内のファイル(kernel, initramfs, imageなど)のみ参照でき、{{ic|''boot''/loader/entries/*.conf}}内のエントリーは{{ic|''boot/''}}ディレクトリ内のファイルのみ参照出来ます。
* ファイルパスはEFIシステムパーティションまたはXBOOTLDRパーティションをルートにしたパスです。例えばEFIシステムパーティションまたはXBOOTLDRパーティションが{{ic|/boot}}ディレクトリにマウントされている時は{{ic|/boot/vmlinuz-linux}}ファイルは{{ic|linux}}キーで{{ic|/vmlinuz-linux}}として指定する必要があります。
* [[セキュアブート]]が有効になっている場合、組み込みの{{ic|.cmdline}}を持つ[[ユニファイドカーネルイメージ]](UKI)はブートエントリーで指定したオプションや対話的に渡されるコマンドラインオプションを全て無視します。セキュアブートが無効の場合コマンドラインで渡されたオプションは組み込みの{{ic|.cmdline}}の内容を上書きします。
}}


[[UUID]] ''xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx''のボリュームからArch Linuxを起動するloaderファイルの例:
{{hc|$esp/loader/entries/arch-encrypted.conf|2=
{{hc|''esp''/loader/entries/arch.conf|2=
title Arch Linux Encrypted
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
linux /vmlinuz-linux
initrd /initramfs-linux.img
options cryptdevice=UUID=<UUID>:<mapped-name> root=UUID=<luks-UUID> quiet rw
options root=UUID=''xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'' rw
}}
{{hc|''esp''/loader/entries/arch-fallback.conf|2=
title Arch Linux (fallback initramfs)
linux /vmlinuz-linux
initrd /initramfs-linux-fallback.img
options root=UUID=''xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'' rw
}}
}}
全構成オプションの詳細については、[https://uapi-group.org/specifications/specs/boot_loader_specification/#type-1-boot-loader-specification-entries Boot Loader Specification]を参照してください。


''systemd-boot''は起動時に、{{ic|/EFI/Microsoft/Boot/Bootmgfw.efi}}の'''Windows Boot Manager'''、ファームウェア内の'''Apple macOS Boot Manager'''、{{ic|/shellx64.efi}}の[[Unified_Extensible_Firmware_Interface#UEFI_シェル|UEFIシェル]]、{{ic|/EFI/BOOT/bootx64.efi}}の'''EFIデフォルトローダー'''をチェックし、存在する場合それぞれ{{ic|auto-windows}}、{{ic|auto-osx}}、{{ic|auto-efi-shell}}、{{ic|auto-efi-default}}というタイトルで対応するエントリが生成されます。さらに{{ic|/EFI/Linux/}}に置かれた特別なカーネルファイルを検出します。これらのエントリは手動でローダーを構成する必要はありません。ただし他のEFIアプリケーションの自動検出機能は([[rEFInd]]とは異なり)備えていません、Linuxカーネルを起動するには手動でエントリを作成する必要があります。
上記の例では UUID を使っています。必要であれば、PARTUUID で UUID を置き換えることもできます。{{ic|<luks-UUID>}} は暗号化を解除した後の実際の root ファイルシステムの UUID を示しています ({{Ic|/dev/mapper/<mapped-name>}})。デバイスの UUID ではありません。[[Dm-crypt/システム設定#ブートローダー]]を見て下さい。
{{Tip|
* 設定済みのブートエントリは、{{ic|bootctl list}}コマンドで表示できます。
* エントリファイルの例は{{ic|/usr/share/systemd/bootctl/arch.conf}}にあります。
* [[LVM]]、[[LUKS]]、[[dm-crypt]]、[[Btrfs]]などで必要な[[カーネルパラメータ]]はそれぞれのページを確認してください。
}}


{{Note|
LVM を使用する場合、cryptdevice 行は以下のようになります:
[[マイクロコード#別個のマイクロコード_initramfs_ファイルを使う|外部のマイクロコードinitramfsイメージ]]を使用する場合(例えばBoosterをinitramfs生成ツールとして使用する場合)、{{ic|/boot/amd-ucode.img}}または{{ic|/boot/intel-ucode.img}}を別の{{ic|inird}}として指定し、メインのinitramfsイメージより'''前に'''記述する必要があります。
{{hc|''$esp''/loader/entries/arch-encrypted-lvm.conf|2=
title Arch Linux Encrypted LVM
linux /vmlinuz-linux
initrd /initramfs-linux.img
options cryptdevice=UUID=<UUID>:MyVolGroup root=/dev/mapper/MyVolGroup-MyVolRoot quiet rw
}}
}}


==== EFI シェルや他の EFI アプリ ====
{{ic|\EFI\arch\grub.efi}} など他の EFI プログラムを追加することもできます。


[[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]] を {{Pkg|edk2-shell}} パッケージとともにインストールした場合、"systemd-boot" は EFI ファイルが {{ic|''esp''/shellx64.efi}} に配置されると自動的に検出して新しいエントリを作成します。
==== btrfs サブボリューム root インストール ====
これを実行するには、パッケージをインストールした後に以下のようなコマンドを使用します:


# cp /usr/share/edk2-shell/x64/Shell.efi /boot/shellx64.efi
[[btrfs]] のサブボリュームを root として起動する場合、{{ic|options}} 行を {{ic|rootflags<nowiki>=</nowiki>subvol<nowiki>=</nowiki><root subvolume>}} に変更してください。以下の例では、'ROOT' という名前の btrfs のサブボリュームを root としてマウントしています (例: {{ic|mount -o subvol<nowiki>=</nowiki>ROOT /dev/sdxY /mnt}}):


それ以外の場合は、[[rEFInd#ツール|その他の EFI アプリケーション]] を ESP にインストールした場合、次のスニペットを使用できます。
{{hc|$esp/loader/entries/arch-btrfs-subvol.conf|2=

title Arch Linux
{{Note|{{ic|efi}} 行のファイルパスパラメータは、[[EFI システムパーティション]] のルートに対して相対的です。もし EFI システムパーティションが {{ic|/boot}} にマウントされていて、EFI バイナリが {{ic|/boot/EFI/xx.efi}} と {{ic|/boot/yy.efi}} に存在する場合、それぞれのパラメータは {{ic|efi /EFI/xx.efi}} と {{ic|efi /yy.efi}} のように指定します。}}
linux /vmlinuz-linux

initrd /initramfs-linux.img
{{hc|''esp''/loader/entries/fwupd.conf|
options root=PARTUUID=14420948-2cea-4de7-b042-40f67c618660 rw rootflags<nowiki>=</nowiki>subvol<nowiki>=</nowiki>ROOT
title Firmware updater
efi /EFI/tools/fwupdx64.efi
}}
}}


{{hc|''esp''/loader/entries/gdisk.conf|
以上のように設定していないと次のエラーメッセージが表示されます: {{ic|ERROR: Root device mounted successfully, but /sbin/init does not exist.}}。
title GPT fdisk (gdisk)
efi /EFI/tools/gdisk_x64.efi
}}


==== EFI シェルや他の EFI アプリ ====
===== Memtest86+ =====


これを機能させるには、{{pkg|memtest86+-efi}} をインストールする必要があります。また、セキュアブートを使用するときに EFI バイナリに署名する必要があります。
EFI シェルなどの EFI アプリケーションを ESP にインストールしている場合、以下のスニペットを使うことができます:


{{hc|$esp/loader/entries/uefi-shell-v1-x86_64.conf|2=
{{hc|''esp''/loader/entries/memtest.conf|
title UEFI Shell x86_64 v1
title Memtest86+
efi /EFI/shellx64_v1.efi
efi /memtest86+/memtest.efi
}}
}}


===== Netboot =====
{{hc|$esp/loader/entries/uefi-shell-v2-x86_64.conf|2=

title UEFI Shell x86_64 v2
"systemd-boot" は [[Netboot]] をチェーンロードできます。{{ic|ipxe-arch.efi}}  EFI バイナリとその署名をダウンロードし、それを検証した後、提案された場所に {{ic|''esp''/EFI/arch_netboot/arch_netboot.efi}} として配置します。
efi /EFI/shellx64_v2.efi

{{hc|''esp''/loader/entries/arch_netboot.conf|
title Arch Linux Netboot
efi /EFI/arch_netboot/arch_netboot.efi
}}
}}

===== GRUB =====

''systemd-boot'' は [[GRUB]] をチェーンロードできます。{{ic|grubx64.efi}} バイナリの場所は、GRUB が ESP にインストールされた際に使用された {{ic|1=--bootloader-id=}} と一致します。

{{hc|''esp''/loader/entries/grub.conf|
title GRUB
efi /EFI/GRUB/grubx64.efi
}}

==== 別のディスクから起動 ====

"systemd-boot" は起動元の ESP や同一ディスク上のXBOOTLDRパーティション以外のパーティションからEFIバイナリを起動 [https://github.com/systemd/systemd/issues/3252 できませんが、] [[UEFI シェル]] を使ってそれを行うことができます。

まず、上記の [[#EFI シェルや他の EFI アプリ]] のセクションに従って、{{Pkg|edk2-shell}} パッケージをインストールします。UEFI シェルで "map" コマンドを使用して、対応する PARTUUID を持つパーティションの '''FS エイリアス''' (例:HD0a66666a2、HD0b、FS1、BLK7) を確認します。

次に、{{ic|exit}} コマンドを使用して Linux に戻り、UEFI シェルを通じてターゲット EFI プログラムを実行するための新しいローダーエントリを作成します:

{{hc|''esp''/loader/entries/windows.conf|
title Windows
efi /shellx64.efi
options -nointerrupt -nomap -noversion HD0b:EFI\Microsoft\Boot\Bootmgfw.efi
}}

{{ic|efi}} パスは、 {{ic|shellx64.efi}} がコピーされた "esp" パーティション内の場所と一致していることを確認してください。また、{{ic|shellx64.efi}} EFI ファイルは、"systemd-boot" による自動エントリ作成を避けるために他の場所に移動することもできます。

{{ic|HD0b}} は、前述の "FS エイリアス" に置き換えてください。

* {{ic|-nointerrupt}} オプションは、{{ic|Ctrl+c}} でターゲット EFI プログラムを中断しないようにします。
* {{ic|-nomap -noversion}} オプションは、デフォルトの UEFI シェルの挨拶を非表示にします。
* ターゲットEFIプログラムが終了した場合(例えばエラーで)にUEFIシェルが自動的にブートローダーに戻るようにするには、{{ic|-exit}} オプションを追加します。
* もし UEFI シェル内にまだ不要な出力がある場合、{{ic|-noconsoleout}} オプションを追加できます。

=== UEFI ファームウェアセットアップの起動 ===

systemd-boot は、デバイスのファームウェアが OS からセットアップに再起動することをサポートしている場合、UEFI ファームウェアセットアップに起動するエントリを自動的に追加します。


=== ハイバネーション ===
=== ハイバネーション ===
175行目: 275行目:
[[サスペンドとハイバネート]]の記事を参照してください。
[[サスペンドとハイバネート]]の記事を参照してください。


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


{{ic|password}} 設定オプションをサポートしている {{AUR|systemd-boot-password}} をインストールすることもできます。{{ic|sbpctl generate}} を使ってオプションで指定する値を生成できます。
=== キー一覧 ===


''systemd-boot-password'' は以下のコマンドでインストールしてください:
メニューの中では以下のキーが使われます:
* {{ic|Up/Down}} - エントリの選択
* {{ic|Enter}} - 選択したエントリの起動
* {{ic|d}} - (不揮発の EFI 変数に保存された) デフォルトエントリを選択して起動
* {{ic|t/T}} - (不揮発の EFI 変数に保存された) タイムアウトを調整
* {{ic|e}} - カーネルコマンドラインを編集。{{ic|editor}} オプションが {{ic|0}} に設定されている場合は使えません
* {{ic|q}} - 終了
* {{ic|v}} - systemd-boot と UEFI のバージョンを表示
* {{ic|p}} - 現在の設定を表示
* {{ic|h}} - キーマップを表示
* {{ic|h/?}} - ヘルプ


{{bc|1=# sbpctl install ''esp''}}
以下のホットキーを、起動中やメニューで押すことで、特定のエントリを直接起動します:

* {{ic|l}} - Linux
カーネルパラメータを編集する前にパスワードの入力が求められるようになります。
* {{ic|w}} - Windows

* {{ic|a}} - OS X
== ヒントとテクニック ==
* {{ic|s}} - EFI Shell

* {{ic|1-9}} - エントリの番号
=== ブートメニューで使用できるキー ===

ブートメニューで使用できるキー割り当てについては、{{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

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

{{ic|''esp''/EFI/Linux/}} にある [[ユニファイドカーネルイメージ|Unified kernel image]] (UKI)は、systemd-boot によって自動的に読み込まれ、{{ic|''esp''/loader/entries}} にエントリを追加する必要はありません。(Unified kernel image は、systemd-boot によって識別されるためには、{{ic|.efi}} 拡張子を持っている必要があります。)

{{Tip|{{ic|''esp''/loader/entries/}} 内のファイルは、{{ic|''esp''/loader/loader.conf}} に {{ic|default}} が設定されていない場合、最初に起動されます。それらのエントリを削除するか、フルファイル名でデフォルトを設定してください。例:{{ic|1=default arch-linux.efi}}}}

=== ESP 上の Grml ===

{{Note|以下の手順は、Grml 専用ではありません。​若干の調整で他のソフト (例: [http://www.system-rescue-cd.org/ SystemRescueCD]) のインストールも可能です。}}
{{Tip|{{ic|PKGBUILD}} が利用可能です: {{AUR|archiso-systemd-boot}}}}

[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]

=== ESP 上の Archiso ===

{{Tip|{{ic|PKGBUILD}} が利用可能です: {{AUR|archiso-systemd-boot}}}}

Grml と同様に、Arch Linux の ISO を使用することができます。そのためには、ISO ファイルからカーネル {{ic|vmlinuz-linux}}、initramfs {{ic|initramfs-linux.img}}、および squashfs イメージ {{ic|airootfs.sfs}} を EFI システムパーティションにコピーする必要があります。

最初に [https://archlinux.org/download/ archlinux-yyy.mm.dd-x86_64.iso] をダウンロードします。

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

# mkdir -p ''esp''/EFI/archiso

そこに {{ic|arch}} ディレクトリの内容を抽出します:

# bsdtar -v -x --no-same-permissions --strip-components 1 -f archlinux-''YYYY''.''MM''.''DD''-x86_64.iso -C ''esp''/EFI/archiso arch

最後のステップでは、systemd-boot Loader のブートエントリを作成します:{{ic|''esp''/roader/entries}}:

{{hc|''esp''/loader/entries/arch-rescue.conf|2=
title Arch Linux (rescue system)
linux /EFI/archiso/boot/x86_64/vmlinuz-linux
initrd /EFI/archiso/boot/x86_64/initramfs-linux.img
options archisobasedir=/EFI/archiso archisosearchfilename=/EFI/archiso/boot/x86_64/vmlinuz-linux
}}

利用可能なブートオプションの概要については、[https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/-/blob/master/docs/README.bootparams README.bootparams for mkinitcpio-archiso] を参照してください。

=== BIOS システムでの systemd-boot ===

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


== トラブルシューティング ==
== トラブルシューティング ==


==== efibootmgr を使って手動エントリを追加する ====
=== systemd-boot がブートエントリを表示しない ===

これは、カーネルへのパスが間違って指定されているなど、設定ファイルに関するさまざまな問題が原因である可能性があります。確認するには、次のコマンドを実行してください:

# bootctl

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

{{Note|こちらの起動方法は推奨されません。}}

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

* 他の場所に機能する UEFI Shell がある場合。
* ファームウェアのインターフェイスから起動時にロードされる EFI ファイルを設定する。
* 一部のファームウェアは、UEFI に他のエントリが設定されていない場合、デフォルトで {{ic|''esp''/EFI/BOOT/BOOTX64.EFI}} を使用することがあります。

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

{{Note|Dell Latitude シリーズのファームウェアインターフェースは、UEFI ブートの設定に必要なすべてを提供しますが、UEFI シェルはコンピュータの ROM に書き込むことができません。}}

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


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


# efibootmgr -c -d /dev/sdX -p Y -l /EFI/systemd/systemd-bootx64.efi -L "Linux Boot Manager"
# efibootmgr --create --disk /dev/sd''X'' --part ''Y'' --loader '\EFI\systemd\systemd-bootx64.efi' --label "Linux Boot Manager" --unicode

{{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 が自動検出された場合は、エントリとして指定する必要はありません。
{{Note|Windows 8.x 以上 (Windows 10 も含む) では、起動するたびにインストールした UEFI のエントリが上書きされてしまい、Windows が一番優先して起動されます。たとえ UEFI のファームウェアでブートの順番を変えたとしても、一度 Windows 10 を起動してしまえばそれで Windows が一番上に戻ります。マザーボードの 'Change Boot Option' キーが何なのか知っておいて下さい。}}
Windows 8.x 以上で、設定したブートの順番を守るようにさせたい場合、Windows のグループポリシーを入力して起動時にバッチファイル (.bat) を起動するようにしてください。Windows 上で以下を実行:
* 管理者権限でコマンドプロンプトを開いて下さい。そして {{ic|bcdedit /enum firmware}} と入力します。
* 説明に "Linux" と付いているファームウェアアプリケーションを探して下さい。例: "Linux Boot Manager"。
* 括弧も含めて Identifier をコピーします。例: {{ic|<nowiki>{31d0d5f4-22ad-11e5-b30b-806e6f6e6963}</nowiki>}}。
* gpedit から ローカルコンピュータポリシー-> コンピューターの構成-> Windows の設定-> スクリプト(スタートアップ/シャットダウン) を開いて "スタートアップ" を選択してください。"スタートアップのプロパティ" という名前のウィンドウが開きます。
* "スクリプト"タブの、追加ボタンを押して下さい。
* スクリプトに名前を付けます。例: {{ic|bootorder.bat}}。
* "スクリプトのパラメーター" には {{ic|<nowiki>bcdedit /set {fwbootmgr} DEFAULT {先にコピーした identifier}</nowiki>}} と入力します (例: {{ic|<nowiki>bcdedit /set {fwbootmgr} DEFAULT {31d0d5f4-22ad-11e5-b30b-806e6f6e6963}</nowiki>}})。


これは実験的な機能なので、必ず {{man|5|loader.conf}} を参照してください。
上記の設定が上手く行かない場合、Windows 環境のどこかに {{ic|<nowiki>bcdedit /set {fwbootmgr} DEFAULT {先にコピーした identifier}</nowiki>}} と記述したバッチファイルを作成して、gpedit から保存したファイルを参照してください。


== 参照 ==
== 参照 ==


* https://systemd.io/BOOT/
* http://www.freedesktop.org/wiki/Software/systemd/systemd-boot/
* https://bbs.archlinux.org/viewtopic.php?id=254374
* https://uapi-group.org/specifications/specs/boot_loader_specification/

2025年12月14日 (日) 14:35時点における最新版

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

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

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

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.efi は esp/EFI/systemd/systemd-bootx64.efi と esp/EFI/BOOT/BOOTX64.EFI にコピーされます。
  • IA32 UEFI では、/usr/lib/systemd/boot/efi/systemd-bootia32.efi は esp/EFI/systemd/systemd-bootia32.efi と esp/EFI/BOOT/BOOTIA32.EFI にコピーされます。

UEFI ブートエントリは "Linux Boot Manager" と呼ばれ、UEFI のビット数によって、ESP 上の EFI}systemd-bootx64.efi か EFI}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 を設定します。

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

新しいバージョンの systemd-boot がリリースされるたびに、UEFI ブートマネージャはオプションでユーザーによって再インストールできます。これは手動または自動で行うことができ、以下にその2つの方法を説明します。

ノート UEFI ブートマネージャは独立した EFI 実行可能ファイルであり、任意のバージョンを使用してシステムをブートできます(部分的な更新は適用されません。pacman は systemd-boot インストーラーのみをインストールし、systemd-boot 本体はインストールしません)ただし、新しいバージョンは新機能を追加したり、バグを修正したりする可能性があるため、systemd-boot の更新はおそらく良いアイデアです。
警告 セキュアブート が有効な場合、ブートローダーの更新に署名する必要があります。詳細は #セキュアブートのための署名 を参照してください。

手動で更新

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

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

自動で更新

systemd-boot を自動的に更新するには、systemd サービス または pacman フック を使用してください。これらの2つの方法については、以下に説明します。

systemd サービス

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

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) を参照してください。

作成された /usr/lib/systemd/boot/efi/systemd-boot*.efi.signed は、bootctl install または bootctl update によって自動的に認識されます。詳細は bootctl(1) § SIGNED .EFI FILES を参照してください。

別の方法としてこちらも参照、sbctl

設定

ローダー設定

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

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

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

ローダーの追加

systemd-bootは、起動元のEFI システムパーティション上の/loader/entries/ディレクトリ内にある.confファイルおよび同一ディスク上のXBOOTDRパーティションも検索対象とします。

ノート
  • esp/loader/entries/*.conf内のエントリーはesp/ディレクトリ内のファイル(kernel, initramfs, imageなど)のみ参照でき、boot/loader/entries/*.conf内のエントリーはboot/ディレクトリ内のファイルのみ参照出来ます。
  • ファイルパスはEFIシステムパーティションまたはXBOOTLDRパーティションをルートにしたパスです。例えばEFIシステムパーティションまたはXBOOTLDRパーティションが/bootディレクトリにマウントされている時は/boot/vmlinuz-linuxファイルはlinuxキーで/vmlinuz-linuxとして指定する必要があります。
  • セキュアブートが有効になっている場合、組み込みの.cmdlineを持つユニファイドカーネルイメージ(UKI)はブートエントリーで指定したオプションや対話的に渡されるコマンドラインオプションを全て無視します。セキュアブートが無効の場合コマンドラインで渡されたオプションは組み込みの.cmdlineの内容を上書きします。

UUID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxのボリュームからArch Linuxを起動するloaderファイルの例: 

esp/loader/entries/arch.conf
title   Arch Linux
linux   /vmlinuz-linux
initrd  /initramfs-linux.img
options root=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx rw
esp/loader/entries/arch-fallback.conf
title   Arch Linux (fallback initramfs)
linux   /vmlinuz-linux
initrd  /initramfs-linux-fallback.img
options root=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx rw

全構成オプションの詳細については、Boot Loader Specificationを参照してください。

systemd-bootは起動時に、/EFI/Microsoft/Boot/Bootmgfw.efiのWindows Boot Manager、ファームウェア内のApple macOS Boot Manager、/shellx64.efiのUEFIシェル、/EFI/BOOT/bootx64.efiのEFIデフォルトローダーをチェックし、存在する場合それぞれauto-windows、auto-osx、auto-efi-shell、auto-efi-defaultというタイトルで対応するエントリが生成されます。さらに/EFI/Linux/に置かれた特別なカーネルファイルを検出します。これらのエントリは手動でローダーを構成する必要はありません。ただし他のEFIアプリケーションの自動検出機能は(rEFIndとは異なり)備えていません、Linuxカーネルを起動するには手動でエントリを作成する必要があります。

ヒント
  • 設定済みのブートエントリは、bootctl listコマンドで表示できます。
  • エントリファイルの例は/usr/share/systemd/bootctl/arch.confにあります。
  • LVM、LUKS、dm-crypt、Btrfsなどで必要なカーネルパラメータはそれぞれのページを確認してください。
ノート

外部のマイクロコードinitramfsイメージを使用する場合(例えばBoosterをinitramfs生成ツールとして使用する場合)、/boot/amd-ucode.imgまたは/boot/intel-ucode.imgを別のinirdとして指定し、メインのinitramfsイメージより前に記述する必要があります。

EFI シェルや他の EFI アプリ

UEFI シェル を edk2-shell パッケージとともにインストールした場合、"systemd-boot" は EFI ファイルが esp/shellx64.efi に配置されると自動的に検出して新しいエントリを作成します。 これを実行するには、パッケージをインストールした後に以下のようなコマンドを使用します: 

# cp /usr/share/edk2-shell/x64/Shell.efi /boot/shellx64.efi

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

ノート efi 行のファイルパスパラメータは、EFI システムパーティション のルートに対して相対的です。もし EFI システムパーティションが /boot にマウントされていて、EFI バイナリが /boot/EFI/xx.efi と /boot/yy.efi に存在する場合、それぞれのパラメータは efi /EFI/xx.efi と efi /yy.efi のように指定します。
esp/loader/entries/fwupd.conf
title  Firmware updater
efi     /EFI/tools/fwupdx64.efi

esp/loader/entries/gdisk.conf
title  GPT fdisk (gdisk)
efi     /EFI/tools/gdisk_x64.efi
Memtest86+

これを機能させるには、memtest86+-efi をインストールする必要があります。また、セキュアブートを使用するときに EFI バイナリに署名する必要があります。 

esp/loader/entries/memtest.conf
title Memtest86+
efi /memtest86+/memtest.efi
Netboot

"systemd-boot" は Netboot をチェーンロードできます。ipxe-arch.efi  EFI バイナリとその署名をダウンロードし、それを検証した後、提案された場所に esp/EFI/arch_netboot/arch_netboot.efi として配置します。 

esp/loader/entries/arch_netboot.conf
title Arch Linux Netboot
efi /EFI/arch_netboot/arch_netboot.efi
GRUB

systemd-boot は GRUB をチェーンロードできます。grubx64.efi バイナリの場所は、GRUB が ESP にインストールされた際に使用された --bootloader-id= と一致します。 

esp/loader/entries/grub.conf
title GRUB
efi /EFI/GRUB/grubx64.efi

別のディスクから起動

"systemd-boot" は起動元の ESP や同一ディスク上のXBOOTLDRパーティション以外のパーティションからEFIバイナリを起動 できませんが、 UEFI シェル を使ってそれを行うことができます。

まず、上記の #EFI シェルや他の EFI アプリ のセクションに従って、edk2-shell パッケージをインストールします。UEFI シェルで "map" コマンドを使用して、対応する PARTUUID を持つパーティションの FS エイリアス (例:HD0a66666a2、HD0b、FS1、BLK7) を確認します。

次に、exit コマンドを使用して Linux に戻り、UEFI シェルを通じてターゲット EFI プログラムを実行するための新しいローダーエントリを作成します: 

esp/loader/entries/windows.conf
title   Windows
efi     /shellx64.efi
options -nointerrupt -nomap -noversion HD0b:EFI\Microsoft\Boot\Bootmgfw.efi

efi パスは、 shellx64.efi がコピーされた "esp" パーティション内の場所と一致していることを確認してください。また、shellx64.efi EFI ファイルは、"systemd-boot" による自動エントリ作成を避けるために他の場所に移動することもできます。

HD0b は、前述の "FS エイリアス" に置き換えてください。

  • -nointerrupt オプションは、Ctrl+c でターゲット EFI プログラムを中断しないようにします。
  • -nomap -noversion オプションは、デフォルトの UEFI シェルの挨拶を非表示にします。
  • ターゲットEFIプログラムが終了した場合(例えばエラーで)にUEFIシェルが自動的にブートローダーに戻るようにするには、-exit オプションを追加します。
  • もし UEFI シェル内にまだ不要な出力がある場合、-noconsoleout オプションを追加できます。

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

systemd-boot は、デバイスのファームウェアが OS からセットアップに再起動することをサポートしている場合、UEFI ファームウェアセットアップに起動するエントリを自動的に追加します。

ハイバネーション

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

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

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

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

esp/EFI/Linux/ にある Unified kernel image (UKI)は、systemd-boot によって自動的に読み込まれ、esp/loader/entries にエントリを追加する必要はありません。(Unified kernel image は、systemd-boot によって識別されるためには、.efi 拡張子を持っている必要があります。)

ヒント esp/loader/entries/ 内のファイルは、esp/loader/loader.conf に default が設定されていない場合、最初に起動されます。それらのエントリを削除するか、フルファイル名でデフォルトを設定してください。例:default arch-linux.efi

ESP 上の Grml

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

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

​Grml を ESP にインストールするには、カーネル vmlinuz、 initramfs initrd.img、 圧縮イメージ grml64-small.squashfs を iso ファイルから ESP にコピーするだけです。そのためには、まず grml64-small.iso ファイルをダウンロードして(マウントポイントは以降 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

ESP 上の Archiso

ヒント PKGBUILD が利用可能です: archiso-systemd-bootAUR

Grml と同様に、Arch Linux の ISO を使用することができます。そのためには、ISO ファイルからカーネル vmlinuz-linux、initramfs initramfs-linux.img、および squashfs イメージ airootfs.sfs を EFI システムパーティションにコピーする必要があります。

最初に archlinux-yyy.mm.dd-x86_64.iso をダウンロードします。

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

# mkdir -p esp/EFI/archiso

そこに arch ディレクトリの内容を抽出します: 

# bsdtar -v -x --no-same-permissions --strip-components 1 -f archlinux-YYYY.MM.DD-x86_64.iso -C esp/EFI/archiso arch

最後のステップでは、systemd-boot Loader のブートエントリを作成します:esp/roader/entries: 

esp/loader/entries/arch-rescue.conf
title   Arch Linux (rescue system)
linux   /EFI/archiso/boot/x86_64/vmlinuz-linux
initrd  /EFI/archiso/boot/x86_64/initramfs-linux.img
options archisobasedir=/EFI/archiso archisosearchfilename=/EFI/archiso/boot/x86_64/vmlinuz-linux

利用可能なブートオプションの概要については、README.bootparams for mkinitcpio-archiso を参照してください。

BIOS システムでの systemd-boot

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

トラブルシューティング

systemd-boot がブートエントリを表示しない

これは、カーネルへのパスが間違って指定されているなど、設定ファイルに関するさまざまな問題が原因である可能性があります。確認するには、次のコマンドを実行してください: 

# bootctl

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

ノート こちらの起動方法は推奨されません。

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

  • 他の場所に機能する UEFI Shell がある場合。
  • ファームウェアのインターフェイスから起動時にロードされる EFI ファイルを設定する。
  • 一部のファームウェアは、UEFI に他のエントリが設定されていない場合、デフォルトで esp/EFI/BOOT/BOOTX64.EFI を使用することがあります。

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

ノート Dell Latitude シリーズのファームウェアインターフェースは、UEFI ブートの設定に必要なすべてを提供しますが、UEFI シェルはコンピュータの ROM に書き込むことができません。

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

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

# efibootmgr --create --disk /dev/sdX --part Y --loader '\EFI\systemd\systemd-bootx64.efi' --label "Linux Boot Manager" --unicode

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

ノート 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) を参照してください。

参照

「https://wiki.archlinux.jp/index.php?title=Systemd-boot&oldid=41250」から取得