「Systemd-boot」の版間の差分
Kusanaginoturugi (トーク | 投稿記録) (空白を追加) |
Kusanaginoturugi (トーク | 投稿記録) (→ローダーの追加: ラベルでの例をUUIDに変更) |
||
(3人の利用者による、間の19版が非表示) | |||
15行目: | 15行目: | ||
'''systemd-boot''' (旧名 '''gummiboot'''。ドイツ語で「ゴムボート」)は、 設定された EFI イメージを実行するシンプルな [[UEFI]] [[ブートマネージャー]]です。デフォルトのエントリは設定されたパターン (glob) または矢印キーで操作する画面上のメニューによって選択されます。{{Pkg|systemd}} に含まれており、Arch システムにデフォルトでインストールされます。 |
'''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 はファイルシステムのサポートを [[Arch ブートプロセス#UEFI|ファームウェア]] から引き継ぎます (少なくとも FAT12、FAT16、FAT32) さらに、{{ic|''esp''/EFI/systemd/drivers/}} にある [[Unified Extensible Firmware Interface#UEFI ドライバ|UEFI ドライバ]] を全てロードします。 |
||
== インストール == |
== インストール == |
||
+ | ''systemd-boot'' は、{{Pkg|base}} メタパッケージの依存関係である {{Pkg|systemd}} パッケージとともに出荷されるため、追加のパッケージを手動でインストールする必要はありません。 |
||
− | === EFI ブートマネージャのインストール === |
||
+ | |||
+ | == 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'' をインストールします: |
||
− | ''systemd-boot'' の EFI ブートマネージャをインストールする場合、まず UEFI モードでシステムが起動しているかどうか、[[Unified Extensible Firmware Interface#UEFI 変数|UEFI 変数]]が利用できるかどうか確かめてください。{{ic|efivar --list}} コマンドを実行することでチェックできます。 |
||
+ | # bootctl install |
||
− | ''systemd-boot'' は [[EFI システムパーティション]] (ESP) からしか [[EFISTUB]] カーネルをロードできません。カーネルを最新状態に保つために、ESP は {{ic|/boot}} にマウントすることが'''推奨'''されています。ESP を {{ic|/boot}} にマウントしなかった場合、カーネルと initramfs を ESP にコピーする必要があります。詳しくは [[EFISTUB#他の ESP マウントポイント]]を見てください。 |
||
+ | これにより、''systemd-boot'' UEFI ブートマネージャーが ESP にコピーされ、その UEFI ブートエントリが作成され、UEFI ブート順序の最初に設定されます。 |
||
− | このページでは ESP のマウントポイントを {{ic|''esp''}} として表します (大抵の場合は {{ic|/boot}} です)。 |
||
+ | * 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|''esp''}} にマウントされているとして、{{man|1|bootctl}} を使用して EFI システムパーティションに ''systemd-boot'' をインストールします: |
||
+ | * IA32 UEFI では、{{ic|/usr/lib/systemd/boot/efi/systemd-bootia32.efi}} は {{ic|''esp''/EFI/systemd/systemd-bootia32.efi}} と {{ic|''esp''/EFI/BOOT/BOOTIA32.EFI}} にコピーされます。 |
||
− | # bootctl --path=''esp'' install |
||
+ | UEFI ブートエントリは "Linux Boot Manager" と呼ばれ、UEFI のビット数によって、ESP 上の {{ic|EFI}systemd-bootx64.efi}} か {{ic|EFI}systemd-bootia32.efi}} を指します。 |
||
− | 上記のコマンドで ''systemd-boot'' ブートローダーが EFI パーティションにコピーされます。x64 アーキテクチャの場合は2つの同じバイナリ {{ic|''esp''/EFI/systemd/systemd-bootx64.efi}} と {{ic|''esp''/EFI/Boot/BOOTX64.EFI}} が ESP に転送されます。そして EFI ブートマネージャによってロードされるデフォルトの EFI アプリケーション (デフォルトブートエントリ) として ''systemd-boot'' が設定されます。 |
||
{{Note| |
{{Note| |
||
− | * {{ic|bootctl install}} を実行すると |
+ | * {{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 を使用したインストール === |
=== XBOOTLDR を使用したインストール === |
||
− | + | カーネルと initramfs を ESP から分離するために、"Linux extended boot" タイプ (XBOOTLDR) の別の [[パーティショニング#/boot|/boot パーティション]]を作成することができます。これは、既存の [[EFI システムパーティション|ESP]] が小さすぎる [[Windows と Arch のデュアルブート]] 時に特に役立ちます。 |
|
− | + | 通常どおり ESP を作成し、同じ物理ドライブに XBOOTLDR 用の別のパーティションを作成します。XBOOTLDR のパーティションタイプ GUID は {{ic|"bc13c2ff-59e6-4262-a352-b275fd6f7172}} である必要があります。XBOOTLDR パーティションのサイズは、インストールする全てのカーネルを収納できる 十分な大きさが必要です。 |
|
{{Note| |
{{Note| |
||
51行目: | 61行目: | ||
}} |
}} |
||
− | インストール中に、 |
+ | インストール中に、ESP を {{ic|/mnt/efi}} にマウントし、 {{ic|''boot''}} を {{ic|/mnt/boot}} にマウントします。 |
− | chrootになったら、次のコマンドを使用します: |
+ | chroot になったら、次のコマンドを使用します: |
# bootctl --esp-path=/efi --boot-path=/boot install |
# bootctl --esp-path=/efi --boot-path=/boot install |
||
− | インストールを完了するには |
+ | インストールを完了するには ''systemd-boot'' を[[#設定|設定]]します。 |
=== EFI ブートマネージャの更新 === |
=== EFI ブートマネージャの更新 === |
||
67行目: | 77行目: | ||
==== 手動で更新 ==== |
==== 手動で更新 ==== |
||
− | ''bootctl'' を使用して ''systemd-boot'' を |
+ | ''bootctl'' を使用して ''systemd-boot'' を更新: |
# bootctl update |
# bootctl update |
||
− | ESP を別の場所に |
+ | {{Note|{{ic|bootctl install}} と同様に、''systemd-boot''は ESP を {{ic|/efi}}、{{ic|/boot}}、{{ic|/boot/efi}} に配置しようとします。{{ic|''esp''}} を別の場所に設定するには、{{ic|1=--esp-path=''esp''}} オプションを渡す必要があります。}} |
− | |||
− | # bootctl --path=''esp'' update |
||
− | |||
− | {{Note|''gummiboot'' から移行する場合、上記のコマンドを使用してからパッケージを削除してください。パッケージを既に削除している場合、{{ic|1=bootctl --path=''esp'' install}} を実行してください。}} |
||
==== 自動で更新 ==== |
==== 自動で更新 ==== |
||
81行目: | 87行目: | ||
===== systemd サービス ===== |
===== systemd サービス ===== |
||
+ | バージョン 250 以降、{{Pkg|systemd}} には {{ic|systemd-boot-update.service}} が同梱されています。このサービスを [[有効]] にすると、次回の起動時にブートローダーが更新されます。 |
||
− | {{Warning|[[セキュアブート]] を有効にしている場合、アップデート後にブートローダーに署名する必要があります}} |
||
+ | {{Warning|[[セキュアブート]] を有効にしている場合、アップデート後にブートローダに署名する必要があります。その方法の例は以下の [[systemd-boot#pacman フック|pacman フック]] を見て下さい。}} |
||
− | バージョン 250 では、{{Pkg|systemd}} には {{ic|systemd-boot-update.service}} が同梱されています。このサービスを [[有効]] にすると、次回の起動時にブートローダーが更新されます。 |
||
+ | {{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 フック]] を使いたい場合は(''systemd'' パッケージがアップグレードされた直後にブートローダをアップデートする)、以下のセクションを参照してください。 |
||
===== Pacman フック ===== |
===== Pacman フック ===== |
||
− | {{AUR|systemd-boot-pacman-hook}} パッケージ |
+ | {{AUR|systemd-boot-pacman-hook}} パッケージは {{Pkg|systemd}} がアップグレードされる度に実行される pacman フックを追加します。 |
+ | systemd-boot-pacman-hook をインストールするのではなく、次のファイルを {{ic|/etc/pacman.d/hooks/}} に手動で配置することをお勧めします: |
||
− | {{hc|/etc/pacman.d/hooks/systemd-boot.hook|2= |
||
+ | |||
+ | {{hc|/etc/pacman.d/hooks/95-systemd-boot.hook|2= |
||
[Trigger] |
[Trigger] |
||
Type = Package |
Type = Package |
||
98行目: | 105行目: | ||
[Action] |
[Action] |
||
− | Description = |
+ | Description = Gracefully upgrading systemd-boot... |
When = PostTransaction |
When = PostTransaction |
||
− | Exec = /usr/bin/ |
+ | Exec = /usr/bin/systemctl restart systemd-boot-update.service |
}} |
}} |
||
− | [ |
+ | [[セキュアブート]] を有効にしている場合は、パッケージのアップグレードのたびにブートマネージャーに自動的に署名する pacman フックを追加するとよいでしょう: |
− | {{hc|/etc/pacman.d/hooks/ |
+ | {{hc|/etc/pacman.d/hooks/80-secureboot.hook|2= |
[Trigger] |
[Trigger] |
||
Operation = Install |
Operation = Install |
||
Operation = Upgrade |
Operation = Upgrade |
||
− | Type = |
+ | Type = Path |
+ | Target = usr/lib/systemd/boot/efi/systemd-boot*.efi |
||
− | Target = linux |
||
− | Target = systemd |
||
[Action] |
[Action] |
||
− | Description = Signing |
+ | Description = Signing systemd-boot EFI binary for Secure Boot |
When = PostTransaction |
When = PostTransaction |
||
+ | Exec = /bin/sh -c 'while read -r i; do sbsign --key ''/path/to/keyfile.key'' --cert ''/path/to/certificate.crt'' "$i"; done;' |
||
− | Exec = /usr/bin/sh -c "/usr/bin/find /boot/ -type f \( -name 'vmlinuz-*' -o -name 'systemd*' \) -exec /usr/bin/sh -c 'if ! /usr/bin/sbverify --list {} 2>/dev/null {{!}} /usr/bin/grep -q \"signature certificates\"; then /usr/bin/sbsign --key db.key --cert db.crt --output {} {}; fi' \;" |
||
+ | Depends = sh |
||
Depends = sbsigntools |
Depends = sbsigntools |
||
+ | NeedsTargets |
||
− | Depends = findutils |
||
− | Depends = grep |
||
}} |
}} |
||
+ | {{ic|''/path/to/keyfile.key''}} と {{ic|''/path/to/certificate.crt''}} をそれぞれ署名鍵と証明書に置き換えてください。このフックのより良い理解については、{{man|1|sbsign}} を参照してください。 |
||
− | 新しいパッケージを追加するたびに、 {{ic|Target}} を複製する必要があります。 {{ic|find}} ステートメントに関しては、ファイル名の条件があり、APLM フックがスペースで分割されているため、フックが適切に解析されるように、ステートメント全体を引用符で囲む必要がありました。 systemd-boot はサブディレクトリにあるため、 {{ic|-maxdepth}} 引数を削除するように、深さも調整する必要がありました。 煩わしさを避けるために、確信が持てない場合は、テストするパッケージを再インストールして、フックと署名部分が正常に処理されるかどうかを確認してください。 詳細については、 [[Pacman#フック]] または {{man|5|alpm-hooks}} を参照してください。 |
||
+ | |||
+ | {{Tip|{{Pkg|sbctl}} を使用している場合、データベースに登録されているファイルの再登録は {{ic|/usr/share/libalpm/hooks/zz-sbctl.hook}} で提供されているフックを使って自動的に行われます。ブートチェインに必要なファイルを最初に登録することを忘れないでください。}} |
||
== 設定 == |
== 設定 == |
||
128行目: | 136行目: | ||
=== ローダー設定 === |
=== ローダー設定 === |
||
− | ローダーの設定は {{ic|''esp''/loader/loader.conf}} ファイルに保存さます。詳細は、{{man|5|loader.conf|OPTIONS}} を参照してください。 |
+ | ローダーの設定は {{ic|''esp''/loader/loader.conf}} ファイルに保存されます。詳細は、{{man|5|loader.conf|OPTIONS}} を参照してください。 |
ローダーの設定例を以下に示します: |
ローダーの設定例を以下に示します: |
||
146行目: | 154行目: | ||
* {{ic|timeout 0}} を設定している場合、{{ic|Space}} を押すことでブートメニューにアクセスできます。 |
* {{ic|timeout 0}} を設定している場合、{{ic|Space}} を押すことでブートメニューにアクセスできます。 |
||
* 基本的なローダー設定ファイルは、{{ic|/usr/share/systemd/bootctl/loader.conf}} にあります。 |
* 基本的なローダー設定ファイルは、{{ic|/usr/share/systemd/bootctl/loader.conf}} にあります。 |
||
− | * ブートローダー |
+ | * ブートローダー(エントリ選択中)が歪んで表示される場合や、誤った解像度が使用されている場合は、{{ic|console-mode}} を {{ic|auto}}(最適な解像度を選択するためのヒューリスティックスを使用)、{{ic|keep}}(ファームウェアが提供する解像度を維持)、または {{ic|2}}(最初の非 UEFI 標準解像度を選択しようと試みる)に設定してみることができます。}} |
=== ローダーの追加 === |
=== ローダーの追加 === |
||
165行目: | 173行目: | ||
title Arch Linux |
title Arch Linux |
||
linux /vmlinuz-linux |
linux /vmlinuz-linux |
||
− | initrd /intel-ucode.img |
||
initrd /initramfs-linux.img |
initrd /initramfs-linux.img |
||
− | options root= |
+ | options root=UUID=''xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'' rw |
+ | }} |
||
{{hc|''esp''/loader/entries/arch-fallback.conf|2= |
{{hc|''esp''/loader/entries/arch-fallback.conf|2= |
||
title Arch Linux (fallback initramfs) |
title Arch Linux (fallback initramfs) |
||
linux /vmlinuz-linux |
linux /vmlinuz-linux |
||
− | initrd /intel-ucode.img |
||
initrd /initramfs-linux-fallback.img |
initrd /initramfs-linux-fallback.img |
||
− | options root= |
+ | options root=UUID=''xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'' rw |
}} |
}} |
||
249行目: | 256行目: | ||
カーネルパラメータを編集する前にパスワードの入力が求められるようになります。 |
カーネルパラメータを編集する前にパスワードの入力が求められるようになります。 |
||
− | |||
− | == ブートメニューのキー一覧 == |
||
− | |||
− | メニューの中では以下のキーが使われます: |
||
− | * {{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/?}} - ヘルプ |
||
− | |||
− | 以下のホットキーを、起動中やメニューで押すことで、特定のエントリを直接起動します: |
||
− | * {{ic|l}} - Linux |
||
− | * {{ic|w}} - Windows |
||
− | * {{ic|a}} - OS X |
||
− | * {{ic|s}} - EFI Shell |
||
− | * {{ic|1-9}} - エントリの番号 |
||
== ヒントとテクニック == |
== ヒントとテクニック == |
||
288行目: | 274行目: | ||
$ systemctl reboot --firmware-setup |
$ systemctl reboot --firmware-setup |
||
− | === |
+ | === ユニファイドカーネルイメージ を使う === |
systemd-boot は {{ic|''esp''/EFI/Linux/}} 内の unified kernel image を検索します。 |
systemd-boot は {{ic|''esp''/EFI/Linux/}} 内の unified kernel image を検索します。 |
||
379行目: | 365行目: | ||
[[Unified Extensible Firmware Interface#Windows によってブート順序が変わってしまう]]を見てください。 |
[[Unified Extensible Firmware Interface#Windows によってブート順序が変わってしまう]]を見てください。 |
||
+ | |||
+ | === Windows BitLocker TPM ロック解除のサポートを追加 === |
||
+ | |||
+ | BitLocker による回復キーの要求を停止するには、次の行を ''loader.conf'' に追加します。 |
||
+ | |||
+ | {{hc|''esp''/loader/loader.conf| |
||
+ | reboot-for-bitlocker yes |
||
+ | }} |
||
+ | |||
+ | これにより、''BootNext'' UEFI 変数が設定され、BitLocker が回復キーを必要とせずに ''Windows ブートマネージャー'' がロードされます。これは 1 回限りの変更であり、''systemd-boot'' がデフォルトのブートローダーのままです。Windows が自動検出された場合は、エントリとして指定する必要はありません。 |
||
+ | |||
+ | これは実験的な機能なので、必ず {{man|5|loader.conf}} を参照してください。 |
||
== 参照 == |
== 参照 == |
2024年6月6日 (木) 09:47時点における最新版
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
を指します。
インストールを完了するには、systemd-boot を設定します。
XBOOTLDR を使用したインストール
カーネルと initramfs を ESP から分離するために、"Linux extended boot" タイプ (XBOOTLDR) の別の /boot パーティションを作成することができます。これは、既存の ESP が小さすぎる Windows と Arch のデュアルブート 時に特に役立ちます。
通常どおり ESP を作成し、同じ物理ドライブに XBOOTLDR 用の別のパーティションを作成します。XBOOTLDR のパーティションタイプ GUID は "bc13c2ff-59e6-4262-a352-b275fd6f7172
である必要があります。XBOOTLDR パーティションのサイズは、インストールする全てのカーネルを収納できる 十分な大きさが必要です。
インストール中に、ESP を /mnt/efi
にマウントし、 boot
を /mnt/boot
にマウントします。
chroot になったら、次のコマンドを使用します:
# bootctl --esp-path=/efi --boot-path=/boot install
インストールを完了するには systemd-boot を設定します。
EFI ブートマネージャの更新
systemd-boot の新しいバージョンがある場合は、ユーザーが任意でブートマネージャを再インストールできます。手動で実行することも、pacman フックを使用して更新を自動的にトリガすることもできます。その後、2つのアプローチについて説明します。
手動で更新
bootctl を使用して systemd-boot を更新:
# bootctl update
自動で更新
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) を参照してください。
設定
ローダー設定
ローダーの設定は esp/loader/loader.conf
ファイルに保存されます。詳細は、loader.conf(5) § OPTIONS を参照してください。
ローダーの設定例を以下に示します:
esp/loader/loader.conf
default arch.conf timeout 4 console-mode max editor no
ローダーの追加
bootctl は esp/loader/entries/*.conf
からブートメニューのアイテムを検索します – 各ファイルにそれぞれひとつだけローダーを記述してください。利用可能なオプション:
title
– オペレーティングシステムの名前。必須。version
– カーネルバージョン、同じ title のエントリが複数存在する場合にのみ表示されます。任意。machine-id
–/etc/machine-id
のマシン識別子、title と version が同じエントリが複数存在する場合にのみ表示されます。任意。efi
– 起動する EFI プログラム、ESP (/boot
) からの相対パス。例:/vmlinuz-linux
。このオプションかlinux
(下を参照) のどちらか一方が必須です。options
– EFI プログラムに渡すコマンドラインオプションまたはカーネルパラメータ。任意ですが、Linux を起動する場合initrd=efipath
とroot=dev
が最低限必要になります。
Linux を起動する場合、efi
と options
を使う代わりに以下のオプションが使用できます:
linux
とinitrd
で ESP の適切なファイルの相対パスを指定します。例:/vmlinuz-linux
。この値は自動でefi path
とoptions initrd=path
に翻訳されます – この文法は利便性のためにサポートされており機能に違いはありません。
arch_os というラベルが付いたパーティションから Arch を起動して Intel CPU のマイクロコードをロードするローダーファイルの例:
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
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 カーネルを起動するには、手動で設定してエントリを作成する必要があります。
EFI シェルや他の EFI アプリ
EFI シェル と 他のEFIアプリケーション を ESP にインストールした場合は、次のスニペットを使用できます。
カスタム 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.efi
を esp/EFI/Linux/
にコピーしてください。
Grml on ESP
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
) に変更してください。
efibootmgr を使って手動エントリを追加する
bootctl install
コマンドが失敗した場合、efibootmgr ユーティリティを使って EFI ブートエントリを手動で作成することができます:
# efibootmgr -c -d /dev/sdX -p Y -l "\EFI\systemd\systemd-bootx64.efi" -L "Linux Boot Manager"
/dev/sdXY
は 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) を参照してください。