「GRUB rescue>」の黒い画面が表示されたとき
CentOS Stream 9サーバーでカーネルのアップデートやパーティションの変更を行い、rebootコマンドを入力したとします。しかし、ログイン画面の代わりに、絶望的なgrub rescue>という文字列が返ってくることがあります。実行中のすべてのサービスが突然停止し、管理者の肩に重圧がのしかかる瞬間です。
私自身、かつて誤って/bootディレクトリ内のファイルを削除してしまい、同じ状況に陥ったことがあります。その時、真っ先に思い浮かんだのは再インストールでしたが、それではこれまでの複雑な設定がすべて失われてしまいます。幸いなことに、Rescue ModeとChrootという強力なツールに救われました。これらを使えば、1バイトのデータも失うことなく、壊れたシステムに「潜入」して内部から修復することが可能です。
なぜサーバーは突然起動しなくなるのか？
実際の運用現場では、Linuxシステムが「ストライキ」を起こす主な原因として以下の3つのシナリオが挙げられます。
- ブートローダー（GRUB）の破損： カーネルアップデート中のエラーや、ブートレコード（Boot record）の書き換えが主な原因です。
- マウント設定ファイルのミス：
/etc/fstabに一文字タイポがあるだけで、OSは必要なパーティションを見つけられずフリーズします。 - ドライバーの競合： アップグレードした新しいカーネルが、サーバーの古いハードウェアと互換性がない場合に発生します。
SSH接続ができない場合、VMのコンソールを使用するか、物理サーバーに直接モニターを接続して操作する必要があります。
起動エラーで焦って再インストールしてはいけない
経験の浅い管理者の多くは、スナップショットの復元やOSの再インストールを選びがちです。スナップショットの復元は迅速ですが、前回のバックアップ以降の最新データはすべて失われます。再インストールはどうでしょうか？それは最も時間がかかる方法であり、本番環境においては極めて非効率な選択です。
Rescue Modeを使用するのが最短ルートです。ISOファイルから起動し、古いハードディスクをマウントしてchrootコマンドを実行するだけです。これにより、救助環境が実際のサーバー環境へと切り替わり、エラーが発生する前と同じように操作できるようになります。
CentOS Stream 9 サーバーの救出手順
以下は、私が通常15分ほどで迅速に処理するために適用している手順です。
ステップ 1：Rescue Modeへのアクセス
CentOS Stream 9のISOファイルを用意し、マシンにマウントします（USBまたは仮想ドライブ経由）。
- 起動し、ISOからブートすることを選択します。
- メインメニューで、Troubleshootingを選択します。
- Rescue a CentOS Stream systemを選択します。
画面に4つの選択肢が表示されたら、1（Continue）を押します。システムがディスクをスキャンし、古いOSを一時ディレクトリ/mnt/sysrootに自動的にマウントします。
# メッセージが表示されたらEnterを押してシェルに入ります
sh-5.1#ステップ 2：Chrootを使用して旧システムに「乗り移る」
この時点では、ISOディスクの環境にいます。サーバーのファイルを修正するには、次のコマンドを使用してルートディレクトリをマシンのハードディスクに切り替える必要があります。
chroot /mnt/sysrootコマンドプロンプトが変化します。これで、実行するすべての変更がエラーの発生しているシステムに直接反映されるようになります。
ステップ 3：GRUBエラーの処理
カーネル選択メニューが表示されないエラーの場合、GRUBを再インストールする必要があります。lsblkコマンドを使用して、ハードディスクの正確な名前（例：/dev/sdaや/dev/vda）を確認してください。
レガシーBIOS（旧標準）の場合：
grub2-install /dev/sda
grub2-mkconfig -o /boot/grub2/grub.cfgモダンなUEFI規格の場合：
dnf reinstall grub2-efi shim
grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfgステップ 4：システムファイルの編集とパスワードのリセット
/etc/fstabに問題がある場合は、viでファイルを開きます。エラーが発生する前に追加した不明なマウント行を削除またはコメントアウトしてください。
vi /etc/fstabついでに、rootパスワードを忘れてしまった場合は、ここで変更することも可能です：
passwd rootステップ 5：SELinuxのリラベルを有効にして再起動
これは最も忘れがちなステップです。外部環境から介入すると、ファイルのSELinuxセキュリティラベルが正しくなくなり、再起動後にログインできなくなる可能性があります。
# 起動時にシステムにSELinuxラベルの再スキャンを要求する
touch /.autorelabel
exit
reboot再起動後、autorelabelプロセスが実行されます（データ量によりますが、約2〜5分かかります）。辛抱強くお待ちください。
実務での経験
chroot技術は、単に起動エラーを直すためだけのものではありません。かつてデータセンターの移転に伴い、5台のサーバーのIPを一括で変更し、ネットワーク設定を再構成しなければならなかったことがありました。Rescue Modeを使用することで、実行中のサービスによる制限を気にすることなく、システム設定に深く介入することができました。
注意点：ls /bootコマンドで、/bootパーティションがマウントされているか必ず確認してください。ディレクトリが空の場合は、grub2-installコマンドを実行する前に手動でマウントする必要があります。
Rescue Modeをマスターすれば、サーバーにトラブルが発生しても冷静さを保てるようになります。なぜなら、システムへの扉を再び開くための鍵を自分が持っていると確信できるからです。
