この投稿では、ブート プロセスを停止させるファイル システム構成または破損の問題を手動で修復することに焦点を当てています。
ファイル システムの問題の診断と修正
/etc/fstab のエラー また、ファイル システムが破損していると、システムの起動が停止する可能性があります。ほとんどの場合、systemd は root パスワードを必要とする緊急修復シェルにドロップします。次の表に、いくつかの一般的なエラーとその結果を示します。
一般的なファイル システムの問題
| 問題 | 結果 |
|---|---|
| 破損したファイル システム | systemd はファイル システムの修復を試みます。問題が深刻すぎて自動修正できない場合、システムはユーザーを緊急シェルにドロップします。 |
| 存在しないデバイスまたは UUID が /etc/fstab で参照されています | systemd は、デバイスが使用可能になるまで、一定時間待機します。デバイスが使用可能にならない場合、システムはタイムアウト後にユーザーを緊急シェルにドロップします。 |
| /etc/fstab に存在しないマウント ポイント | システムはユーザーを緊急シェルにドロップします。 |
| /etc/fstab で指定されたマウント オプションが正しくありません | システムはユーザーを緊急シェルにドロップします。 |
すべての場合において、管理者は緊急ターゲットを使用して問題を診断および修正することもできます。これは、緊急シェルが表示される前にファイル システムがマウントされていないためです。
CentOS/RHEL 7 および 8 で Systemd を使用してレスキュー モードまたは緊急モードで起動する方法
CentOS / RHEL 7 :GRUB2 から緊急モードまたはマルチユーザー モードで起動する方法
CentOS / RHEL 7 :方法レスキュー モードまたは緊急モードで起動する注 :緊急シェルを使用してファイル システムの問題に対処する場合は、/etc/fstab の編集後に systemctl daemon-reload を実行することを忘れないでください。このリロードがないと、systemd は古いバージョンを使い続ける可能性があります。
ノーフェイル /etc/fstab ファイルのエントリにオプションを指定すると、そのファイル システムのマウントに失敗した場合でも、システムを起動できます。通常、このオプションは使用しないでください。 nofail を使用すると、ストレージが不足している状態でアプリケーションが開始され、深刻な結果を招く可能性があります。