Linuxが起動しないときにブートローダーを修復する実務手順

Linuxサーバーが突然起動しなくなり、画面に grub rescue> や error: no such partition が表示されたとき、焦らず対処できる手順をまとめました。原因の多くはブートローダー（GRUB2）の設定破損またはEFIパーティション・MBRへの書き込みミスです。live USBを使ったchroot復旧が最速の解決策です。

復旧の最短ルート：live USBでchrootしてGRUBを再インストールする

同系統ディストリのlive USB（インストールメディアでも可）を用意し、対象マシンで起動します。以下はUbuntu/Debian系とRHEL系（Rocky Linux・AlmaLinux等）に共通の流れです。

1. パーティション構成を確認する

# live環境でrootになっておく
sudo -i

# ディスク構成とファイルシステムを確認
lsblk -f
fdisk -l /dev/sda

/dev/sda1 がEFIパーティション（FAT32）、/dev/sda2 が /boot、/dev/sda3 がルート（/）というのが典型的な構成です。NVMeディスクでは nvme0n1p1 のように表記が変わります。lsblk -f でUUIDとマウントポイントを確認してから作業を進めてください。

2. ルートパーティションをマウントしてchrootする

# ルートパーティションをマウント（例：/dev/sda3 → 環境に合わせて変更）
mount /dev/sda3 /mnt

# /bootが別パーティションの場合
mount /dev/sda2 /mnt/boot

# UEFI環境ではEFIパーティションも忘れずにマウント
mount /dev/sda1 /mnt/boot/efi

# 仮想ファイルシステムをバインドマウント
for dir in proc sys dev dev/pts run; do
    mount --bind /$dir /mnt/$dir
done

# 対象環境にchrootで入る
chroot /mnt

3. GRUBを再インストールして設定を再生成する

# ---- UEFI（GPT）環境の場合 ----
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB

# ---- Legacy BIOS（MBR）環境の場合（ディスク全体を指定） ----
grub-install /dev/sda

# ---- 設定ファイルを再生成（どちらの環境でも実行） ----
update-grub                                      # Debian/Ubuntu系
# または
grub2-mkconfig -o /boot/grub2/grub.cfg          # RHEL系（Rocky/AlmaLinux等）

エラーなく完了したら exit でchrootを抜け、バインドマウントをアンマウントしてから reboot します。大半のケースはこれだけで起動が回復します。

ブートローダーが壊れる典型的なシナリオ

ディスク交換・増設後のデバイス名変動：SATAポートの差し替えや仮想マシンへのディスク追加で /dev/sda と /dev/sdb が入れ替わり、GRUBが正しいパーティションを参照できなくなるケースです。/etc/fstab でデバイス名を直書きしている環境ほど発生しやすく、UUIDへの統一が予防策になります。

WindowsとのデュアルブートでWindowsがMBR・EFIエントリを上書き：Windowsの機能更新プログラムや修復インストールがGRUBのエントリを消すことがあります。UEFI環境では efibootmgr -v でエントリが残っているか確認してください。

パッケージアップデート中の中断：dnf upgrade や apt upgrade の途中でカーネルアップデートが止まると、initramfs や grub.cfg が中途半端な状態になることがあります。UPSのないサーバー室での停電後によく見られます。

UEFI環境特有の注意点

現代のサーバー・PCはほぼUEFIです。Legacy BIOS（MBR）とは手順が異なる点がいくつかあります。

EFIパーティション（ESP）の確認：fdisk -l で EFI System と表示されるパーティションがESPです。FAT32でフォーマットされており、通常 /boot/efi にマウントします。このパーティション自体が消去・破損している場合は、mkfs.vfat で再フォーマットしてから grub-install を実行する必要があります。

# EFIブートエントリの一覧確認
efibootmgr -v

# GRUBエントリが消えている場合に手動追加する例
efibootmgr --create --disk /dev/sda --part 1 \
  --label "GRUB" \
  --loader '\EFI\GRUB\grubx64.efi'

Secure Bootが有効な場合：UEFI Secure BootはBIOSレベルで署名されていないブートローダーの実行を拒否します。カスタムカーネルや非公式のGRUBをインストールした直後に起動しなくなった場合は、UEFI設定画面でSecure Bootを一時的に無効化して動作確認するのが最速の切り分け方法です。

GRUBプロンプトからの応急起動（live USBがない場合）

grub rescue> ではなく grub> プロンプトが表示されている場合は、コマンドを手入力してLinuxを一時起動できることがあります。起動後に恒久的な修復作業（grub-install と update-grub）を行ってください。

# grub> プロンプトでパーティション一覧を確認
ls

# (hd0,gpt2) のような形式でパーティションを確認しながら特定する
ls (hd0,gpt2)/

# カーネルとinitrdを指定して起動（パスは環境に合わせて変更）
set root=(hd0,gpt2)
linux /vmlinuz root=/dev/sda3 ro quiet
initrd /initrd.img
boot

GRUBの内部パーティション表記はディストリのデバイス名とは異なります。ls (hd0,gpt1)/ のようにタブ補完を使いながら目的のパーティションを特定してください。

よくある落とし穴と対処法

「grub-install: error: cannot find EFI directory」：EFIパーティションのマウント忘れが原因です。mount /dev/sda1 /mnt/boot/efi を実行してから再試行してください。

「Warning: File system `ext2′ doesn’t support embedding」：GPT環境でLegacy BIOSモードの grub-install を実行したときに出ます。GPT+Legacy BIOSの組み合わせでは1MiB程度の「BIOSブート用パーティション」（タイプ: BIOS boot）が必要です。まずディスクがUEFI/Legacyどちらの環境か再確認してください。

「Exec format error」でchrootに失敗する：live USBとターゲットのCPUアーキテクチャが一致していない場合に起きます。x86_64環境にはx86_64のメディア、arm64環境にはarm64のメディアを使用してください。

ある運用現場では、仮想基盤のスナップショットからVMを復元した直後にGRUBが壊れるトラブルが続いていました。調査の結果、スナップショット取得時にディスクのUUIDが変わっており、/etc/fstab および grub.cfg の参照先がずれていたことが原因でした。UUIDベースの設定と定期的な update-grub（または grub2-mkconfig）の実行が予防策になります。