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

注:

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

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

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

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

fstab の問題を特定する

Azure portalの [ブート 診断] (/azure/virtual-machines/boot-診断#boot-診断-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)

注:

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

解決方法

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

• VM をオンラインで修復する
  • シリアル コンソールの使用
• VM をオフラインで修復する
  • Azure Linux 自動修復 (ALAR) を使用する
  • 手動メソッドを使用する

VM Online を修復する

シリアル コンソールを使用する

1. Azure portalから VM のシリアル コンソールに接続します。
2. fstab を再構成するには、シングル ユーザー モードへの手動アクセスが必要です。 この手順は、使用中の Linux OS の種類とルート アカウントへのアクセスによって異なる場合があります。 シングル ユーザー モードのドキュメントに従って、サポートされている各 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 に接続できるかどうかを確認します。

注:

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

VM をオフライン修復する

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

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

Azure Linux Auto Repair (ALAR) スクリプトは、「 Azure Virtual Machine 修復コマンドを使用して 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

注:

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

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

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

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

手動メソッドを使用する

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

• Azure portalを使用して OS ディスクを復旧 VM に接続する
• Azure CLI を使用して OS ディスクを復旧 VM に接続する

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

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

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