次の方法で共有

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

  • [アーティクル]

注:

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

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

前提条件

Linux VM で シリアル コンソール が有効で機能していることを確認します。

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

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

ブートの問題が発生したすべての 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 シリアル コンソールを使用して問題のトラブルシューティングを試みます。

    注:

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

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

  3. GRUB 設定を手動で変更した後、CtrlXを+選択して 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 ファイル システムのコピーをマウントします。

    注:

    または、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 Virtual Machine 修復コマンドを使用して Linux VM を修復する」の手順 5 を参照してください。
    4. Azure シリアル コンソールを見るか、VM に接続して VM を起動できるかどうかを検証します。

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

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

Hyper-V ドライバーがありません

最新のすべての Linux ディストリビューションの Linux カーネルに含まれる Hyper-V ドライバーが無効になっている場合は、それらを再度有効にして、initramfs/initrd イメージを再生成します。 詳細については、「 シナリオ 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 構成ファイルは、 パラメーター とのスワップとして論理ボリューム (LV) を読み込むよう設定されています rd.lvm.lv=VG/SwapVol。 ただし、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. VG が検出されたかどうかを rootvg 検証します。

      vgs

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

      lvs

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

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

      PV を保持しているパーティションが誤って削除、サイズ変更、または作成されます。 この問題を解決するには、「 ルート パーティションがありません」を参照してください。

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

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

  4. PV が回復不可能な場合は、 バックアップからの復元を実行します。

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

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

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

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

Initrd または initramfs の破損

initrd/initramfs イメージにはある程度の破損があるため、ルート ボリュームのマウントと OS の起動プロセスが失敗します。

この問題を解決するには、修復/レスキュー VM の chroot 内から次の手順を実行します。

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

次の手順

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

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

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