GRUB2更新時のブート不能を防ぐUEFIフォールバック設計と本番復旧フロー

月次のCVE対応でGRUB2パッケージを更新したあと、サーバーが起動しなくなる——こうしたトラブルは珍しくありません。特に物理サーバーやリモートKVMしか手段のない環境では、復旧に数時間を要することもあります。UEFIには「フォールバックブートパス」と呼ばれる安全網が仕様として定義されており、これを事前に活用しておくことでリスクを大幅に下げられます。本記事では、フォールバック設計の背景から事前準備・更新手順・復旧フローまでを一連の運用シナリオとして整理します。

GRUB2更新がブート不能を引き起こす仕組み

UEFI環境でLinuxが起動するまでの流れを簡単に確認します。UEFIファームウェアは起動時にNVRAM（不揮発性メモリ）に記録されたブートエントリを参照し、指定のEFIパーティション（ESP: EFI System Partition）内のファイルパスへジャンプします。たとえば /boot/efi/EFI/redhat/grubx64.efi や /boot/efi/EFI/ubuntu/grubx64.efi がその実体です。

GRUB2のパッケージ更新では、この grubx64.efi 本体や設定ファイルが書き換わります。問題が生じやすいのは次の場面です。

• パッケージ更新スクリプトが grub2-install を再実行し、NVRAMのブートエントリが意図せず書き換わる
• Secure Bootの署名付きEFIバイナリが新旧で整合しなくなり、検証エラーでファームウェアが起動を拒否する
• EFIパーティションの空き容量不足やファイルシステム破損が更新処理と重なる
• 仮想化環境でEFIパーティションがゲストとホストで共有されており、更新順序の制御が難しい

NVRAMのブートエントリが失われたり壊れたりすると、ファームウェアは次のフォールバック動作に移行します。これがUEFI仕様で定められた「フォールバックブートパス」です。

UEFIフォールバックブートパスの仕組みと活用戦略

UEFI仕様（UEFI Specification 2.x）では、NVRAMのブートエントリがすべて失敗した場合、ファームウェアは決まったパスにあるEFIファイルを試みます。x86_64の場合、このパスは次のように定義されています。

\EFI\BOOT\BOOTX64.EFI

ESPのマウントポイントを /boot/efi とすると、実際のパスは /boot/efi/EFI/BOOT/BOOTX64.EFI になります。このファイルが存在すれば、NVRAMのエントリが消えても自動的に読み込まれます。

活用戦略としては、GRUB2の更新前にディストリビューション固有のGRUBローダーをフォールバックパスへコピーしておく方法が有効です。更新後にNVRAMが壊れても、フォールバックパスのGRUBが起動し、そこから /boot/grub2/grub.cfg を読み込んでLinuxカーネルを呼び出せます。

なお、フォールバックパスはUEFI仕様上の最終手段であり、すべてのファームウェアが同一の挙動をするとは限りません。サーバーベンダーや仮想化プラットフォームによって挙動が異なる場合があるため、事前に検証環境で確認してから本番に適用することを推奨します。

更新前の事前準備：バックアップとフォールバック配置

GRUB2の更新作業に入る前に、以下の準備を済ませます。

現在のブートエントリを記録する

efibootmgr でNVRAMのブートエントリをファイルに書き出しておきます。

efibootmgr -v > /root/efibootmgr_backup_$(date +%Y%m%d).txt

出力には BootCurrent（現在の起動エントリ番号）・BootOrder（試行順序）・各エントリのデバイスパスとファイルパスが含まれます。復旧時にこの情報が重要になります。

EFIファイルをフォールバックパスへコピーする

フォールバック用ディレクトリを作成し、現在の起動可能なGRUBローダーをコピーします。Rocky Linux 9 / RHEL 9 の場合の例を以下に示します。

# フォールバックディレクトリを作成
mkdir -p /boot/efi/EFI/BOOT

# 現行の署名済みGRUBローダーをフォールバックパスへコピー
cp /boot/efi/EFI/redhat/grubx64.efi /boot/efi/EFI/BOOT/BOOTX64.EFI

# shimがある環境では shim もコピー（Secure Boot有効時）
cp /boot/efi/EFI/redhat/shimx64.efi /boot/efi/EFI/BOOT/BOOTX64.EFI

Secure Bootが有効な環境では、shim経由でGRUBを呼び出す構成が標準です。その場合はshimをフォールバックパスに置き、shimがGRUBを呼び出せるようにGRUBのパスを grubx64.efi として同一ディレクトリに配置します。

# Secure Boot環境での配置（RHEL/Rocky系の想定例）
cp /boot/efi/EFI/redhat/shimx64.efi  /boot/efi/EFI/BOOT/BOOTX64.EFI
cp /boot/efi/EFI/redhat/grubx64.efi  /boot/efi/EFI/BOOT/grubx64.efi

スナップショット・バックアップの確認

LVMシンプロビジョニングやBtrfsを使っている環境では、更新前にスナップショットを取得します。クラウド環境であればボリュームスナップショットを作成します。ESPそのものは数百MBの小さなFAT32パーティションなので、dd や tar でイメージを取得しておくことも有効です。

# ESP全体をイメージとして保存（/dev/sdaX はESPのデバイス）
dd if=/dev/sdaX of=/root/esp_backup_$(date +%Y%m%d).img bs=4M status=progress

GRUB2更新の実施と事後検証

準備が整ったら実際の更新作業に進みます。ディストリビューションごとに更新コマンドが異なります。

