起動できない時の初動 - kernel panic と緊急モード

起動できない時の初動 - kernel panic と緊急モード
読了時間: 約12分 難易度: 中級

この記事で解決できること

  • 画面が kernel panic で固まる・(initramfs) で止まる・緊急モードに落ちる、それぞれの 意味と違い が分かる
  • 起動失敗が どの段階で止まっているか を切り分けられる
  • GRUB からの旧カーネル起動・fstab 修復・fsck による 最短の復旧手順 が身につく

結論（切り分けの型）

起動失敗は「どの段階で止まったか」で対処が全く変わる。上から順に到達点を確認する。

  1. grub rescue> / grub> → ブートローダ段階で停止（GRUB 設定・モジュール喪失）
  2. (initramfs) プロンプト → root ファイルシステムをマウントできない（初期ユーザ空間）
  3. Kernel panic - not syncing: ... → カーネルが回復不能で停止
  4. 緊急モード（emergency / rescue）のシェル → ユーザ空間には到達、起動が途中で失敗（多くは fstab）

前提（対象環境）

  • ディストリ：Ubuntu / Debian 系（systemd・GRUB 2 を想定）
  • 物理コンソール または クラウドのシリアルコンソール / VNC で画面が見える状態
  • 復旧操作には root 権限が必要（緊急モードのシェルは root）

起動失敗はどの段階で止まっているか？

結論: 画面に出る文字列で段階を判定する。grub ならブートローダ、(initramfs) なら root マウント失敗、Kernel panic ならカーネル停止、emergency mode ならユーザ空間到達後の失敗。

Linux の起動は大きく次の順で進む。止まった場所を特定することが復旧の第一歩。

段階 画面に出るサイン 主な原因
1. ブートローダ grub rescue> / grub> GRUB 設定・/boot の喪失、パーティション変更
2. 初期ユーザ空間 (initramfs) プロンプト root デバイスが見つからない、FS 破損
3. カーネル Kernel panic - not syncing: root マウント不能、必須ドライバ欠如、initramfs 破損
4. systemd You are in emergency mode / rescue mode fstab のミス、必須マウント失敗、サービス起動失敗

まず試す価値があるのは旧カーネル起動

直前のカーネル更新後に起動しなくなった場合、GRUB の「Advanced options」から 1 つ前のカーネルで起動するだけで復旧することが多い（後述）。

kernel panic とは何か？

結論: kernel panic は、カーネルが回復不能なエラーを検知して安全のため停止した状態。多くは root ファイルシステムをマウントできない、または必須ドライバ・initramfs の欠落が原因。

カーネルが内部で致命的な矛盾を検知すると、これ以上続行するとデータ破壊につながると判断して意図的に停止する。これが kernel panic。アプリのクラッシュとは違い、システム全体が止まる。

典型的なメッセージ:

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

これは「root ファイルシステムをマウントできなかった」サイン。よくある原因:

  • カーネル更新後に initramfs が壊れている / 古い（必要なストレージドライバが含まれていない）
  • GRUB の root= パラメータが指す UUID / デバイスが変わった
  • ストレージ構成変更（LVM / RAID / ディスク交換）で root が見つからない

別パターンの Kernel panic - not syncing: Attempted to kill init! は、init（systemd）が起動直後に死んだことを示す。initramfs や root FS の破損を疑う。

panic 画面はスクロールして消えることがある。**最初の数行（最上部）**に本当の原因が出る。クラウドならシリアルコンソールのログ、物理機なら写真を撮って最上部を確認する。

GRUB メニューから旧カーネルで起動するには？

結論: 起動時に GRUB メニューを出し、「Advanced options」から 1 つ前のカーネルを選ぶ。直近のカーネル更新が原因なら、これだけで起動できる。

カーネル更新直後の起動不能は、旧カーネルで起動して切り分けるのが最短。

  1. 電源投入後、GRUB メニューを表示する（出ない場合は起動中に Shift 長押し、UEFI なら Esc 連打）
  2. Advanced options for Ubuntu を選ぶ
  3. 一覧から 1 つ前のバージョンのカーネルを選んで起動

旧カーネルで起動できたら、現行カーネルの initramfs を作り直す:

$ sudo update-initramfs -u -k all
$ sudo update-grub

GRUB の起動エントリをその場で編集する

メニューでカーネルを選んだ状態で e を押すと、その場で起動パラメータを編集できる。

  1. 対象エントリで e を押す
  2. linux で始まる行の末尾（ro quiet splash など）にカーソルを移動
  3. 必要なパラメータを追記する（例: systemd.unit=rescue.target）
  4. Ctrl + X または F10 で起動

この編集は一時的で、再起動すると元に戻る。恒久化は /etc/default/grub 編集 + update-grub。

initramfs プロンプトで止まったら？

結論: (initramfs) プロンプトは root ファイルシステムをマウントできなかった状態。多くは FS 破損で、fsck をかけてから exit で起動を続行できる。

