Linuxが起動しなくなる瞬間は突然やってきます。カーネルアップデートの直後、/etc/fstab の誤記、ストレージ障害、あるいは原因不明の停電——いずれも復旧を急ぐ状況で、画面に表示されるメッセージだけを頼りに対処しなければなりません。
この記事では、Linux起動障害のうち特に遭遇頻度の高い「grub rescue> プロンプト」「emergency mode / rescue target」「fstab誤設定」の3パターンに絞り、原因の切り分けから実際の復旧コマンドまでを体系的に解説します。Linuxの起動シーケンスの理論(BIOS から systemd まで)は別記事で解説しており、本記事はトラブル発生時の実践的な操作手順に特化しています。
動作確認環境:RHEL 9.4 / Rocky Linux 9 / Ubuntu 24.04 LTS
この記事のポイント
・grub rescue> が出たら ls でパーティション確認 → insmod normal で起動できる
・emergency modeはjournalctl -xbでエラーを特定してから対処する
・fstab誤設定はblkidでUUID確認 → findmnt --verifyで書式検証が基本
・再発防止にはnofailオプションとGRUB設定ファイルのバックアップが有効
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
Linuxが起動しない:まず状況を見極める
Linuxの起動障害に対処する際、最も重要なのは「画面のどのタイミングで止まっているか」を正確に把握することです。焦って電源を入れ直し続けると、ファイルシステムが汚損して被害が拡大することがあります。まず深呼吸して、表示を確認することから始めてください。起動障害の3つの代表パターン
起動しないLinuxの症状は大きく3つに分類できます。・GRUBエラー(grub rescue>):ブートローダー自体が壊れているか、/boot パーティションを見失っている状態です。OS が読み込まれる前の段階で止まります。
・emergency mode / rescue target:systemd は起動しているが、ファイルシステムのマウントやサービスの起動に失敗した状態です。ルートシェルが提供されるため、コンソールで直接作業できます。
・fsck 待ち(Press key to maintenance):強制シャットダウン後やディスク障害でファイルシステムが汚損し、手動の fsck を促される状態です。本記事では fstab 誤設定に絞って解説します。
ブート画面のメッセージでトリアージする
どのパターンかは、画面のメッセージで判断できます。# パターン1: grub rescue> プロンプト → GRUBエラー対応へ grub rescue> # パターン2: emergency mode に入る場合 Welcome to emergency mode! After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or ^D to try again to boot into default mode. Give root password for maintenance (or press Control-D to continue): # パターン3: デバイス待ちで止まる場合 → fstab誤設定の疑い [ *** ] A start job is running for dev-sdb1.device (1min 28s / 1min 30s)
作業前に確認しておくこと
復旧作業を始める前に、以下を確認してください。・コンソールへの接続:起動障害時は SSH が使えません。物理コンソール、IPMI、または iDRAC/iLO 経由でサーバー画面を確認します。クラウドであればシリアルコンソールや VNC コンソールを使います。
・LiveUSB の準備:grub rescue 状態では LiveUSB が必要になるケースがあります。Rocky Linux 9 または Ubuntu 24.04 の ISO を別の自分の PC に焼いておくと確実です。
・バックアップの確認:スナップショット・バックアップが存在するなら、復元を先に検討してください。復旧作業は最後の手段ではなく、最適な選択肢を選ぶという考え方が重要です。
GRUBエラー(grub rescue>)からの復旧手順
grub rescue> プロンプトが表示された場合、GRUB2 が /boot/grub2/grub.cfg や必要なモジュールファイルを見つけられていない状態です。GRUB 自体は動いているため、手動でパスを指定すれば一時的に起動できます。1. ls コマンドでパーティションを特定する
まず利用可能なパーティションを確認し、/boot が存在する場所を特定します。# パーティション一覧を確認 grub rescue> ls (hd0) (hd0,gpt1) (hd0,gpt2) (hd0,gpt3) # 各パーティションの内容を確認して /boot を探す grub rescue> ls (hd0,gpt1)/ ./ ../ boot/ etc/ home/ usr/ var/ ... # /boot が独立パーティションの場合の例 grub rescue> ls (hd0,gpt2)/ grub2/ vmlinuz-5.14.0-503.el9.x86_64 initramfs-5.14.0-503.el9.x86_64.img
2. insmod normal でGRUBモジュールをロードする
/boot のパーティションが特定できたら、root と prefix を設定し、normal モジュールを読み込みます。# /boot が (hd0,gpt2) にある場合の例 grub rescue> set root=(hd0,gpt2) grub rescue> set prefix=(hd0,gpt2)/grub2 grub rescue> insmod normal # ノーマルモードへ移行(GRUBメニューが表示される) grub rescue> normal
なお、grub.cfg が存在するのに読み込めない場合は、configfile で直接指定することもできます。
# grub.cfg を直接指定して読み込む方法 grub rescue> insmod normal grub rescue> configfile (hd0,gpt2)/grub2/grub.cfg
3. OS起動後にGRUBを再インストールする
上記で一時的に起動できても、GRUB の設定が壊れた状態では次回起動時に再発します。OS が起動したら速やかに正式な修復を行います。# RHEL / Rocky Linux(BIOS環境) $ sudo grub2-install /dev/sda $ sudo grub2-mkconfig -o /boot/grub2/grub.cfg # Ubuntu / Debian(BIOS環境) $ sudo grub-install /dev/sda $ sudo update-grub # UEFI環境(ESPへのインストール) $ sudo grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=grub $ sudo grub2-mkconfig -o /boot/efi/EFI/grub2/grub.cfg
ls /sys/firmware/efi でディレクトリが存在すれば UEFI です。BIOS 用コマンドを UEFI 環境に使うとブートができなくなるため、必ず事前に確認してください。emergency mode / rescue target への対処
emergency mode は、systemd が起動したもののファイルシステムのマウントやサービスの起動に失敗した際に提供される最低限の復旧環境です。ルートシェルが使えるため、原因調査と修正を直接行えます。1. journalctl -xb でエラーを特定する
emergency mode のプロンプトが表示されたら、まず root パスワードでログインし、起動ログを確認します。# 起動ログからエラーを絞り込む $ journalctl -xb | grep -E "FAILED|failed|error|Error" # 典型的なfstab関連エラーの出力例 Jul 15 09:32:01 server01 systemd[1]: Failed to mount /data. Jul 15 09:32:01 server01 systemd[1]: Dependency failed for Local File Systems. Jul 15 09:32:01 server01 systemd[1]: Job local-fs.target/start failed with result 'dependency'. # デバイスが見つからないエラーの例 Jul 15 09:32:01 server01 kernel: EXT4-fs (sdb1): no journal found Jul 15 09:32:02 server01 systemd[1]: dev-sdb1.device: Job dev-sdb1.device/start timed out.
2. rescue target と emergency target の違い
Linux の起動障害モードには段階があります。・emergency.target:ルートファイルシステムのみを読み取り専用でマウントした最低限の環境です。ネットワークも他のサービスも動きません。起動時の GRUB メニューで「e」を押してカーネルパラメータに
systemd.unit=emergency.target を追加して手動で入ることもできます。・rescue.target(シングルユーザーモード):ルートファイルシステムを読み書き可能でマウントし、基本的なサービスを起動した状態です。通常「emergency mode に入りました」と表示されるのはこちら寄りの状態のことが多いです。
3. 一時的に読み書き可能にしてから修正する
emergency mode ではルートが読み取り専用になっていることが多く、ファイルの編集ができません。リマウント後に修正します。# 現在のマウント状態を確認 $ mount | grep " / " /dev/sda2 on / type xfs (ro,relatime,attr2,inode64,...) # ro(read-only)の場合は修正前にリマウントが必要 # ルートファイルシステムを読み書き可能にリマウント $ mount -o remount,rw / # 修正完了後に再起動 $ systemctl reboot
systemctl reboot で再起動してください。emergency mode から exit や Ctrl+D を押すと通常起動を再試行しますが、原因を修正していない場合は再び emergency mode に落ちます。fstab誤設定が原因の場合の修正手順
/etc/fstab の誤設定は、起動障害の中で最も頻繁に見かける原因のひとつです。特にディスク追加・削除後や UUID のコピーミスで発生します。fstab の書式と mount コマンドの詳細については mount コマンドの使い方 も参考にしてください。1. fstab誤設定が引き起こす典型症状
fstab に存在しないデバイスや誤ったUUIDが記述されていると、systemd がデバイスを 1分30秒待ち続けた末に emergency mode へ落ちます。次のような経緯がある場合は fstab が疑われます。・直前に /etc/fstab を編集した、またはディスクを追加・削除した
・NAS や USB 外付けストレージを fstab に記述していた
・ディスクの UUID が変わった(ディスク交換・パーティション再作成など)
・別の環境の fstab をそのままコピーしてきた
2. blkidでUUIDを確認してfstabを修正する
emergency mode に入ったら、まず現在接続されているデバイスの UUID を確認します。# 接続中のデバイスとUUIDを一覧表示 $ blkid /dev/sda1: UUID="7b8c9d12-ab34-ef56-7890-abcdef123456" TYPE="xfs" PARTLABEL="boot" /dev/sda2: UUID="a1b2c3d4-e5f6-7890-abcd-ef1234567890" TYPE="xfs" PARTLABEL="root" /dev/sdb1: UUID="1234abcd-5678-ef90-1234-abcdef567890" TYPE="ext4" # 現在の fstab を確認 $ cat /etc/fstab # 問題のある行の例(存在しないデバイスを参照している) # UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /data ext4 defaults 0 2 # ルートを読み書き可能にリマウントしてから修正 $ mount -o remount,rw / $ vi /etc/fstab
3. findmnt --verifyで書式を検証してから再起動
fstab を修正したら、必ず書式チェックを行ってから再起動します。書式エラーがあると再び起動障害になります。# fstab の書式チェック(エラーがあれば [E] で表示される) $ findmnt --verify # エラーがなければ mount -a でマウントを試みる $ mount -a # マウントに成功したら再起動 $ systemctl reboot
findmnt --verify で [E] が出た場合は再度 fstab を修正してください。[W] は警告で、起動への影響はほとんどありませんが内容を確認しておくと安心です。起動後の再発防止チェックリスト
復旧後は「同じことが二度と起きないように」する対策が重要です。現場では「直した」で終わらせず、再発防止まで徹底することがプロの証しです。GRUBのバックアップとgrub2-mkconfigの徹底
grub.cfg はカーネルアップデートのたびに自動更新されますが、手動でのバックアップも有効です。# grub.cfg のバックアップ(BIOS環境 / RHEL・Rocky Linux) $ sudo cp /boot/grub2/grub.cfg /boot/grub2/grub.cfg.bak.$(date +%Y%m%d) # UEFI環境の場合 $ sudo cp /boot/efi/EFI/redhat/grub.cfg /boot/efi/EFI/redhat/grub.cfg.bak.$(date +%Y%m%d) # カーネルアップデート後は必ず再生成と確認 $ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
fstabにnofailオプションを付ける
外付けストレージや NAS など「起動時に必ずしも存在しないデバイス」を fstab に書く場合は、nofail オプションを付けることで、マウント失敗時でも起動を継続できます。# nofail を付けた fstab 記述例(マウント失敗でも起動継続) UUID=1234abcd-5678-ef90-1234-abcdef567890 /data ext4 defaults,nofail 0 0 # NFS マウントの場合は待機タイムアウトも短縮する 192.168.1.100:/share /nas nfs defaults,nofail,x-systemd.device-timeout=10s 0 0 # fstab 変更後は必ず検証してから保存する $ findmnt --verify $ mount -a
nofail を付けても、定期的に mount -a でマウントが正常かを確認する運用を徹底してください。本記事のまとめ
Linuxが起動しない時の原因と復旧コマンドをまとめます。| 症状・画面表示 | 最初に実行するコマンド |
|---|---|
| grub rescue> プロンプトが出た | grub rescue> ls (hd0,gpt1)/ → パーティション特定 → set root= → insmod normal |
| emergency mode に入った | journalctl -xb | grep -E "FAILED|failed" でエラー特定 |
| ルートが読み取り専用になっている | mount -o remount,rw / |
| fstab誤設定が疑われる | blkid → UUID確認 → vi /etc/fstab → findmnt --verify |
| GRUB を再インストールする(BIOS) | grub2-install /dev/sda → grub2-mkconfig -o /boot/grub2/grub.cfg |
| GRUB を再インストールする(UEFI) | grub2-install --target=x86_64-efi --efi-directory=/boot/efi |
現場で役立つLinux復旧スキルを体系的に学ぶには
grub rescue> や emergency mode への対処は、マニュアルを読んで頭で理解するだけでは身につきません。実際に手を動かし、失敗しながら覚えていくものです。セミナーでは3,100名以上の受講生に実機環境でこのような復旧手順を体験してもらっており、「自分で直せた」という経験が現場での自信に直結すると実感しています。現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、
Linux Master Pro Seminar では、GRUB 復旧・fstab 修正・emergency mode 対処など、本番障害対応の実践スキルを RHEL 10 実機を使った2日間ハンズオンで徹底習得できます。3,100名以上の受講実績。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒/合わなければ解除3秒 / 詳細はこちら

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます