Ubuntuサーバーが緊急モードで起動した場合の対処法：ステップバイステップの復旧ガイド

Ubuntu Server がアップデート後または停電後に再起動し、「緊急モードに入ります」というプロンプトで停止します。SSH は利用できず、サービスは停止しており、コンソールにはメンテナンスを要求します。これは通常、systemd が必要な起動手順を完了できなかったことを意味し、多くの場合、ファイルシステムのチェックが失敗したか、必要なマウントが見つからなかったことが原因です。このメッセージを手がかりとして、ファイルの編集や修復コマンドの実行を行う前に、障害が発生したユニットを特定してください。

このガイドは、systemd を使用する従来の Ubuntu Server インストールに適用されます。コマンドとブート メニューは、Ubuntu Core、暗号化システム、クラウド イメージ、およびプロバイダ管理サーバーでは異なる場合があります。現在の Ubuntu の man ページでは、emergency.target は通常のサービスを開始したり、通常のファイルシステムをマウントしたりしない最小限のシェルとして説明されています。ルート ファイルシステムは、アクセス方法によっては読み取り専用または読み書き可能になります。そのため、最初のステップは検査とバックアップです。

1. 変更を加える前に、エラーメッセージを読んでください。

プロンプトが表示されたら、ローカルコンソールまたはプロバイダコンソールにログインしてください。物理マシンでは、キーボードとモニターを接続します。仮想サーバーでは、プロバイダのシリアルコンソールまたはリカバリコンソールを使用します。エラーメッセージ全体、特にユニット名（例：）systemd-fsck@dev-disk-by-uuid-....serviceやマウントユニット名（末尾が）を写真に撮るかコピーしてください.mount。UUID の欠落、ファイルシステムチェックの失敗、サービスの破損には、それぞれ異なる修正が必要です。

緊急シェルから、障害が発生したユニットと現在のブートログを検査します。

systemctl --failed
journalctl -xb

最後の「依存関係の失敗」行だけでなく、最初に意味のあるエラーを探してください。ログにマウントが特定されている場合は、そのマウントポイントとデバイスのUUIDをメモしてください。ストレージとは関係のないサービスが特定されている場合は、/etc/fstab無作為に変更を開始せず、特定のユニットとsystemctl status unit-nameその最近のログメッセージを調べてください。

2. ルートファイルシステムが編集を許可しているかどうかを確認します

設定ファイルを編集する前に、ルートファイルシステムがどのようにマウントされているかを確認してください。

findmnt /

オプションに が表示されている場合ro、ルートファイルシステムは読み取り専用です。ファイルシステムが正常で、小さな設定修復が必要な場合は、読み書き可能な状態で再マウントしてください。

mount -o remount,rw /

変更を確認するために再度実行してくださいfindmnt /。再マウントに失敗した場合は、停止してエラーを記録してください。読み取り専用のルートは、ファイルシステムのトラブルに対する保護的な対応策となる場合があります。書き込みを強制したり、マウントを繰り返し試行したりすると、復旧が困難になる可能性があります。ルートボリュームが破損していると思われる場合は、レスキュー環境を使用するか、プロバイダのサポートを受けてください。

3. ディスクを検査し、/etc/fstabと比較する

よくある原因は、古い/etc/fstabエントリです。ディスクが取り外された、UUIDが変更された、またはマウントパスが誤って入力されたなどが考えられます。まず、検出されたファイルシステムとその識別子を一覧表示します。

lsblk -f
blkid

次に、マウントテーブルの設定を読み込みます。

cat /etc/fstab

lsblk -f設定された各 UUID を、またはの出力と照合しblkid、マウントポイントとファイルシステムの種類が正しいことを確認してください。/dev/sdb1現在の文字のみに基づいて、などのデバイス名を置き換えないでください。デバイスの順序は変更される可能性があります。UUID は多くの場合より安定していますが、実際のファイルシステムと一致させる必要があります。

この/etc/fstabファイルは起動時にsystemdマウントユニットに変換されます。各フィールドとオプションにはそれぞれ固有の意味があるため、不明な項目がある場合は公式のUbuntu fstabマニュアルを参照してください。

4. オプションのマウントが欠落している場合、一時的にそれをバイパスする

失敗したエントリが、意図的に存在しない重要でないデータディスクを指している場合は、バックアップを作成し/etc/fstab、その行の先頭に を記述して、その行のみをコメントアウトして#ください。これにより、マウントされていないディスクがブートをブロックしているかどうかをテストできます。システムのストレージレイアウトを理解していない限り、ルートファイルシステム、 、または暗号化ボリュームのエントリをコメントアウトしない/bootでください。

cp -a /etc/fstab /etc/fstab.before-emergency-fix
nano /etc/fstab

あるいは、ディスクが通常動作時にオプションである場合は、nofail意図した動作を確認した上でマウントオプションを検討してください。このオプションは、真にオプションのマウントにのみ使用してください。必須のシステムボリュームに追加すると、実際のストレージ障害が隠蔽される可能性があります。ネットワークファイルシステムでは、systemd固有のオプションやネットワーク依存関係が追加で必要になる場合があります。無関係な設定からオプションをコピーしないでください。

編集後、systemdに生成されたユニットを再読み込みさせ、ファイルをテストしてください。

systemctl daemon-reload
mount -a