(initramfs) という BusyBox のプロンプトが出るのは、カーネルは起動したが root をマウントできなかったため。直前に次のような行が出ることが多い。

ALERT!  /dev/sda1 does not exist.  Dropping to a shell!

または FS の不整合検知。対処:

# 認識されているブロックデバイスを確認
(initramfs) cat /proc/partitions
(initramfs) ls /dev/sd* /dev/nvme*

# 対象パーティションを検査・修復（必ずアンマウント状態で）
(initramfs) fsck /dev/sda1

# 修復後、起動を続行
(initramfs) exit

fsck が「修復するか？」を聞いてきたら、原則 y。大量に出る場合は fsck -y /dev/sda1 で一括。終了後 exit で通常の起動シーケンスに戻る。

緊急モード（emergency / rescue）の入り方と違いは？

結論: rescue.target は基本サービスとローカル FS マウントありの単一ユーザ相当、emergency.target は root を read-only マウントするだけの最小環境。fstab 破損などでは emergency に自動的に落ちる。

systemd には復旧用の 2 つのターゲットがある。できることの範囲が違う。

ターゲット マウント サービス 用途
rescue.target ローカル FS をマウント 最小限を起動 単一ユーザ相当。通常の復旧作業向け
emergency.target root のみ read-only ほぼ起動しない 最も最小。fstab 破損時の最後の砦

意図的に rescue / emergency で起動する

GRUB の編集（e）で linux 行末尾に追記する。

# rescue モード（推奨。多くの復旧はこれで足りる）
systemd.unit=rescue.target

# emergency モード（最小構成）
systemd.unit=emergency.target

短縮形（rescue / emergency / 古い single 1）も使えるが、systemd.unit= 形式が確実。Ctrl + X で起動するとパスワード入力後に root シェルに入る。

緊急モードで root を書き込み可にする

emergency に落ちると root が read-only のことが多く、ファイルを編集できない。次で書き込み可に再マウントする。

$ mount -o remount,rw /

fstab のミスで緊急モードに落ちたら？

結論: /etc/fstab の記述ミスや存在しないデバイス指定は起動を止め、emergency モードに落とす。該当行を修正し、mount -a で全行を検証してから再起動する。

緊急モードへの転落で最も多いのが /etc/fstab の問題。追加したマウントの UUID 間違い、デバイス未接続、タイプミスなどで、systemd がマウント待ちのまま起動を諦める。

復旧手順:

# 1. root を書き込み可で再マウント
$ mount -o remount,rw /

# 2. 直近のブートログから失敗したマウントを特定
$ journalctl -xb | grep -i -E 'mount|fstab|dependency'

# 3. fstab を修正（問題行を一時的にコメントアウトしてもよい）
$ nano /etc/fstab

# 4. 設定を再読込し、全行のマウントを検証
$ systemctl daemon-reload
$ mount -a

mount -a がエラーなく完了すれば fstab は健全。エラーが出るなら、その行がまだ問題を抱えている。

事前の保険: 必須でないマウントには nofail オプションを付けておくと、そのデバイスが見つからなくても起動が止まらない。外付けディスクやネットワークマウントに有効。

UUID=xxxx  /mnt/data  ext4  defaults,nofail  0  2

ブートログをどう読むか？

結論: 復旧後は journalctl -xb で今回の、journalctl -b -1 で前回の失敗ブートを読む。赤字（失敗ユニット）と Dependency failed の行が起点。

起動できたら、再発防止のため何が起きたかを確認する。

# 今回のブート全体（-x で説明文付き）
$ journalctl -xb

# 直前（失敗した）のブート
$ journalctl -b -1

# 失敗したユニットだけを一覧
$ systemctl --failed

Dependency failed for ... や Failed to mount ... の行が、起動が止まった直接の原因を指す。ディスク I/O エラーが混じる場合はハードウェア障害も疑う。

前回ブートのログ（-b -1）を読むには永続ジャーナルが必要。/var/log/journal/ が無い環境では再起動でログが消える。sudo mkdir -p /var/log/journal && sudo systemctl restart systemd-journald で永続化しておく。

やってはいけないこと

結論: マウント中の FS への fsck、原因未確認のままの再インストール、panic 画面の見落としは事態を悪化させる。最上部のログと段階の特定を最優先する。

  • マウント中のファイルシステムに fsck をかける → データ破損。必ず read-only / アンマウント状態で
  • panic 画面の最後の行だけ見て判断 → 本当の原因は最上部。スクロールアウトに注意
  • 原因を切り分けずに OS 再インストール → fstab 1 行や旧カーネル起動で直るケースを潰してしまう
  • fstab を直さず問題行を放置 → 再起動のたびに emergency に落ちる
  • 永続ジャーナル未設定のまま再起動 → 失敗時のログが消えて原因不明になる

次に読む