適用対象: ✔️ Linux VM
注:
この記事で参照されている CentOS は Linux ディストリビューションであり、EOL (End Of Life) に到達します。 適宜、使用と計画を検討してください。 詳細については、「 CentOS End Of Life ガイダンスを参照してください。
Linux ファイルシステム テーブル fstab は、システム ブート プロセス中に特定のファイル システムが検出され、順番にマウントされるルールを構成するように設計された構成テーブルです。
この記事では、間違った fstab 構成によって起動の問題が発生する可能性がある複数の条件について説明し、トラブルシューティングガイダンスを提供します。
fstab の構成ミスが原因で仮想マシン (VM) の起動の問題が発生する可能性がある一般的な理由を次に示します。
- 従来のファイルシステム名は、ファイルシステムの汎用一意識別子 (UUID) の代わりに使用されます。
- 不適切な UUID が使用されています。
- fstab 構成内に
nofailオプションがない接続されていないデバイスのエントリが存在します。 - fstab 構成内のエントリが正しくありません。
fstab の問題を特定する
Azure portal の Boot diagnostics ブレード内のシリアル ログで、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 は、使用されるマウント ポイントの例です。 ファイルシステム マウント ポイントの依存関係エラーは、使用される名前によって異なります。
Resolution
この問題を解決するには、次の 2 つの方法があります。
- VM をオンラインで修復する
- VM をオフラインで修復する
VM をオンラインで修復する
シリアル コンソールの使用
- Azure portal VM のシリアル コンソール に接続します。
- fstab を再構成するには、シングル ユーザー モードへの手動アクセスが必要です。 手順は、使用される Linux OS の種類とルート アカウントへのアクセスによって異なる場合があります。 single-user モードドキュメントに従って、サポートされている各 Linux パートナー イメージのシングル ユーザー モードにアクセスします。
Fstab のトラブルシューティングの手順
VM がシングル ユーザー モードで起動した後。 任意のテキスト エディターを使用して fstab ファイルを開きます。
vi /etc/fstab/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 が起動することを確認するのに役立ちます。
変更内容を fstab ファイルに保存します。
fstab エントリを変更した後、ベスト プラクティスとして
mount -aを使用します。 これにより、fstab 構成が再実行され、既存の構文またはエントリエラーがユーザーに通知されます。構文とエントリが確認されたら、次のコマンドを使用して VM を再起動します。
reboot -fエントリのコメント化または修正が成功した場合、ポータル内に bash プロンプトが表示されます。 VM に接続できるかどうかを確認します。
注:
ctrl+xコマンドを使用して、VM を再起動することもできます。
VM をオフライン修復する
VM のシリアル コンソール アクセスが利用できない場合は、VM をオフラインで修復する方法もあります。 オフラインアプローチを使用するには、次の 2 つの方法があります。
Azure Linux 自動修復 (ALAR) を使用する
Azure Linux 自動修復 (ALAR) スクリプトは、「 Azure Linux Auto Repair (ALAR) を使用して Linux VM を修正するで説明されている VM 修復拡張機能の一部です。 ALAR では、 /etc/fstab の問題など、複数の修復シナリオの自動化について説明します。
ALAR スクリプトでは、修復拡張機能 repair-button を使用して、 --button-command fstabを指定して fstab の問題を修正します。 このパラメーターは、自動回復をトリガーします。 オフライン ALAR アプローチを使用して fstab エラーを自動化するには、次の手順を実装します。
az extension add -n vm-repair
az extension update -n vm-repair
az vm repair repair-button --button-command 'fstab' --verbose --resource-group $RGNAME --name $VMNAME
注:
それに応じて、リソース グループ名 $RGTEST と VM 名 $VMNAME 置き換えます。
- 修復 VM スクリプトは、ALAR スクリプトと組み合わせて、リソース グループ、修復 VM、および影響を受ける VM の OS ディスクのコピーを一時的に作成します。 元の
/etc/fstabファイルをバックアップし、システムの起動に必要のないデータ ファイル システム エントリを削除またはコメント アウトして変更します。 - OS が正常に起動したら、
/etc/fstabファイルを確認して編集し、適切な再起動を妨げている可能性のあるエラーを修正します。 - 最後に、
repair-buttonスクリプトによって、修復 VM を含むリソース グループが自動的に削除されます。
手動メソッドを使用する
シリアル コンソールと ALAR の両方の方法が不可能または失敗した場合は、修復を手動で実行する必要があります。 OS ディスクを復旧 VM に手動で接続し、OS ディスクを元の VM にスワップし直すには、次の手順に従います。
OS ディスクが復旧 VM に正常にアタッチされたら、詳細な chroot の手順に従って 接続された OS ディスクのファイルシステムにマウントして chroot します。 次に、 fstab のトラブルシューティング手順を実装し 問題のある OS ディスクの fstab ファイルに適切な変更を加えます。
お問い合わせはこちらから
質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。