アプローチの比較：Linux起動障害への対処法
定期メンテナンスの直後にサーバーが起動しなくなることほど、業務を一瞬で混乱に陥れる事態はありません。カーネル更新の失敗、予期せぬ停電、ストレージ設定でのタイポ（入力ミス）などにより、画面が真っ暗なまま停止したり、grub rescue> プロンプトで立ち往生したりすることがあります。
OSの起動プロセスが停止した場合、通常は次の3つのアプローチが考えられます。
| アプローチ | 典型的な作業フロー | 復旧速度 | 失敗リスク |
|---|---|---|---|
| 自動修復ディスク（例：Boot-Repair） | デスクトップ版ISOを起動し、自動修復ボタンをクリックしてスクリプトの推測に任せる。 | 5〜10分 | mdadm RAID、LVMボリューム、LUKS暗号化、標準外のEFI構成ではリスクが高い。 |
| フルバックアップからのリストア（スナップショット／イメージ） | ルートパーティションイメージの再書き込み、またはハイパーバイザー／ZFSスナップショットのロールバック。 | 30〜90分 | 前回のバックアップ以降にコミットされたすべてのトランザクションでデータ損失が確実に発生する。 |
| Live USB経由の手動Chroot | ホストのパーティションをマウントし、仮想ファイルシステムをバインドして、ルートシェルに直接入る。 | 5〜15分 | 低い。推測に頼らず、すべてのコマンドを管理者の完全な制御下で実行可能。 |
GUIベースの自動修復ユーティリティは、マルチディスクアレイや複雑なボリュームグループに直面すると失敗することが珍しくありません。また、スナップショットのロールバックは有効な手段ですが、スナップショット取得後に作成された最新のデータベース書き込みやランタイムログが消失してしまいます。一方、chroot（change root）セッションを利用すれば、これら両方の問題を回避できます。Live USBから障害の発生したディスク環境に入ることで、サーバー本来のネイティブパッケージマネージャーやツールを実行し、実際の設定ファイルを直接修正できます。
Chrootによる復旧ワークフローのメリットとデメリット
chrootによる復旧はすべてのシステム管理者にとって必須のスキルですが、慎重な作業が求められます。レスキューシェルを開く前に、以下のトレードオフを把握しておきましょう。
メリット
- ネイティブバイナリの実行: インストール済みディストリビューションのネイティブパッケージマネージャー（
apt、dnf、pacmanなど）を直接実行できます。ライブラリの不一致や外部のツールチェーンに悩まされることはありません。 - 独自の依存関係が不要: 700MB程度の軽量なDebian netinstやUbuntu Serverのイメージなど、一般的なISOであれば追加ツールなしですぐに使用できます。
- ピンポイントでの修復: 正常なファイルシステムに影響を与えることなく、破損したコンポーネントだけをピンポイントで修正できます。たとえば
/etc/fstabのUUIDが間違っているだけなら、その1行を修正するだけで済み、残り500GBのアプリケーションデータには一切手を触れずに済みます。 - 高い作業透明性: ディスクへの永続的な書き込みを行う前に、生のパーティションテーブル、UUIDのマッピング、EFI起動変数などを直接確認できます。
デメリット
- 厳密なマウント前提条件:
/dev、/proc、/sysなどの仮想ファイルシステムのマウント（バインド）を忘れると、明確なエラーログが出ないままGRUBスクリプトやカーネルの事後インストールフックが失敗します。 - セーフガードがない: 制限のないroot権限で作業するため、
dd、fdisk、rm -rfコマンドでのタイポ1つが正常なパーティションを恒久的に破壊するリスクがあります。 - アーキテクチャの制限: Live環境のCPUアーキテクチャが、修復対象のシステムと一致している必要があります。QEMUユーザーエミュレーションを設定しない限り、x86_64のLiveイメージからarm64環境にchrootすることはできません。
推奨される事前準備
緊急事態が発生してからレスキューメディアを作成するのでは手遅れです。あらかじめ Ventoy を設定した専用の32GBまたは64GBのUSBメモリを用意しておきましょう。Ubuntu 24.04/22.04 LTS、Debian 12、AlmaLinux 9などの最新ISOファイルを直接保存しておけば、数時間におよぶダウンタイムになるはずだったトラブルを、わずか10分の作業で解決できます。
このアプローチは、低速なアウトオブバンドネットワーク経由の復旧においても大幅な時間短縮になります。15Mbpsの回線環境でIPMI仮想メディアセッションを使って60GBの生イメージを転送すると1時間以上かかりますが、1.5GB程度のISOをRAMに直接ロードして起動すれば、10分未満でサーバーの診断と修復を完了できます。
修復コマンドを実行する前に、以下の簡易チェック項目を確認してください。
- マシンが レガシーBIOS（MBR） と UEFI のどちらで起動しているか確認します。Live環境で
/sys/firmware/efiディレクトリが存在するかどうかをチェックしてください。 - パーティション構成を特定します。LVMやLUKS暗号化の有無を考慮しつつ、ルート（
/）、ブート（/boot）、EFIシステムパーティション（ESP）の場所を把握します。 - ネットワーク接続を確認します。破損したカーネルパッケージを再インストールする必要がある場合は、LiveホストからDNSおよびデフォルトゲートウェイと通信できることを確認してください。
実践ガイド：起動不能なシステムの復旧手順
ステップ1：Live環境を起動してパーティションを特定する
レスキューメディアを挿入してLiveコンソールを起動し、lsblk を使用して接続されているすべてのブロックストレージを確認します。
# ファイルシステム、サイズ、UUIDを含むデバイステーブルを表示
lsblk -o NAME,FSTYPE,SIZE,FSAVAIL,FSUSE%,MOUNTPOINTS,UUID
# パーティションテーブルの種類を確認（GPT vs DOS/MBR）
sudo parted -l対象のパーティションを特定します。本ガイドでは、/dev/nvme0n1（SATAシステムの場合は /dev/sda）にあるNVMeストレージ環境を前提とします。
/dev/nvme0n1p1: EFIシステムパーティション（vfat、512MB）/dev/nvme0n1p2: ブートパーティション（ext4、1GB、独立した/boot構成の場合）/dev/nvme0n1p3: ルートファイルシステム（ext4またはxfs、約100GB）
ステップ2：対象パーティションと仮想ファイルシステムのマウント
ルートパーティションを /mnt にマウントします。次に、chroot環境内のシステムユーティリティがハードウェアテーブル、プロセスツリー、デバイスノードを読み取れるように、カーネルの仮想ランタイムファイルシステムをバインドマウントします。
# 1. メインのルートファイルシステムをマウント
sudo mount /dev/nvme0n1p3 /mnt
# 2. 別パーティションにある場合は /boot をマウント
sudo mount /dev/nvme0n1p2 /mnt/boot
# 3. EFIシステムパーティションをマウント（UEFIシステムのみ）
sudo mount /dev/nvme0n1p1 /mnt/boot/efi
# 4. カーネル仮想ファイルシステムをバインドマウント
for dir in /dev /dev/pts /proc /sys /run; do
sudo mount --bind "$dir" "/mnt$dir"
done
# 5. chroot内でのネットワーク接続を確保するためホストのDNS設定をコピー
sudo cp -L /etc/resolv.conf /mnt/etc/resolv.confステップ3：Chroot環境に入る
ルートの実行コンテキストをマウントしたディスクに切り替えます。
sudo chroot /mnt /bin/bash
# 標準の実行パスを設定し、環境変数をロード
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
source /etc/profile 2>/dev/nullこれで対象のOS内部で直接作業できる状態になりました。ここで行うすべての変更は、永続ストレージに直接反映されます。
ステップ4：修復シナリオ1 — fstabのUUID不一致の修正
ストレージボリュームの再フォーマットや新しい仮想ディスクへの移行を行うと、UUIDが変更されます。/etc/fstab が古いIDを参照したままだと、systemdは Timed out waiting for device /dev/disk/by-uuid/... というエラーを出力し、緊急メンテナンスプロンプトで起動を停止します。
現在のデバイスのUUIDを確認し、fstabの記述と突き合わせます。
# 有効なパーティションのUUIDを一覧表示
blkid
# 現在の静的マウント定義を確認
cat /etc/fstab誤ったエントリがある場合は、ファイルをエディタで開き、blkid の現在の出力に合わせてUUID文字列を更新します。
nano /etc/fstab重要度の低いセカンダリマウント（データ専用ディスクやNFS共有など）については、4列目のマウントオプションに nofail を追記しておきます。これにより、補助ドライブが見つからない場合でも、OSがmulti-userターゲットまで正常に起動できるようになります。
ステップ5：修復シナリオ2 — GRUBの再インストールと更新
デュアルブートインストーラーの実行、アップデートの中断、ディスククローンなどによってブートローダーが破損した場合は、GRUBをクリーンに再インストールします。
UEFIシステムの場合：
作業を進める前に /sys/firmware/efi が存在することを確認してください。その後、EFIバイナリを再インストールし、マザーボードのNVRAMブートエントリに登録します。
# マウントされたESPにGRUBのEFIバイナリを再インストール
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --recheck
# クリーンな /boot/grub/grub.cfg を生成
update-grubレガシーBIOS（MBR）システムの場合：
対象にはベースとなるディスクデバイス（/dev/sda や /dev/vda など）を指定します。/dev/sda1 のような個別のパーティション番号は絶対に指定しないでください。
# マスターブートレコード（MBR）およびpost-MBRギャップにブートコードを直接書き込み
grub-install --target=i386-pc /dev/sda
# ブートローダーメニューを再生成
update-grubステップ6：修復シナリオ3 — 破損したカーネルとInitramfsの再構築
カーネル更新中にパッケージ処理が中断された場合、ramdiskイメージが破損または消失している可能性があります。これにより、起動初期に kernel panic - not syncing: VFS: Unable to mount root fs というエラーが発生します。chroot環境内でramdiskを再構築し、未完了のdpkgトランザクションをクリーンアップします。
# 1. 中断されたパッケージ設定を完了
dpkg --configure -a
# 2. 現在インストールされているカーネルイメージを確認
dpkg -l | grep -E 'linux-image|linux-headers'
# 3. 本番用カーネルメタパッケージを再インストール（Debian/Ubuntu）
apt-get update
apt-get install --reinstall -y linux-image-generic
# 4. 検出されたすべてのカーネルバージョン向けにinitramfsを再生成
update-initramfs -c -k all
# 5. 再構築したinitrdを認識させるためにGRUB設定を更新
update-grubステップ7：安全な終了と再起動
生のパーティションやカーネル仮想ファイルシステムが /mnt にバインドマウントされた状態で再起動してはいけません。不意のリセットはファイルシステムにダーティフラグを残したり、書き込みバッファを破損させたりする原因になります。chroot環境を抜けて、パーティションを安全にアンマウントしてください。
# chrootシェルを終了
exit
# 末端のマウントポイントから順にすべてのマウントを再帰的に解除
sudo umount -R /mnt
# システムを安全に再起動
sudo rebootハードウェアの初期化が始まったらUSBメモリを取り外します。サーバーは復旧したブートローダーへと正常に制御を引き渡し、検証済みの /etc/fstab を読み込んで、新たに生成されたinitramfsから正常に起動します。
