Azure Linux 仮想マシンの起動に失敗し、dracut 緊急シェルに入る

  • [アーティクル]

適用対象: ✔️ Linux VM

Note

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

この記事では、オペレーティング システム (OS) ファイル システムに RAMdisk からアクセスできないために Azure Linux 仮想マシン (VM) を起動できない問題の解決策について説明します。 VM は、dracut 緊急シェルに格納されます。

前提条件

コンソールが有効になっており、Linux VM で機能していることを確認します。

dracut ブートの問題を特定する方法

dracut ブートの問題を特定するには、Azure portal を使用して、ブート診断ウィンドウ、シリアル コンソール ウィンドウで VM のシリアル コンソール ログ出力を表示するか、 AZ CLI を使用します。

起動の問題が発生したすべての VM は、dracut または initramfs 緊急シェルに格納され、シリアル コンソール ログの最後に表示されます。

  • RHEL/CentOS/SLES/Oracle Linux:

    [  201.935612] dracut-initqueue[455]: Warning: dracut-initqueue timeout - starting timeout scripts
[  201.941153] dracut-initqueue[455]: Warning: Could not boot.
         Starting Setup Virtual Console...
[[0;32m  OK  [0m] Started Setup Virtual Console.
         Starting Dracut Emergency Shell...
Warning: /dev/mapper/rootvg-rootlv does not exist

Generating "/run/initramfs/rdsosreport.txt"


Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.


dracut:/#

  • Ubuntu:

    mdadm: No arrays found in config file or automatically
done.
Gave up waiting for root file system device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  /dev/mapper/osencrypt does not exist.  Dropping to a shell!


BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu3.4) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs)

オンライン トラブルシューティング

ヒント

VM の最近のバックアップがある場合は、 バックアップから VM を復元し ブートの問題を解決します。

