次の方法で共有

フル OS ディスクによる Azure Linux 仮想マシンの起動に関する問題のトラブルシューティング

  • [アーティクル]

適用対象: ✔️ Linux VM

特定の状況や構成では、オペレーティング システム (OS) ディスク全体が Azure Linux 仮想マシン (VM) の起動の問題につながる可能性があります。 この記事では、ブートの問題の原因と解決策について説明します。

現象

通常のシステム操作中に、OS ディスクまたは重要なシステム パーティションがいっぱいになると、次の問題が発生する可能性があります。

  • VM が予期せずシャットダウンしました。
  • VM が正常に起動しません。

前提条件

ブートの問題をトラブルシューティングし、システムの修復を完了するには、次の要件を満たす必要があります。

  • ディスク スナップショットを作成したり、一部のバックアップおよび復元ツールを操作したりするためのアクセス許可。

    この記事では、データまたはディスクが変更されるため、VM を以前の状態に戻す機能は、安全なシステム管理の重要なコンポーネントです。

  • ブート診断 有効で構成されています。

    この構成を設定すると、コンソール ログのストレージの将来の確認と、VM のシリアル コンソール インターフェイスとの対話が可能になります。

  • 任意の時点で復旧 VM が必要な場合に備えて、VM を作成するためのアクセス許可。

  • ディスクのスワップが必要な場合に備えて、ディスクの作成、デタッチ、アタッチを行うアクセス許可。

Note

すべての要件が次のシナリオに適用されるわけではありません。

シナリオ 1: VM が予期せずシャットダウンし、起動に失敗する

セキュリティ強化のプラクティスの多くは、システムの保守が困難になることがあります。 監査ログへの書き込み中にエラーが発生した場合、1 つの一般的な構成では、システムを直ちにシャットダウンする必要があります。 このシナリオがシステムシャットダウンの理由であるかどうかを確認するには、次の操作を行います。

  • コンソールログでシステムシャットダウンメッセージを確認します。

    システムが起動した場合は、"Starting Security Auditing Service...メッセージが表示されます。 このメッセージは、サービスが開始されたことを示していません。 代わりに、VM はすぐにシャットダウンに切り替わり、"電源ダウン" メッセージが表示されます。 システムが実行中で、予期せずシャットダウンした場合、シリアル コンソールに、"電源ダウン" メッセージで終わる順番なシャットダウン プロセスが表示されることがあります。 例として、次のスクリーンショットを参照してください。

    シリアル コンソールの [Starting Security Auditing Service]\(セキュリティ監査サービスの開始\) メッセージのスクリーンショット。

    シリアル コンソールの [電源オフ] メッセージのスクリーンショット。

  • az vm repair コマンド、手動回復 VM、または single ユーザー モードを使用して、OS ディスクをマウント。 次に、 df コマンド ライン ツールを使用してディスク使用率を調べ、 /var/log/audit ディレクトリを含むディスクの使用率が 100% に近いかどうかを確認します。

  • az vm repair コマンド、手動回復 VM、または single ユーザー モードを使用して OS ファイルシステムにアクセスし、/etc/audit/auditd.conf ファイルに次の構成が含まれているかどうかを確認します。

    [root@linux /]# grep action /etc/audit/auditd.conf
admin_space_left_action = HALT
disk_full_action = HALT
disk_error_action = HALT

解決策: HALT 構成を一時的に無効にする

Note

この解決策が機能しない場合、または環境に適していない場合は、「 Resolution 」セクションに進んでください。

監査対象の構成により、監査ログの障害時にシステムのシャットダウンが発生した場合、 HALT 構成を一時的に無効にすると、VM は修復のために完全な OS で起動できます。

この一般的な監査の問題とその他の一般的な問題を解決するには、Azure Linux 自動修復 (ALAR) ツールの監査アクションを使用して、Azure CLI でaz vm repair拡張機能を自動的に実行。 同じ手順を手動で実行するには、次の手順に従います。

  1. OS ディスクのスナップショットを作成して、復旧状態を提供します。

  2. az vm repair コマンド、手動の回復 VM、または single ユーザー モードを使用して、構成ファイルにアクセスできます。

  3. VM でファイルをバックアップするための領域が使用できない可能性があるため、現在の構成をメモしておきます。

  4. /etc/audit/auditd.conf ファイル内の以前の構成をHALTから、SINGLEを除く他の有効な値に変更します。 このシナリオでは、IGNORE、SUSPEND、または auditd.conf ファイルの Linux man ページに記載されているその他の値を指定できます。これにより、VM で使用されるソフトウェアのバージョンに適したパラメーターが提供されます。

    [root@linux /]# grep action /etc/audit/auditd.conf
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND

  • 復旧 VM を使用している場合は、「 元の仮想ハード ディスクをアンマウントしてデタッチする」の手順に従って OS ディスクを問題のある VM にスワップし直し、VM を正常に起動してみてください。 シングル ユーザー モードを使用している場合は、終了し、VM が再起動します。

  • VM が完全に起動したら、ファイルシステムを参照し、 df や duなどのコマンド ライン ツールを使用して領域を解放します。 /var/log/audit ディレクトリを含むファイルシステムの約 10% が適切な初期ターゲットである必要があります。

