GRUBからsystemd-bootへ移行する｜UEFI環境の差分確認とロールバック手順

ブートローダーの選定は、一度構築すると長期間そのまま運用されることが多く、問題が起きて初めて見直す機会が生まれるケースが少なくありません。近年は主要ディストリビューションが systemd-boot をデフォルト採用する動きが広がっており、GRUB を前提とした運用フローを見直す必要が出てきた現場も増えています。本記事では、UEFI 環境で GRUB から systemd-boot へ移行する際の差分確認ポイント、実際の移行手順、そして切り戻しまでを一本の流れとして解説します。

GRUBとsystemd-bootの設計思想の違いを理解する

GRUB（GNU GRand Unified Bootloader）は BIOS・UEFI の両方に対応し、LVM・RAID・暗号化パーティションのアンロックまでブート前に処理できる汎用性の高いローダーです。一方 systemd-boot（旧称 gummiboot）は UEFI 専用という制約を持つ代わりに、設定ファイルが平文テキストのみで構成されており、構造が極めてシンプルです。

systemd-boot が読み込む設定は EFI システムパーティション（ESP）上の /loader/loader.conf と /loader/entries/*.conf だけです。スクリプトや条件分岐は存在せず、「どのカーネルをどのオプションで起動するか」だけを記述します。複雑な設定が書けない分、誤設定でブート不能になりにくいという実運用上の利点があります。

ただし、LUKS 暗号化ボリュームの解錠やネットワーク越しの PXE ブートなど、GRUB が担っていた機能が必要な構成では、systemd-boot だけでは対応できない場合があります。移行前にこの点を明示的に確認しておくことが重要です。

移行前に確認すべきUEFI環境の差分チェック

移行作業を始める前に、現在の環境が UEFI で起動しているかどうかを必ず確認します。/sys/firmware/efi ディレクトリが存在すれば UEFI モードで動作しています。

ls /sys/firmware/efi

次に ESP のマウント先を確認します。Fedora・Arch 系では /boot に ESP をマウントするケースが多く、Ubuntu・Debian 系では /boot/efi が一般的です。findmnt /boot/efi または findmnt /boot で確認し、実際のデバイスと UUID を控えておきます。

現在の UEFI ブートエントリは efibootmgr -v で一覧できます。GRUB のエントリが登録されている番号を記録しておくと、ロールバック時にスムーズに対応できます。また、カーネルと initramfs の実際の配置パスも確認します。systemd-boot は ESP 上にカーネルファイルが存在することを求めるため、現行構成が /boot を ESP としていない場合は、ファイルのコピー戦略（stub エントリ・UKI 利用など）を事前に決めておく必要があります。

systemd-bootのインストールと設定手順

インストールは bootctl コマンド一本で完了します。ESP が /boot にマウントされている環境では追加オプションは不要です。

bootctl install

ESP が /boot/efi にある場合は --esp-path=/boot/efi を明示します。このコマンドは /EFI/systemd/ 以下にローダーバイナリをコピーし、UEFI ブートエントリを自動登録します。

次に /boot/loader/loader.conf（ESP が /boot/efi なら /boot/efi/loader/loader.conf）を作成します。最小限の設定例は以下の通りです。

default  linux.conf
timeout  5
editor   no

editor no は起動時にカーネルパラメータを対話編集できないよう制限する設定で、セキュリティ上の観点から運用環境では設定しておくことが推奨されます。

続いてブートエントリを /boot/loader/entries/linux.conf として作成します。

title   Linux
linux   /vmlinuz-linux
initrd  /initramfs-linux.img
options root=UUID=xxxx-xxxx rw quiet

カーネルと initramfs のパスは ESP ルートからの相対パスで指定します。ファイルが ESP 上に存在しない場合はコピーするか、パッケージマネージャの hook（pacman の場合 kernel-install、Fedora 系では kernel-install や BLS 対応の grubby 後継）で自動配置されるよう設定します。

動作確認と検証ポイント

設定後、再起動の前に bootctl status で現状を確認します。

bootctl status

出力の Boot Loader Entries セクションに作成したエントリが列挙され、default として認識されていれば準備完了です。efibootmgr を再度実行して systemd-boot のエントリが追加されたことも確認します。

再起動後は bootctl status の Current Boot Loader 欄が systemd-boot になっているかを確認します。また journalctl -b 0 -p err でブート時のエラーログを確認し、カーネルパラメータ不足や initramfs 未ロードのエラーがないかをチェックします。

Secure Boot を有効にしている環境では、systemd-boot 自体が署名済みバイナリである必要があります。ディストリビューションが提供するパッケージ経由でインストールした場合は通常署名済みですが、手動でバイナリを配置した場合は sbsign や sbverify で署名状態を確認してください。

GRUBへのロールバック手順

systemd-boot で起動した環境から GRUB に戻す場合、まず GRUB のバイナリを再インストールします。Debian・Ubuntu 系では以下のように実行します。

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
update-grub

Fedora・RHEL 系では grub2-install と grub2-mkconfig を使います。インストール後は efibootmgr -v で GRUB のエントリが登録されたことを確認し、次回起動のデフォルトを GRUB に変更します。

# GRUB のエントリ番号を確認してデフォルトに設定（例: エントリ番号が 0002 の場合）
efibootmgr --bootorder 0002,0001,0000

systemd-boot を UEFI から完全に除去したい場合は bootctl remove を実行します。ただし、GRUB が正常に動作することを確認してから実行するのが安全です。ESP 上のローダー設定ファイル（/loader/ ディレクトリ）は手動で削除するかどうか、チームで方針を決めておくとよいでしょう。

なお、systemd-boot で起動できない状態でロールバック作業が必要になった場合は、ライブ USB 等でシステムを起動し、chroot 環境から上記コマンドを実行します。この手順を事前に習得しておくと、障害時の対応速度が大きく変わります。

2026年時点の主要ディストリ対応状況と実務上の注意点

2026年現在、Fedora は Fedora 37 以降の新規インストールで systemd-boot をデフォルト採用しており、BLS（Boot Loader Specification）に準拠したエントリ管理が標準となっています。kernel-install が自動でエントリを生成・削除するため、カーネルアップデート時の手作業が不要になっている点は運用上の大きなメリットです。

Ubuntu は 23.10 以降のインストーラーで systemd-boot を選択できるオプションが追加されましたが、LTS リリースでは依然として GRUB がデフォルトです。2026年時点の Ubuntu 24.04 LTS でも GRUB が標準であり、既存の Ubuntu 運用環境をそのまま移行する必然性は高くありません。

Arch Linux はどちらも公式サポートしており、インストール時にユーザーが選択できます。最近の Arch インストールガイドでは systemd-boot が比較的平易な手順として紹介されており、新規構築であれば選択肢として有力です。

実務上で注意が必要なのは、Unified Kernel Image（UKI）との組み合わせです。カーネル・initramfs・カーネルパラメータを一つの EFI バイナリにまとめる UKI は、Secure Boot との親和性が高く、systemd-boot 環境での採用が増えています。一方で、UKI を前提とした構成に移行すると、個別のカーネルパラメータ変更の手順がこれまでと大きく変わります。既存の運用手順書がある場合は、この点を合わせて更新する必要があります。

また、マルチブート構成（Windows との共存等）では、GRUB が Windows Boot Manager を検出して自動でエントリを生成する機能が利用できなくなります。systemd-boot でも手動でエントリを追加することは可能ですが、Windows アップデート後にブートエントリが変化するケースへの対応を事前に検討しておく必要があります。

systemd-boot へ移行するかどうかは、環境の複雑さと運用チームの習熟度次第です。シンプルな UEFI シングルブート環境で Fedora 系を扱う現場では、すでに移行済みであることも多く、新規サーバー構築の際に迷う場面は少なくなっています。一方でレガシー構成が残るミックス環境では、GRUB の柔軟性がまだ有効に機能する場面も多いため、目的と制約を整理したうえで判断することが重要です。