シリアル コンソールは、問題を解決するための最速の方法です。 これにより、システム ディスクを復旧 VM に提示しなくても、問題を直接修正できます。 ディストリビューションに必要な前提条件を満たしていることを確認します。 詳細については、「Linux 用の仮想マシンのシリアル コンソールを参照してください。

  1. VM が dracut 緊急シェルに格納されているかどうかを確認。

  2. Azure シリアル コンソールを使用して、問題のトラブルシューティングを試みます。

    Note

    Azure シリアル コンソールを使用してすべての問題に対処できるわけではありません。

    1. シリアル コンソールから 起動 VM (ハード) をトリガーします。
    2. ESC キーを使用して GRUB メニューで VM を中断します。
    3. [ E を選択して、GRUB メニューの最初のカーネル エントリを変更します。
    4. linux16行に移動し、次のようにGRUB の構成ミスを検証して修正します。

  3. GRUB 設定を手動で変更した後、 Ctrl+X を選択して VM を起動します。

    この段階で行われる変更は、永続的でない変更です。 VM が起動できる場合は、GRUB 構成ファイルでこの問題を解決するか、繰り返し発生します。

  4. VM がオンラインに戻ったら、 /etc/default/grub 構成ファイルの構成の問題を修正し、GRUB 構成を更新します。 これを行うには、「 GRUB をインストールして GRUB 構成ファイルを再生成するを参照してください。

  5. VM を再起動して、手動による介入なしで起動できることを確認します。

オフライン トラブルシューティング

ヒント

VM の最近のバックアップがある場合は、 バックアップから VM を復元し ブートの問題を解決します。

  1. Azure シリアル コンソールが特定の VM で動作しない場合、またはサブスクリプションのオプションでない場合は、復旧/修復 VM を使用してこの問題のトラブルシューティングを行います。 vm 修復コマンドを使用して影響を受ける VM の OS ディスクのコピーがアタッチされた修復 VM を作成します。 chrootを使用して、修復 VM に OS ファイル システムのコピーをマウントします。

    Note

    または、Azure portalを使用して手動で復旧 VM を作成することもできます。 詳細については、「Azure portal で OS ディスクを復旧 VM に接続して Linux VM のトラブルシューティングを行う」を参照してください。

  2. 特定の問題を解決するには、次のセクションに移動します。

  3. dracut/initramfs 関連のブートの問題が解決されたら、次の操作を実行します。

    1. chroot を終了します。
    2. 復旧/修復 VM からファイル システムのコピーのマウントを解除します。
    3. az vm repair restore コマンドを実行して、修復された OS ディスクを VM の元の OS ディスクにスワップします。 詳細については、「 Azure 仮想マシンの修復コマンドを使用して Linux VM を修復するの手順 5 を参照してください。
    4. Azure シリアル コンソールを確認するか、VM に接続して、VM を起動できるかどうかを検証します。

VFAT が無効になっているため、ADE で暗号化された VM の起動に失敗する

詳細については、「 ADE で暗号化された VM の起動に失敗する」を参照してください。

Hyper-V ドライバーが見つからない

すべての最新の Linux ディストリビューションの Linux カーネルに含まれる Hyper-V ドライバーが無効になっている場合は、それらを再度有効にして、initramfs/initrd イメージを再生成します。 詳細については、「 Scenario 3: その他の Hyper-V ドライバーが無効になっているを参照してください。

VM が Red Hat で、オンプレミスから移行される場合は、initramfs イメージで必要な Hyper-V ドライバーを有効にします。 詳細については、「 Hyper-V 以外のハイパーバイザーを使用する場合、Hyper-V ドライバーを初期 RAM ディスクに含められなかったを参照してください。

GRUB の構成ミス

rd.break パラメーターは、dracut 緊急シェルで VM を強制的に起動します。 このパラメーターが GRUB 構成ファイルにハードコーディングされていないことを確認します。

GRUB 構成ファイルのルート デバイス パスが正しくありません

GRUB 構成ファイルのルート パス root=/dev/*** が正しいかどうかを検証します。 適切なデバイス パスが使用されていることを確認します。

この検証中に、次のことを確認します。

  • OS 暗号化を使用する Ubuntu VM で、デバイス名が /dev/mapper/osencryptされていることを確認します。
  • OS ディスク内の論理ボリューム マネージャー (LVM) を使用する VM では、ルート ボリュームが /dev/mapper/rootvg-rootlv。 ADE OS ディスクが暗号化された RHEL VM でも、同じパスが使用されます。
  • 再起動の間に変更されるため、 /dev/sdX の形式のデバイス名が使用されていないこと、および Linux では永続的でないことを確認します。 詳細については、「 Linux VM デバイス名の変更をトラブルシューティングする」を参照してください。
  • UUID が使用されている場合は、適切なルート ファイル システム UUID が使用され、構文が root=UUID=xxx-yyy-zzzされていることを確認します。

GRUB 構成ファイルのスワップ デバイス パスが正しくありません

このシナリオでは、VM がブート プロセスを完了できず、次のようなエラーで dracut 緊急シェルに入ります。

[  188.000765] dracut-initqueue[324]: Warning: /dev/VG/SwapVol does not exist
         Starting Dracut Emergency Shell...
Warning: /dev/VG/SwapVol does not exist

この例の GRUB 構成ファイルは、パラメーター rd.lvm.lv=VG/SwapVolとのスワップとして論理ボリューム (LV) を読み込むよう設定されています。 ただし、VM はブート プロセス中にこの LV を見つけることができません。

Azure Linux VM でこの方法でスワップ デバイスを使用することは推奨されないことに注意してください。 詳細については、「 Azure Linux VM の SWAP ファイルを作成するを参照してください。

この問題を解決するには、GRUB 構成ファイル (/etc/default/grub) でrd.lvm.lv=VG/SwapVolスワップ パスを見つけて削除します。 これを行うには、次のいずれかの方法を使用します。

GRUB 構成ファイル内の重複したパラメーター

GRUB 構成ファイルに重複するパラメーターがあるかどうかを検証します。

ルート ファイル システムの破損

ルート ファイル システムが破損している場合は、initrd/initramfs イメージからマウントできません。

ルート ファイル システムの破損を修正するには、「 ファイルシステム エラーによる Linux 仮想マシンのブートの問題を解決する - ファイルシステムの修復を実行する」の手順に従います。

LVM のアクティブ化に関する問題

LVM 物理ボリューム (PV)、ボリューム グループ (VG)、論理ボリューム (LV) にアクセスすると、いくつかの問題が発生する可能性があります。 Azure シリアル コンソールからは対処できません。 それらを解決するには、修復/復旧 VM を使用します。

  1. オフラインのトラブルシューティングの手順 1 に従います。

  2. 問題を特定するには、次のコマンドを実行し、コマンドの出力を確認します。

    1. OS ディスクに対応するデバイスを特定し、PV として検出されたかどうかを確認します。

      lsblk
pvs

    2. rootvg VG が検出されたかどうかを検証します。

      vgs

    3. LV が検出されたかどうかを検証します。

      lvs

  3. ルート ボリュームへのアクセスに関する問題を引き起こす、次の一般的な LVM エラーのトラブルシューティングを行います。

    • rootvg VG に 1 つの PV しかない場合の不明な PV (これが標準の Azure 構成)

      PV を保持しているパーティションが誤って削除、サイズ変更、または作成されました。 この問題を解決するには、 Root パーティションが見つからないを参照してください。

    • rootvg VG が変更され、複数のディスクに分割された場合の不明な PV

      rootvg VG に 2 台の PV を配置することは、推奨される構成ではありません。 このシナリオでは、データ ディスクが仮想マシンからデタッチされ、rootvg 論理ボリュームにアクセスできなくなります。 この問題を解決するには、元のディスクを VM に再アタッチして再起動します。

  4. PV が回復できない場合は、バックアップから リストアを実行。

ルート パーティションがありません

パーティションのサイズ変更操作中にパーティション レベルで発生するいくつかの問題が原因で、ルート ファイル システムにアクセスできない場合があります。

このシナリオでは、元のパーティション テーブル レイアウトを文書化し、元の各パーティションの開始セクターと終了セクターを正確に記述した場合 (新しいファイル システムの作成など、システム上でそれ以上変更は行われません)、同じ元のレイアウトを使用してパーティションを再作成します。 これを行うには、 fdisk (MBR パーティション テーブルの場合) や gdisk (GPT パーティション テーブルの場合) などのツールを使用して、アクセスできないファイル システムにアクセスできます。 修復/復旧 VM からこの回復操作に従います。 詳細については、「 オフラインのトラブルシューティング 」セクションを参照してください。

この方法が機能しない場合は、バックアップから restore を実行することをお勧めします。

Initrd または initramfs の破損

initrd/initramfs イメージには、ルート ボリュームのマウントと OS スタートアップ プロセスの開始が失敗する原因となる、ある程度の破損があります。

この問題を解決するには、修復/復旧 VM の chroot 内から次の手順に従います。

  1. オフラインのトラブルシューティングの手順 1 に従います。
  2. 不足している initramfs を手動で再生成します。
  3. VM を再起動して、起動できるかどうかを確認します。

次のステップ

特定のブート エラーが dracut または initramfs の問題でない場合は、「 Azure Linux Virtual Machines のブート エラーをトラブルシューティングする を参照してください。

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

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