「Systemd-boot」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(他言語へのリンクを追加)
(→‎ローダー設定: 記事を更新)
128行目: 128行目:
 
=== ローダー設定 ===
 
=== ローダー設定 ===
   
ローダーの設定は {{ic|''esp''/loader/loader.conf}} ファイルに保存され、以下のオプションで設定します:
+
ローダーの設定は {{ic|''esp''/loader/loader.conf}} ファイルに保存さます。詳細は、{{man|5|loader.conf|OPTIONS}} を参照してください。
   
  +
ローダーの設定例を以下に示します:
* {{ic|default}} – [[#ローダーの追加]]で定義されるデフォルト選択エントリ。{{ic|.conf}} 拡張子は付けず、{{ic|arch-*}} のようにワイルドカードを使うこともできます。
 
* {{ic|timeout}} – デフォルトエントリが起動するまでのメニューのタイムアウト秒数。この値が設定されていない場合、起動中に {{ic|Space}} キーを押した時だけメニューが表示されます。
 
* {{ic|editor}} - カーネルパラメータの編集を可能にするかどうかの設定。{{ic|yes}} (デフォルト) は可能になり、{{ic|no}} は無効になります。{{ic|1=init=/bin/bash}} を加えることで root パスワードを回避して root 権限を得ることが出来てしまうため、このオプションは {{ic|no}} に設定することが強く推奨されています。
 
* {{ic|auto-entries}} – {{ic|1}} (デフォルト) に設定した場合は Windows, EFI Shell, デフォルトローダーの自動エントリを表示し、{{ic|0}} の場合は表示しません。
 
* {{ic|auto-firmware}} – {{ic|1}} (デフォルト) に設定した場合、UEFI ファームウェア設定を起動するエントリを表示し、{{ic|0}} に設定した場合は表示しません。
 
* {{ic|console-mode}} – UEFI コンソールモードを変更します:
 
** {{ic|0}} の場合は 80x25;
 
** {{ic|1}} の場合は 80x50;
 
** {{ic|2}} 以上の場合はデバイスファームウェアによって提供されている非標準モード;
 
** {{ic|auto}} は適切なモードを自動的に選択します;
 
** {{ic|max}} ​は一番解像度が高いモード;
 
** {{ic|keep}} ​(デフォルト) はファームウェアが選択したモードを維持します;
 
* {{ic|random-seed-mode}} - ファイル {{ic|''esp''/loader/random-seed}} からランダムシードを読み取るかどうかを制御します。 {{ic|with-system-token}} (デフォルト)に設定すると、EFI 変数 {{ic|LoaderSystemToken}} が設定されている場合にのみファイルからシードがロードされます。 {{ic|always}} に設定すると、 EFI 変数が設定されていなくても、ファイルからシードが読み込まれます。 {{ic|off}} に設定すると、ファイルは無視されます。
 
 
利用可能なオプションの完全な一覧は {{man|5|loader.conf}} を参照。
 
 
設定例:
 
   
 
{{hc|''esp''/loader/loader.conf|
 
{{hc|''esp''/loader/loader.conf|

2023年4月28日 (金) 16:12時点における版

関連記事

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

設定は簡単ですが、起動できるのは Linuxカーネル EFISTUBUEFI シェルGRUB、Windows ブートマネージャなどの EFI 実行ファイルのみです。

インストール

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

systemd-boot の EFI ブートマネージャをインストールする場合、まず UEFI モードでシステムが起動しているかどうか、UEFI 変数が利用できるかどうか確かめてください。efivar --list コマンドを実行することでチェックできます。

systemd-bootEFI システムパーティション (ESP) からしか EFISTUB カーネルをロードできません。カーネルを最新状態に保つために、ESP は /boot にマウントすることが推奨されています。ESP を /boot にマウントしなかった場合、カーネルと initramfs を ESP にコピーする必要があります。詳しくは EFISTUB#他の ESP マウントポイントを見てください。

このページでは ESP のマウントポイントを esp として表します (大抵の場合は /boot です)。

ESP が esp にマウントされているとして、bootctl(1) を使用して EFI システムパーティションに systemd-boot をインストールします:

# bootctl --path=esp install

上記のコマンドで systemd-boot ブートローダーが EFI パーティションにコピーされます。x64 アーキテクチャの場合は2つの同じバイナリ esp/EFI/systemd/systemd-bootx64.efiesp/EFI/Boot/BOOTX64.EFI が ESP に転送されます。そして EFI ブートマネージャによってロードされるデフォルトの EFI アプリケーション (デフォルトブートエントリ) として systemd-boot が設定されます。

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

インストールしたら、#設定セクションに進んで systemd-boot を正しく機能させるために必要なブートローダーを追加してください。

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

​systemd バージョン 242 以降では、カーネルと initramfs を esp パーティションから分離するために、 "Linux extended boot" タイプの別の boot パーティションを作成することができます。​ XBOOTLDR [1] のパーティションタイプ GUID は "bc13c2ff-59e6-4262-a352-b275fd6f7172 である必要があります。

これは、既存の EFI システムパーティション が小さすぎる Windows と Arch のデュアルブート 時に特に役立ちます。 それ以外の場合は、通常どおりesp パーティションを作成し、同じ物理ドライブに boot 用に別のパーティションを作成します。 boot のサイズは、インストールするすべてのカーネルを収容するのに十分なはずです。

ノート:
  • 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

インストールを完了するには configure systemd-boot

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

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

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

手動で更新

bootctl を使用して systemd-boot をアップデートしてください。path パラメータを指定しなかった場合 /efi, /boot, /boot/efi がチェックされます。

# bootctl update

ESP を別の場所にマウントしている場合、path オプションを以下のように指定します:

# bootctl --path=esp update
ノート: gummiboot から移行する場合、上記のコマンドを使用してからパッケージを削除してください。パッケージを既に削除している場合、bootctl --path=esp install を実行してください。

自動で更新

systemd サービス
警告: セキュアブート を有効にしている場合、アップデート後にブートローダーに署名する必要があります

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

別の方法として pacman フック を使いたい場合は(systemd パッケージがアップグレードされた直後にブートローダをアップデートする)、以下のセクションを参照してください。

Pacman フック

systemd-boot-pacman-hookAUR パッケージには上記のアップデートを自動化する Pacman フックが含まれています。パッケージをインストールすると systemd パッケージをアップグレードしたときに毎回フックが起動するようになります。また、パッケージをインストールする代わりに、/etc/pacman.d/hooks/ ディレクトリに以下の pacman フックを作成することでも自動更新できます:

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

[Action]
Description = Updating systemd-boot
When = PostTransaction
Exec = /usr/bin/bootctl update

セキュアブート を有効にしている場合は、 pacman フックをインストールして、カーネルと systemd-boot が更新されたときに自動的に再署名することをお勧めします。

/etc/pacman.d/hooks/99-secureboot.hook
[Trigger]
Operation = Install
Operation = Upgrade
Type = Package
Target = linux
Target = systemd

[Action]
Description = Signing Kernel for SecureBoot
When = PostTransaction
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 = sbsigntools
Depends = findutils
Depends = grep

新しいパッケージを追加するたびに、 Target を複製する必要があります。 find ステートメントに関しては、ファイル名の条件があり、APLM フックがスペースで分割されているため、フックが適切に解析されるように、ステートメント全体を引用符で囲む必要がありました。 systemd-boot はサブディレクトリにあるため、 -maxdepth 引数を削除するように、深さも調整する必要がありました。 煩わしさを避けるために、確信が持てない場合は、テストするパッケージを再インストールして、フックと署名部分が正常に処理されるかどうかを確認してください。 詳細については、 Pacman#フック または alpm-hooks(5) を参照してください。

設定

ローダー設定

ローダーの設定は 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 に存在します。

ローダーの追加

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

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

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

ブートメニューのキー一覧

メニューの中では以下のキーが使われます:

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

以下のホットキーを、起動中やメニューで押すことで、特定のエントリを直接起動します:

  • l - Linux
  • w - Windows
  • a - OS X
  • s - EFI Shell
  • 1-9 - エントリの番号

ヒントとテクニック

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

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

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

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

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

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

$ systemctl reboot --firmware-setup

Unified Kernel Image を使う

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 にコピーするだけです。そのためには、まず [2] ファイルをダウンロードして(マウントポイントは以降 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 によってブート順序が変わってしまうを見てください。

参照