「Systemd-boot」の版間の差分
Mycelithyl (トーク | 投稿記録) 細 →EFI ブートマネージャのインストール: 斜体のマークアップ位置を修正 |
|||
| 162行目: | 162行目: | ||
=== ローダーの追加 === |
=== ローダーの追加 === |
||
''systemd-boot''は、起動元の[[EFI システムパーティション]]上の{{ic|/loader/entries/}}ディレクトリ内にある''.conf''ファイルおよび同一ディスク上の[[Systemd-boot#XBOOTLDR_を使用したインストール|XBOOTDR]]パーティションも検索対象とします。 |
|||
''bootctl'' は {{ic|''esp''/loader/entries/*.conf}} からブートメニューのアイテムを検索します – 各ファイルにそれぞれひとつだけローダーを記述してください。利用可能なオプション: |
|||
| ⚫ | |||
* {{ic|title}} – オペレーティングシステムの名前。'''必須。''' |
|||
* {{ic|''esp''/loader/entries/*.conf}}内のエントリーは{{ic|''esp/''}}ディレクトリ内のファイル(kernel, initramfs, imageなど)のみ参照でき、{{ic|''boot''/loader/entries/*.conf}}内のエントリーは{{ic|''boot/''}}ディレクトリ内のファイルのみ参照出来ます。 |
|||
* {{ic|version}} – カーネルバージョン、同じ title のエントリが複数存在する場合にのみ表示されます。任意。 |
|||
* ファイルパスはEFIシステムパーティションまたはXBOOTLDRパーティションをルートにしたパスです。例えばEFIシステムパーティションまたはXBOOTLDRパーティションが{{ic|/boot}}ディレクトリにマウントされている時は{{ic|/boot/vmlinuz-linux}}ファイルは{{ic|linux}}キーで{{ic|/vmlinuz-linux}}として指定する必要があります。 |
|||
* {{ic|machine-id}} – {{ic|/etc/machine-id}} のマシン識別子、title と version が同じエントリが複数存在する場合にのみ表示されます。任意。 |
|||
* [[セキュアブート]]が有効になっている場合、組み込みの{{ic|.cmdline}}を持つ[[ユニファイドカーネルイメージ]](UKI)はブートエントリーで指定したオプションや対話的に渡されるコマンドラインオプションを全て無視します。セキュアブートが無効の場合コマンドラインで渡されたオプションは組み込みの{{ic|.cmdline}}の内容を上書きします。 |
|||
* {{ic|efi}} – 起動する EFI プログラム、ESP ({{ic|/boot}}) からの相対パス。例: {{ic|/vmlinuz-linux}}。このオプションか {{ic|linux}} (下を参照) のどちらか一方が'''必須'''です。 |
|||
| ⚫ | |||
* {{ic|options}} – EFI プログラムに渡すコマンドラインオプションまたは[[カーネルパラメータ]]。任意ですが、Linux を起動する場合 {{ic|1=initrd=''efipath''}} と {{ic|1=root=''dev''}} が最低限必要になります。 |
|||
UUID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxのボリュームからArch Linuxを起動するloaderファイルの例: |
|||
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 の[[マイクロコード]]をロードするローダーファイルの例: |
|||
{{hc|''esp''/loader/entries/arch.conf|2= |
{{hc|''esp''/loader/entries/arch.conf|2= |
||
title Arch Linux |
title Arch Linux |
||
linux /vmlinuz-linux |
linux /vmlinuz-linux |
||
initrd /initramfs-linux.img |
initrd /initramfs-linux.img |
||
options root=UUID= |
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 /initramfs-linux-fallback.img |
initrd /initramfs-linux-fallback.img |
||
options root=UUID= |
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カーネルを起動するには手動でエントリを作成する必要があります。 |
||
{{Tip| |
|||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
}} |
|||
{{Note| |
{{Note| |
||
[[マイクロコード#別個のマイクロコード_initramfs_ファイルを使う|外部のマイクロコードinitramfsイメージ]]を使用する場合(例えばBoosterをinitramfs生成ツールとして使用する場合)、{{ic|/boot/amd-ucode.img}}または{{ic|/boot/intel-ucode.img}}を別の{{ic|inird}}として指定し、メインのinitramfsイメージより'''前に'''記述する必要があります。 |
|||
* Windows とデュアルブートする場合、Windows のデフォルトオプションである[[Windows と Arch のデュアルブート#高速スタートアップ|高速スタートアップ]]を無効にすることを強く推奨します。 |
|||
* 必要な場合は {{ic|initrd}} で Intel のマイクロコードをロードしてください。例は[[マイクロコード#systemd-boot]] を参照。 |
|||
* {{ic|1=blkid -s PARTUUID -o value /dev/sd''xY''}} コマンドを使うことで root パーティションの PARTUUID を確認できます。{{ic|''x''}} はデバイス文字、{{ic|''Y''}} はパーティション番号に置き換えて下さい。確認するのは root パーティションだけで大丈夫です。{{ic|''esp''}} は確認する必要がありません。 |
|||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
}} |
}} |
||
2025年12月14日 (日) 14:28時点における版
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つの方法を説明します。
手動で更新
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カーネルを起動するには手動でエントリを作成する必要があります。
外部のマイクロコード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.efiESP 上の Grml
PKGBUILD が利用可能です: archiso-systemd-bootAURGrml は、システム管理とレスキュー用のソフトウェアを集めた小さなライブシステムです。
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-bootAURGrml と同様に、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) に変更してください。
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 システムパーティションに置き換えてください。
\) を使用します。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) を参照してください。