🐧 Linux 総合学習プラットフォーム
プロセス監視/障害対応 ・ 中級〜上級

起動しないときの立て直し

システムが起動しないのはもっとも緊張する障害ですが、GRUB→カーネル→initramfs→systemdという起動段階のどこで止まったかを見れば、闇雲な作業を避けられます。emergency/rescueターゲットや前回起動ログの確認、fstabミスという定番の落とし穴、ライブUSBからのchroot修理まで、立て直しの道筋を概観します。

起動しない――数ある障害の中でも、これがいちばん心臓に悪い。動いていたはずのサーバに電源を入れても、画面がそこで止まったまま先に進まない。

だが慌てて手当たり次第に試すと、かえって状況を悪化させかねない。起動処理には決まった段階があり、「どの段階で止まったか」さえ分かれば、疑うべき範囲は驚くほど狭まる。

💡
ポイント起動不能は「どこで止まったか」を特定するゲームだ。全体を疑うのではなく、止まった段階だけに集中すれば復旧の道筋は意外と単純になる。

🪜 起動の4段階——GRUB→カーネル→initramfs→systemd

一般的なLinuxの起動処理は、大まかに4つの段階を順番に通過する。

1. GRUBブートローダカーネルを選ぶ2. カーネルハードを初期化3. initramfs本体を探してマウントする4. systemd各サービスを順に起動止まった段階だけを疑えば、調査範囲は一気に狭まる

1段階目はGRUBに代表されるブートローダだ。どのカーネルを、どんなオプション付きで起動するかを選ぶ役割を持つ。ここで止まるなら、ブートローダの設定やディスクの認識そのものに問題がある。

コツGRUBのメニュー画面でeキーを押すと、その起動時だけ一時的にカーネルの起動オプションを編集できる。設定ファイルを恒久的に書き換える前に、まずここで挙動を試せると分かっておくと、原因切り分けの選択肢が増える。

2段階目はカーネルの初期化だ。ハードウェアを認識し、基本的な機能を立ち上げていく。ここで止まる、あるいはパニックを起こす場合は、カーネル自体やハードウェアの深刻な問題を疑う。

この段階で完全に画面が固まる「カーネルパニック」は、数ある起動不能の中でもとくに深刻な部類だ。直前にハードウェア構成を変えていないか、あるいはカーネルの更新直後でないかを振り返ると、手がかりが見つかることがある。

3段階目はinitramfs(初期RAMファイルシステム)だ。本番のルートファイルシステムを探し出してマウントするための、小さな仮の実行環境になる。ここで止まる代表例が、ディスクを見つけられない・マウントに失敗するケースだ。

4段階目はsystemdによる各種サービスの起動だ。ルートファイルシステムはマウントできたが、その後に起動する個々のサービス(ネットワーク、ファイルシステムのマウント処理など)のどれかで失敗している状態になる。

🔗
たとえ4段階は、家を建てる工程に似ている。GRUBは設計図を選ぶ工程、カーネルは基礎工事、initramfsは仮設の足場を組んで本設の建物にたどり着く工程、systemdは完成した家の中で各部屋の電気やガスを順に点けていく工程だ。どの工程で止まったかで、直すべき場所がまるで違う。

🚑 emergency / rescueターゲットという避難所

systemdの段階まで到達したものの、特定のサービスの失敗で先に進めない――そんなときのために、systemdには緊急避難用の起動モードが用意されている。

rescueターゲットは、最低限のサービスとシングルユーザー相当の環境で起動するモードだ。emergencyターゲットはさらに絞り込まれ、ルートファイルシステムの再マウントすら行わない、より原始的な状態で起動する。

つまずきfstabの記述ミスなどでファイルシステムのマウントに失敗すると、systemdは自動的にemergencyモードへ落ちてパスワード入力を求めてくることがある。慌てず、ここから調査・修復を始められる設計になっている。

📖 journalctl -b -1 で前回の記録を読む

無事に起動できた(あるいはrescueモードに入れた)後、原因を過去にさかのぼって調べたいときに便利なのが journalctl -b -1 だ。

journalctl -b -1 ……-b(boot)はブート(起動)単位でログを絞り込むオプションで、-1 は「1つ前の起動」を意味する。今回ではなく、失敗した前回の起動時に何が起きていたかを直接確認できる。
コツ-b の後ろの数字を変えれば、-2 で2つ前、というように、さらに過去の起動ログもたどれる。「いつからおかしくなったか」を特定するのに役立つ。

🪤 fstabミスは定番の落とし穴

起動不能の原因の中でも、とりわけ「よくある」のが /etc/fstab の記述ミスだ。ディスクの追加やパーティション変更のあとにfstabを編集し、そのまま再起動して痛い目を見る、というのは経験者の多くが通る道である。

fstabに書かれたデバイスやUUIDが実際には存在しない、あるいはネットワーク越しのマウントで相手が応答しないといった状況になると、システムはそのマウントの完了を待ち続け、最悪の場合は先に進めなくなる。

blkid ……接続されている各パーティションの実際のUUIDやラベルを一覧表示する。fstabに書いたUUIDと実物が一致しているかを、編集後に必ず突き合わせておきたい。

ここで知っておきたい知恵が nofail オプションだ。fstabの該当行のオプション欄に nofail を加えておくと、そのマウントに失敗しても起動処理全体を止めずに先へ進んでくれる。絶対に必要なルートファイルシステム以外の、外付けディスクや追加パーティションには付けておくと安全性が上がる。

コツfstabを編集したら、再起動する前に mount -a を試すとよい。fstabの記述に沿って未マウントのものを一括でマウントしてくれるので、再起動せずに記述ミスを事前に検出できる。

🔧 ライブUSBからchrootで修理する道筋(概観)

それでも起動できない、あるいはrescueモードにすら入れないほど深刻な場合の最終手段が、ライブUSBからの起動とchrootによる修理だ。

🔗
たとえこれは、患部(インストール済みのシステム)を一時的に体外に置いた状態で、外部の作業台(ライブ環境)から手術する動きに近い。壊れたシステム自身を経由せずに、外から直接手を入れられる。

おおまかな流れは、ライブUSBで起動する、インストール済みシステムのルートパーティションを一時的にマウントする、chrootコマンドでそのマウント先を「本来のルート」として扱う環境に切り替える、という3ステップだ。chroot後は、あたかも壊れたシステム自身にログインしたかのようにコマンドを実行でき、設定ファイルの修正やブートローダの再インストールが行える。

ライブUSBで起動外部の作業台に立つ該当パーティションをmountchrootで切替中から修理する詳細な手順は別トピック・公式ドキュメントで確認する

この手順は環境やディストリビューションによって細部が異なり、パーティション構成を誤って扱うとデータ損失のリスクもあるため、ここでは道筋の概観にとどめる。実際に行う際は、対象ディストリビューションの公式ドキュメントを確認しながら慎重に進めたい。

起動不能は焦る場面だからこそ、GRUB→カーネル→initramfs→systemdという地図を頭に入れておくことが効く。どの段階で立ち止まっているかを見極め、rescue/emergencyやjournalctl -b -1で手がかりを集め、必要ならchrootという最終手段があると知っておく――これだけで、真っ暗な画面を前にしたときの安心感が変わる。

この項目に出てくる用語

emergency/rescueターゲットえまーじぇんしーれすきゅーたーげっと
通常起動に失敗したとき入る、最小限の機能だけで立ち上がる緊急モード。
nofailオプションのーふぇいるおぷしょん
fstabの該当行で、マウント失敗時に起動処理全体を止めないようにする指定。

▶ 学習アプリでこの続きを学ぶ・演習する