問題が解決したら、 /etc/audit/auditd.conf ファイルの内容を元の値に戻し、VM を再起動します。

シナリオ 2: Azure で VM ディスクのサイズが変更されるが、OS のサイズを変更できない、VM が完全に起動しない

完全なディスクが識別され、VM がシャットダウンされて OS ディスクのサイズが変更された後、VM が正常に起動しない可能性があります。 このシナリオは、OS が再起動時にルート (/) ファイルシステムのサイズを自動的に変更しようとする一部のディストリビューションで混乱を招く可能性があります。 ディスクがいっぱいの場合、サイズ変更操作が失敗する可能性があります。これは、ファイル システムを拡張するための空き領域がプロセスによって必要になるためです。 空き領域がない場合、cloud-init が失敗し、VM の起動が完了しない可能性があります。

この問題を特定するには、シリアル コンソールでブート ログを確認し、次のテキストのような行が存在するかどうかを確認します。

[   15.384699] cloud-init[1142]: OSError: [Errno 28] No space left on device
[   15.384742] cloud-init[1142]: Original exception was:
[   15.384784] cloud-init[1142]: OSError: [Errno 28] No space left on device

特定の cloud-init メッセージが返される最も目に見えるメッセージではない可能性があるため、"[Errno 28] No space left on device" ([Errno 28] No space left on device" (デバイスにスペースが残っていない) テキストまたは類似の "スペースなし" メッセージを含む他の行を探します。

この問題を解決するには、不要なデータ少量のディスク領域を解放してから、ファイルシステム展開します。

シナリオ 3: VM は起動しますが、サービスエラーのためにアクセスできない

完全に起動すると思われる VM では、次の問題が発生する可能性があります。

  • サービスの問題は、起動時に発生します。
  • Azure エージェントが使用できない可能性があります。
  • VM への接続が失敗する可能性があります。
  • アプリケーションによっては、VM がオフラインのように見える場合があります。

起動中、"[Errno 28] No space left on device" などの複数のメッセージが表示されたり、その他の種類のメッセージがルート ファイルシステムがいっぱいであることを示したりします。

VM が起動しても使用できない場合は、ブート診断内のシリアル ログを確認してブート メッセージを表示するか、 コンソール を使用して VM と対話します。 空き領域が不足している場合は、不要なデータ空き領域にするかディスクを拡張します。

コンソール ログに "ERROR ExtHandler /proc/net/route にルートがありません" というメッセージが多数含まれている場合は、ネットワーク サービスを完全に開始できないため、OS ディスク全体が原因である可能性もあります。

解決方法

次の解決策は、前のシナリオのいずれかに適用されます。

解決策 1: 不要なデータをクリアする

  1. システムが正常に起動しないため、 az vm repair コマンド、手動 回復 VM、または single ユーザー モードを使用して、OS ディスクとパーティションにアクセスできます。

  2. 標準の Linux ツールとコマンドを使用して、大きなファイルとディレクトリを特定します。

    • du -ks /* | sort -n - 領域が最も多いファイルまたはディレクトリを 1 つの場所に配置します。 一部の大きなデータが見つかるまで、最大の報告されたディレクトリで繰り返します。

    • ls -altSr /var/log - ディレクトリの内容をサイズ順に昇順で一覧表示します。

    • find / -size +500M -exec ls -alFh {} \; - 大きな個々のファイルを検索します。 必要に応じて 500M 値を数メガバイトまたはギガバイトに調整して、排除する最も効果的なファイルを見つけます。

  3. 古いログ、忘れたバックアップ、同様のファイルなど、不要と識別できるファイルを削除します。

  4. 適切な容量の領域がクリアされたら、約 10% の空きディスクをターゲットにして、システムを再起動します。

解決策 2: OS ファイルシステムを展開する

OS ファイルシステムからデータを消去できない場合は、重要な OS ボリュームを含むディスクを拡張することをお勧めします。 詳細については、「 Linux VM 上の仮想ハード ディスクの拡張を参照してください。

次のステップ

OS ディスク全体が原因で特定のブート エラーが Linux ブートの問題ではない場合は、「 Azure Linux 仮想マシンのブート エラーをトラブルシューティングする を参照してください。

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

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