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

具体例：ケーシーは、Ubuntu Server VM を運用していますが、再起動後、オプションのデータボリュームマウントが追加された直後に、緊急モードに陥ってしまいます/etc/fstab。ケーシーはコンソールにアクセスできますが、SSH セッションは利用できません。マウントの変更は手がかりではありますが、原因が確定しているわけではありません。緊急モードは複数の起動失敗後に発生する可能性があるため、ケーシーは変更を加える前に現在のマシンのログを確認します。以下のターミナルパネルは、実際の修復やテストではなく、代表的なレイアウトとプレースホルダー出力を示しています。

緊急モードとは

systemd を使用する Ubuntu Server インストールでは、emergency.targetメインコンソールで最小限のシェルが起動します。これはrescue.target、基本システムとシステムマウントを必須サービスのみで起動する よりも制限されています。緊急モードへのパスによっては、ルートファイルシステムが既に読み取り専用または読み書き可能でマウントされている可能性があります。どちらかの状態を想定するのではなく、確認してください。詳細については、上流のsystemd special-target のドキュメントを参照してください。

まず、プロンプトを判別してください。systemd の緊急シェルは通常「緊急モードへようこそ！」と表示し、メンテナンスのために root パスワードを要求する場合があります。BusyBox のプロンプト（例: ）は、(initramfs)ブートがまだインストール済みのルートファイルシステムに切り替わっていないことを意味します。grub>またはgrub rescue>プロンプトはブートローダーの問題です。これらはそれぞれ異なる復旧手順が必要です。root アカウントがロックされている場合、またはサーバーがリモートにある場合は、ホスティングプロバイダのシリアル/VNC コンソールまたはレスキュー環境を使用してください。通常、この段階では SSH は利用できません。報告された障害を理解して修正するまで、Ctrl+D を押して続行しないでください。

ステップバイステップの救出

1. コンソールへのアクセスを維持し、正確な障害発生状況を記録する。

緊急コンソールを開いたままにしてください。プロンプトの上に表示された、最後に失敗したマウントまたはサービス名、およびデバイスパスまたはUUIDをメモしてください。Caseyによる最近のfstab編集内容を確認する価値はありますが、失敗した行をすべてコメントアウトしたり、「緊急」という単語だけに基づいて修復コマンドを実行したりしないでください。システムが仮想マシンの場合は、修復中および次回の再起動中もプロバイダコンソールを開いたままにしてください。

2. 現在のブートジャーナルと失敗したユニットを読み込む

緊急シェルで、以下を実行します。

journalctl -xb -p err --no-pager
systemctl --failed --no-pager

-bジャーナルクエリを今回の起動に限定し、-p errエラー優先度以上のエラーをフィルタリングします。関連する最初のエラーを探し、単に「依存関係の失敗」メッセージの最後の連鎖を探すのではなく、最初のエラーを探します。マウントユニットが失敗した場合は、エスケープされたユニット名とターゲットパスをメモします。サービスが失敗した場合は、それがマウントの欠落の原因なのか、それとも単なる結果なのかを特定します。Ubuntuのjournalctl(1)マニュアルには、起動とユニットのフィルタリングに関するドキュメントがあります。

3. ルートマウントと空き容量を確認する

ファイルを編集したり修復を試みたりする前に、ルートファイルシステムがどのようにマウントされているか、またシステムがブロックやinodeを使い果たしていないかを確認してください。

findmnt -no SOURCE,FSTYPE,OPTIONS /
df -h /
df -i /

出力においてfindmnt、roは読み取り専用、 はrw読み書き可能を意味します。読み取り専用のルートは、復旧プロセスの一部として意図的に設定する場合もあれば、ファイルシステムの不具合を反映している場合もあります。カーネルログにI/Oエラーやファイルシステムエラーが報告されている場合は、すぐに読み書き可能として再マウントしないでください。ファイルシステムがいっぱいになったり、inodeテーブルが枯渇したりすると、無関係なサービスやマウントが失敗することもあります。マウントされたファイルシステムの検査方法については、 Ubuntufindmnt(8)マニュアルを参照してください。

4./etc/fstabデバイス識別子の検証と確認

Casey が最近変更したため/etc/fstab、構文と参照されているデバイスが存在するかどうかを確認してください。

findmnt --verify --verbose
lsblk -f
blkid

findmnt --verify --verbosefstab エントリの解析と使用上の問題をチェックします。UUID=疑わしい行のすべての項目を、lsblk -fまたはで表示される UUID と比較しますblkid。また、マウント ポイント、ファイルシステム タイプ、およびオプションもチェックします。別のディスクからコピーされた UUID、接続されていないデバイス、または無効なオプションによって、必要なマウントが完了しない場合があります。などのパーティションを推測しないでください/dev/sda1。デバイス名は起動ごとに変更される可能性があります。

5. 確認済みのマウントの問題のみを修正する

ルートファイルシステムが書き込み可能で、fstabのチェックで不正な行が検出された場合は、編集する前にバックアップを作成してください。

cp -a /etc/fstab /etc/fstab.before-rescue
nano /etc/fstab

意図したデバイスを確認してから、UUID またはその他のフィールドを修正してください。マウントが本当にオプションであり、そのボリュームが存在しない場合でもサーバーが起動する必要がある場合は、systemd 対応の fstab 行nofailと有限のデバイス待機を使用できます。例:

UUID=VERIFIED-UUID /srv/archive ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2

プレースホルダーを実際の UUID に置き換え、実際のファイルシステムタイプを使用してください。nofailマシンやアプリケーションが正しく動作するために必要なルート、ブート、その他のファイルシステムには追加しないでください。 を使用すると、マウントが失敗してもブートは続行されるため、依存するサービスには引き続き注意が必要になる場合があります。これらの fstab オプションについては、nofailUbuntu systemd mount-unit マニュアルを参照してください。

編集後、マウントを試みる前に再度検証してください。

findmnt --verify --verbose
systemctl daemon-reload
mount /srv/archive

最後のコマンドで実際のマウントポイントを使用してください。それでも失敗する場合は、新しいエラーメッセージを読み、ディスクが正しく接続されているか、正常かを確認してください。ルートファイルシステムが読み取り専用の場合は、安易に変更を加えないでください。プロバイダのリカバリ環境または起動可能なUbuntuメディアを使用して、インストール済みのシステムを安全に検査および編集してください。

6. ジャーナルが特定の箇所を指している場合にのみ、サービスの障害を調査する

緊急モードとは、起動停止の原因がすべてのサービス障害であることを意味するものではありません。関連するエラーでサービス名が挙げられている場合は、そのサービスをマスクしたり無効にしたりするのではなく、そのサービスとそのログを調べてください。

systemctl status example.service --no-pager
journalctl -u example.service -b --no-pager

正確なユニット名に置き換えてくださいexample.service。構成ファイル、実行ファイル、認証情報、または必要なマウントが欠落していないか確認してください。障害がCaseyのデータボリュームの欠落に起因する場合は、まずそのマウントを修正してからサービスを再評価してください。重要なサービスを無効にすると、症状が隠蔽される一方で、サーバーが使用不能になる可能性があります。

7. ファイルシステムのエラーをオフライン修復タスクとして扱う

カーネルジャーナルにファイルシステムの破損またはストレージI/Oエラーが報告された場合は、可能な限り書き込みを停止し、修復前にバックアップまたはプロバイダのスナップショットを保持してください。正確なデバイスとファイルシステムは、で確認してくださいlsblk -f。ルートファイルシステムの場合は、プロバイダのレスキューシステムまたはUbuntuリカバリ/ライブメディアで起動し、ターゲットパーティションがアンマウントされていることを確認し、そのファイルシステムに適したチェッカーを使用してください。ext2/3/4の場合は、そのツールはですe2fsck。XFS、Btrfs、およびその他のフォーマットでは手順が異なります。

マウントされたファイルシステム（読み取り専用のルートファイルシステムを含む）上で、このツールを実行しないでください。Ubuntu のfsckマニュアルでは、マウントされたファイルシステムのチェックは一般的に安全ではなく、結果も有効ではないと警告しています。ディスクが繰り返し I/O エラーを報告する場合は、修復を試み続けるよりも、データの復旧またはストレージプロバイダへの問い合わせを優先してください。e2fscke2fsck(8)

8. 通常起動に戻り、結果を確認する。

原因が特定され修正されたら、コンソールから再起動してください。

systemctl reboot

Ubuntuが起動したら、設定されているデフォルトのターゲット、現在のシステム状態、失敗したユニット、および新しいブートを確認します。

systemctl get-default
systemctl is-system-running
systemctl --failed --no-pager
journalctl -b -p err --no-pager
findmnt --verify --verbose

意図的に現在のブートを継続する場合は、systemctl defaultsystemd に設定済みのデフォルトターゲットを起動するように要求します。これは、ブロックエラーが修正された後にのみ使用してください。無効なマウントや破損したファイルシステムは修復されません。systemctl get-default設定済みのデフォルトターゲットを表示します。systemdsystemctl is-system-runningが現在の状態を実行中、劣化状態、またはその他の状態とみなしているかどうかを報告します。クリーンリカバリとは、想定されるファイルシステムがマウントされ、必要なサービスがアクティブになり、再起動後に同じ緊急事態が再発しないことを意味します。

プロンプトが(initramfs)代わりに

BusyBox initramfs で systemd の emergency-shell 手順を盲目的に適用しないでください。initramfs ステージは、インストール済みのシステムに制御を渡す前に、実際のルート ファイルシステムを特定してマウントしようとしています。正確なエラーを記録し、期待されるデバイスが と に表示されているかどうかを確認し/dev、/dev/disk/by-uuidブート コマンドラインのroot=値と実際のルート UUID を比較してください。ディスクまたは暗号化/LVM ボリュームが見つからない場合は、プロバイダのストレージおよびレスキュー ツールを使用して調査してください。見つからないデバイスを特定せずに initramfs を再構築したり、GRUB パラメータを変更したりすると、ブートの復旧が困難になる可能性があります。

ケーシーの仮想VMの場合、有用な結果は、原因の特定と範囲を限定した修正です。具体的には、想定されるオプションボリュームを復元するか、確認済みの識別子を修正するか、ワークロードが本当に許容する場合にのみオプションとして構成します。その後、リカバリセッションを閉じる前に、コンソールから次回の起動を検証します。