出力結果をすべて確認してください。エラーが解消されたからといって、すべてのアプリケーションがマウントされたデータを使用できるとは限りませんが、報告されたUUID、構文、またはマウントエラーは、修正すべき箇所を示しています。systemd -fstab-generatorのマニュアルには、 systemdがfstabエントリをマウントユニットに変換する方法が説明されています。

5. 不正なUUID、パス、またはマウントオプションを修復する

ディスクが存在するがUUIDが異なる場合は、一致するUUID=...フィールドを更新する前に正しいファイルシステムを識別していることを確認してください。マウントポイントディレクトリが存在すること、ファイルシステムタイプが正確であること、およびオプションがそのファイルシステムに対して有効であることを確認してください。一度に1つのエントリを修正してから、再度実行してsystemctl daemon-reloadくださいmount -a。

オプションのリムーバブルディスクまたはセカンダリデータディスクの場合、適切なオプションマウントポリシーを設定することで、デバイスが存在しないために起動がブロックされるのを防ぐことができます。重要なボリュームの場合は、障害を隠蔽するのではなく、デバイス、ケーブル、暗号化マッピング、または識別子を修正してください。障害が発生したユニットがLUKSまたはLVMデバイスの名前である場合は、関連するマッピングとボリュームの状態を確認してください。UUIDを同じ名前のパーティションに置き換えないでください。

6. 対象がアンマウントされている場合にのみファイルシステムチェックを実行する

コンソールにファイルシステムエラーが具体的に報告された場合は、修復する前にファイルシステムの種類とデバイスを特定してください。マウントされているファイルシステム、特にアクティブなルートファイルシステムに対して修復ユーティリティを実行しないでください。Ubuntuのfsckマニュアルにはラッパーコマンドの説明があります。適切なチェッカーと修復オプションはファイルシステムによって異なります。

ext2、ext3、またはext4データパーティションの場合、まず、マウントされていないことを確認してくださいfindmnt。マウントされている場合は、確認する前にアンマウントしてください。適切なレスキュー環境からの一般的なext4チェックは次のとおりです。

sudo e2fsck -f /dev/DEVICE

/dev/DEVICE正しいパーティションと一致した後のみ置き換えてくださいlsblk -f。チェッカーの質問とステータスをよく読んでください。データ損失のリスクを理解せずに、自動的に「すべてにはい」というオプションを追加しないでください。実行中の緊急シェルからアンマウントできないルートファイルシステムの場合は、ライブ環境またはプロバイダリカバリ環境を起動し、オフラインで確認してください。Btrfs、XFS、およびその他のファイルシステムは、異なるツールと修復手順を使用します。特に、汎用fsckコマンドをすべてのファイルシステムタイプが修復された証拠として扱わないでください。

7. シェルが利用できない場合にのみ、GRUBまたは外部リカバリを使用してください。

サーバーが緊急シェルに到達しない場合は、GRUB メニューを開き、ディストリビューションのリカバリエントリが利用可能な場合はそれを試してください。標準の Ubuntu インストールでは、レガシー BIOS システムでは Shift キーを押し続けるか、UEFI システムでは Esc キーを押すことでメニューにアクセスできることが多いですが、ホストされている仮想マシンでは別のコンソールフローを使用する場合があります。systemd による緊急ブートを 1 回だけ実行する場合は、管理者が選択した GRUB エントリを編集し、systemd.unit=emergency.targetLinux カーネルのコマンドラインに追加できます。この変更はそのブートにのみ適用されるため、次の通常のブートの前に削除してください。公式のGNU GRUB メニューのリファレンスを参照してください。

ブートボリュームをマウントできない場合は、ライブUbuntu環境またはクラウドプロバイダーのレスキューシステムを使用して、そのボリュームを検査してください。暗号化されたストレージのロックを解除し、LVMをアクティブ化するのは、それがインストールと一致する場合に限ります。リカバリからサーバーのルートファイルシステムをマウントすると、追加のリスクが発生します。ディスクとファイルシステムが特定されるまで、書き込みは避けてください。Ubuntu Coreは独自のリカバリワークフローを使用しており、デスクトップまたは従来のサーバーGRUBの手順を盲目的に実行しても修復されません。

8. 再起動して修復を確認します。

報告された原因が修正され、マウントテストに合格したら、再起動してください。

reboot

起動後、ホストが通常のマルチユーザーターゲットに到達し、想定されるファイルシステムがマウントされ、重要なサービスがアクティブになっていることを確認します。

systemctl is-system-running
systemctl --failed
findmnt --target /

で想定されるデータマウントポイントを確認しfindmnt /path/to/mount、で重要なサービスを確認してくださいsystemctl status service-name。緊急モードに戻った場合は、同じ修復を繰り返すのではなく、新しい起動の最初の失敗を再度確認してください。復旧が成功したとは、サーバーが正常に起動し、必要なストレージとサービスが利用可能になったことを意味します。ログインプロンプトが表示されるだけでは十分ではありません。

systemdの最新の動作については、Ubuntuの特殊ユニットマニュアルを参照してください。パッケージのバージョンやリカバリメニューはUbuntuのリリースやホスティングプラットフォームによって異なる場合があるため、コマンドやユニットが異なる場合は、インストールされているリリースのドキュメントを参照してください。