RHEL / Rocky Linux 9 系

# GRUBパッケージのみ更新（他のパッケージを巻き込まない）
dnf update grub2-efi-x64 grub2-efi-x64-modules shim-x64 --disablerepo='*' --enablerepo='baseos'

# grub.cfg の再生成
grub2-mkconfig -o /boot/grub2/grub.cfg

Ubuntu 22.04 / 24.04

apt-get install --only-upgrade grub-efi-amd64 grub-efi-amd64-signed shim-signed
update-grub

更新後の事後検証

更新完了後、以下の確認を行います。

• efibootmgr -v でブートエントリが更新前と同等に存在するか確認する
• ls -lh /boot/efi/EFI/BOOT/BOOTX64.EFI でフォールバックファイルが残っているか確認する（更新スクリプトが上書きした可能性がある）
• フォールバックファイルが古いままの場合は再度コピーし直す
• 可能であれば一度リブートし、起動を確認してから次のホストに展開する

バッチ更新を自動化している場合、更新後スクリプトでフォールバックパスへの再コピーを組み込んでおくと確実です。

ブート不能時の本番復旧フロー

それでも起動しない場合の復旧手順を、症状に応じて整理します。

UEFIシェルから復旧する

多くのサーバーBIOSやIPMI/iDRACコンソールにはUEFIシェルへのアクセス手段があります。UEFIシェルに入れた場合、ESPのファイルを直接実行できます。

# UEFIシェルでESPを探してマウント（FS0:〜FS2:のどれかがESP）
Shell> map -r
Shell> FS0:
FS0:\> ls EFI\BOOT\
FS0:\> EFI\BOOT\BOOTX64.EFI

フォールバックファイルが存在すれば BOOTX64.EFI を直接実行してGRUBを起動できます。GRUBのプロンプトが出れば、カーネルパスを手入力して起動できます。

レスキューメディアから復旧する

UEFIシェルでの操作が困難な場合、ISOレスキューメディア（ディストリのインストールISOにレスキューモードが含まれます）から起動します。

# レスキューモードでchroot環境に入った後
# ESPをマウント
mount /dev/sdaX /mnt/boot/efi

# GRUBを再インストール
grub2-install --target=x86_64-efi --efi-directory=/mnt/boot/efi --bootloader-id=redhat

# NVRAMのエントリを再作成（efibootmgr_backup の内容を参照）
efibootmgr --create --disk /dev/sda --part 1 --loader '\EFI\redhat\grubx64.efi' --label 'Red Hat Enterprise Linux'

# grub.cfgを再生成
chroot /mnt grub2-mkconfig -o /boot/grub2/grub.cfg

バックアップしておいた efibootmgr_backup ファイルを参照して、元のエントリに合わせた --loader パスを指定します。ここでパスを誤ると再び起動しなくなるため、コピーアンドペーストではなくバックアップファイルを確認しながら入力します。

ESPイメージから復元する

ESPのイメージバックアップを取得していた場合は、最終手段として書き戻しできます。ただしこれはESP全体を上書きするため、更新後の新しいカーネルエントリが消える点に注意が必要です。

# レスキュー環境で実行（/dev/sdaX はESPデバイス）
dd if=/root/esp_backup_20261105.img of=/dev/sdaX bs=4M status=progress

2026年現行環境での差分と注意点

2025年後半から2026年にかけて、主要ディストリビューションのGRUB2まわりにいくつかの変化があります。

RHEL 9 / Rocky Linux 9 系

RHEL 9.4以降では grub2-efi-x64 パッケージの更新時に自動でNVRAMエントリを修正するスクリプトが走るようになっています。意図せずブートオーダーが変わるケースが報告されているため、更新後は必ず efibootmgr -v で確認する習慣をつけます。また、UKI（Unified Kernel Image）への移行がFedora系では進んでおり、将来的にGRUBを経由しない起動フローが標準になる可能性があります。現時点のRHEL 9はまだGRUB2が主流です。

Ubuntu 24.04 LTS

Ubuntu 24.04は引き続きGRUB2＋shimのスタック構成ですが、grub-efi-amd64-signed パッケージの更新でフォールバックパスが自動更新されるケースと上書きされないケースの両方が確認されています。更新後に /boot/efi/EFI/BOOT/BOOTX64.EFI のタイムスタンプを確認し、更新前のものが残っている場合は手動でコピーし直します。

Secure Boot DBX更新との組み合わせ

2025年以降、MicrosoftのDBX（Secure Boot禁止リスト）更新が定期的に配布されており、古い署名のshimやGRUBがブロックされるケースが増えています。GRUBパッケージ更新と同じタイミングでDBX更新が来た場合、フォールバックパスに置いた古いshimがSecure Boot検証で弾かれて起動しないことがあります。フォールバックファイルは更新のたびに最新版に差し替えるルールを運用フローに組み込むことが重要です。

クラウド・仮想化環境での注意

AWS EC2（Nitro系）やGoogle Compute Engineでは、EFIパーティションがインスタンスのブートボリュームとは独立した仮想NVRAMで管理されるため、ゲスト内からの efibootmgr 操作が無効になる場合があります。これらの環境では、ブート設定の変更はクラウドコンソールや専用CLIで行うことが前提です。フォールバックファイルの配置自体は有効ですが、NVRAMエントリの復旧手順はオンプレミスと異なります。事前にプラットフォーム固有の復旧手順を確認しておきます。