fstab エラーによる Linux VM の起動に関する問題のトラブルシューティング

  • [アーティクル]

適用対象: ✔️ Linux VM

Note

この記事で参照されている CentOS は Linux ディストリビューションであり、EOL (End Of Life) に到達します。 適宜、使用と計画を検討してください。 詳細については、「 CentOS End Of Life ガイダンスを参照してください。

Linux ファイルシステム テーブル fstab は、システムのブート プロセス中に特定のファイル システムが検出され、順番にマウントされるルールを構成するように設計された構成テーブルです。 この記事では、間違った fstab 構成によって起動の問題が発生する可能性がある複数の条件について説明し、トラブルシューティングのガイダンスを提供します。

fstab の構成ミスが原因で仮想マシンの起動の問題が発生する可能性がある一般的な理由を次に示します。

  • 従来のファイルシステム名は、ファイルシステムの汎用一意識別子 (UUID) の代わりに使用されます。
  • 不適切な UUID が使用されています。
  • fstab 構成内に nofail オプションがない接続されていないデバイスのエントリが存在します。
  • fstab 構成内のエントリが正しくありません。

fstab の問題を特定する

Azure portal の [ブート診断] (/azure/virtual-machines/boot-diagnostics#boot-diagnostics-view) ブレード内のシリアル ログで、VM の現在のブート状態を確認します。 VM は緊急モードになります。 次の例のようなログ エントリが表示され、緊急モードの状態が表示されます。

[K[[1;31m TIME [0m] Timed out waiting for device dev-incorrect.device.
[[1;33mDEPEND[0m] Dependency failed for /data.
[[1;33mDEPEND[0m] Dependency failed for Local File Systems.
…
Welcome to emergency mode! After logging in, type "journalctl -xb" to viewsystem logs, "systemctl reboot" to reboot, "systemctl default" to try again to boot into default mode.
Give root password for maintenance
(or type Control-D to continue)

Note

"/data" は、使用されるマウント ポイントの例です。 ファイルシステム マウント ポイントの依存関係エラーは、使用される名前によって異なります。

解決方法

この問題を解決するには、次の 2 つの方法があります。

VM Online を修復する

シリアル コンソールの使用

  1. Azure portal VM のシリアル コンソール に接続します。
  2. fstab を再構成するには、シングル ユーザー モードへの手動アクセスが必要です。 手順は、使用中の Linux OS の種類とルート アカウントへのアクセスによって異なる場合があります。 single ユーザー モードドキュメントに従って、サポートされている各 Linux パートナー イメージのシングル ユーザー モードにアクセスします。
Fstab のトラブルシューティングの手順

  1. VM が起動されてシングル ユーザー モードになります。 任意のテキスト エディターを使用して fstab ファイルを開きます。

    vi /etc/fstab

  2. /etc/fstabで一覧表示されているファイル システムを確認します。 fstab ファイルの各行は、VM の起動時にマウントされるファイルシステムを示します。 fstab ファイルの構文の詳細については、 man fstab コマンドを実行します。 ブートエラーのトラブルシューティングを行うには、マウントに失敗したファイルシステムのエントリを確認します。 各行を確認して、構造とコンテンツの両方で正しいことを確認することをお勧めします。 fstab ファイルを正しく管理する際に考慮すべき点を次に示します。

    • 各行のフィールドは、タブまたはスペースによって区切られます。 空白行は無視されます。 先頭文字がシャープ記号 (#) になっている行はコメントです。 コメント行は fstab ファイル内に残しておくことができますが、処理されません。 行を削除する代わりに、不明な fstab 行をコメント化することをお勧めします。

    • ファイル システム パーティションの UUID を使用して、Azure VM にデータ ディスクをマウントします。ファイル システムの UUID を確認するには、 blkid コマンドを実行します。 構文の詳細については、 man blkid コマンドを実行します。 fstab ファイル内の UUID エントリの例:

      UUID=<UUID number here>  /data      xfs    defaults,nofail 0  0

    • ファイルシステム エントリ (データ ディスク) の nofail オプションを使用して、対応するエントリのパーティションでエラーが発生した後でも起動を続行できるようにします。 nofail オプションは、ファイル システムが破損している場合や起動時に VM が存在しない場合でも、VM が起動することを確認するのに役立ちます。

  3. 変更内容を fstab ファイルに保存します。

  4. fstab エントリを変更した後、ベスト プラクティスとして mount -a を使用します。 これにより、fstab 構成が再実行され、既存の構文またはエントリエラーがユーザーに通知されます。

  5. 構文とエントリが確認されたら、次のコマンドを使用して VM を再起動します。

    reboot -f

  6. エントリのコメント化または修正が成功した場合、ポータル内に bash プロンプトが表示されます。 VM に接続できるかどうかを確認します。

Note

また、"Ctrl + x" コマンドを使用して VM を再起動することもできます。

VM をオフライン修復する

VM のシリアル コンソール アクセスが利用できない場合は、VM をオフラインで修復する方法もあります。 オフラインアプローチを使用するには、次の 2 つの方法があります。

Azure Linux 自動修復 (ALAR) を使用する

Azure Linux 自動修復 (ALAR) スクリプトは、Azure 仮想マシンの修復コマンドを使用して Linux VM を修復するで説明されている VM 修復拡張機能の一部です。 ALAR では、 /etc/fstab の問題を含む複数の修復シナリオの自動化について説明します。

ALAR スクリプトでは、修復拡張機能 run コマンドとその --run-id オプションが使用されます。 自動復旧のスクリプト ID は、 linux-alar2 です。 オフライン ALAR アプローチを使用して fstab エラーを自動化するには、次の手順を実装します。

az vm repair create --verbose -g centos7 -n cent7 --repair-username rescue --repair-password 'password!234' --copy-disk-name  repairdiskcopy

az vm repair run --verbose -g centos7 -n cent7 --run-id linux-alar2 --parameters fstab --run-on-repair

az vm repair restore --verbose -g centos7 -n cent7

Note

リソース グループ名 "centos7、VM 名 "cent7"、および --copy-disk-name "repairdiskcopy" が例であり、それに応じて値を変更する必要があります。

fstab 修復スクリプトは、元のファイルのバックアップを取得し、システムを起動するために必要のない /etc/fstab ファイル内のすべての行を取り除きます。 OS の正常な起動後、fstab をもう一度編集し、以前にシステムの再起動を許可しなかったエラーを修正します。

または、修復 VM が作成されたら、修復 VM に手動でログインし、OS ディスクのアタッチされたコピーをマウントし、その fstab ファイルに変更を加えることで、変更を実装することもできます。 次の手順に従います。

  • az vm repair create コマンドを使用して修復 VM を作成します。
  • 復旧 VM で接続されている OS ディスクのファイルシステムにマウントして chroot にするには、詳細な chroot の手順に従います。
  • 次に、上記と同じ fstab のトラブルシューティング手順 従います。
  • 変更が適用されたら、 az vm repair restore コマンドを使用して、元の VM との OS ディスクの自動スワップを実行できます。

手動メソッドを使用する

シリアル コンソールと ALAR アプローチの両方が不可能または失敗した場合は、修復を手動で実行する必要があります。 OS ディスクを復旧 VM に手動で接続し、OS ディスクを元の VM にスワップし直すには、次の手順に従います。

OS ディスクが復旧 VM に正常にアタッチされたら、詳細な chroot の手順に従って 接続された OS ディスクのファイルシステムにマウントして chroot します。 次に、 fstab のトラブルシューティング手順を実装し 問題のある OS ディスクの fstab ファイルに適切な変更を加えます。

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。