次の方法で共有

Azure Linux 仮想マシンでの UEFI ブート エラーのトラブルシューティング

  • [アーティクル]

適用対象: ✔️ Linux VM

Note

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

Azure Marketplace の Linux パートナー イメージは、BIOS 第 1 世代ブートと Unified Extensible Firmware Interface (UEFI) 第 2 世代ブートの両方にタグ付けされ、構成されます。

第 2 世代 Linux 仮想マシン (VM) を Azure にデプロイすると、UEFI ブート エラーが発生する可能性があります。 この記事では、UEFI ブート エラーが発生するシナリオと解決策について説明します。

現象

第 2 世代 Linux VM を Azure にデプロイすると、ブートが失敗し、サーバーにアクセスできなくなります。

UEFI ブート エラーを特定する

Azure ブート診断を使用して、VM の現在の状態を確認します。

ブート診断のスクリーンショットには、次のエラー メッセージが表示されます。

  • エラー 1

    仮想マシンのブートの概要

    1. 不明なデバイス
      ブート ローダーがオペレーティング システムを読み込んでいません。
    2. SCSI ディスク (0,0)
      ブート ローダーがオペレーティング システムを読み込んでいません。
    3. SCSI ディスク (0,1)
      ブート ローダーがオペレーティング システムを読み込んでいません。
    4. ネットワーク アダプター (000D3A4DD64D)
      ブート イメージが見つかりませんでした。

    オペレーティング システムが読み込まれていませんでした。 仮想マシンが正しく構成されていない可能性があります。 VM を終了して構成し直すか、[再起動] をクリックして現在のブート シーケンスを再試行します。

    UEFI ブート イメージが見つからない場合の Hyper-V エラー メッセージのスクリーンショット。

  • エラー 2

    IPv4 経由で PXE を起動する

    HYPER-V エラーから PXE ブートの問題への移行のスクリーンショット。

トラブルシューティングを行う前に

Scenario 1: ブート イメージの UEFI パーティションが見つからない、ブート イメージ内の Scenario 2: UEFI パーティションが破損しているに必要なオフライン VM 修復を実行するには、Azure CLI または Azure Cloud Shell にアクセスできることを確認してください。

シナリオ 1: ブート イメージに UEFI パーティションがない

UEFI ブート ローダー パーティションが見つからないか削除されている場合、第 2 世代 Linux VM は起動に失敗します。

この問題を解決するには、次の手順に従ってください。

  1. az vm repair create コマンドを使用して、修復 VM を作成します。 修復 VM には、非機能 VM の OS ディスクのコピーがアタッチされます。 詳細については、「 Azure 仮想マシンの修復コマンドを使用して Linux VM を修復するを参照してください。

  2. 次のコマンドを使用してパーティションを再作成します。

    root@repair-centos7:~# gdisk /dev/sdc
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/sdc: 134217728 sectors, 64.0 GiB
Model: Virtual Disk    
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): <Disk GUID>
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 134217694
Partitions will be aligned on 2048-sector boundaries
Total free space is 1019837 sectors (498.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1         1026048         3123199   1024.0 MiB  0700  
   2         3123200       134215679   62.5 GiB    8E00  
  14            2048           10239   4.0 MiB     EF02  

Command (? for help): n
Partition number (3-128, default 3): 
First sector (34-134217694, default = 10240) or {+-}size{KMGTP}: 10240
Last sector (10240-1026047, default = 1026047) or {+-}size{KMGTP}: 1026047
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): ef00
Changed type of partition to 'EFI System'

Command (? for help): p
Disk /dev/sdc: 134217728 sectors, 64.0 GiB
Model: Virtual Disk    
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): <Disk GUID>
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 134217694
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1         1026048         3123199   1024.0 MiB  0700  
   2         3123200       134215679   62.5 GiB    8E00  
   3           10240         1026047   496.0 MiB   EF00  EFI System
  14            2048           10239   4.0 MiB     EF02  

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT) to /dev/sdc.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.

    重要

    • /dev/sdcをオペレーティング システム (OS) ディスク デバイスの対応するコピーに置き換えます。
    • パーティション番号の選択は、セクターの始点と終点が正しい限り関係ありません。 OS が不足しているセクターを特定できるため、正しいセクターの開始点とエンドポイントが選択されます。
    • 終了セクターがディスク内の他のパーティションによって占有されていないことを確認します。 ここでは既定値を選択すれば十分です。

    Azure Linux パートナー イメージには、次のパーティション番号、セクターの開始点、およびセクターエンドポイントがあります。

    Linux OS ディストリビューション EFI パーティション番号 セクターの開始 セクターの終了
    CentOS 7 15 10240 1024000
    CentOS 8 15 10240 1024000
    Debian 10 15 8192 262143
    Debian 11 15 8192 262143
    RHEL 7 1 2048 1026047
    RHEL 8 15 10240 1024000
    Oracle Linux 7 15 10240 1024000
    Oracle Linux 8 15 10240 1024000
    Ubuntu 18.04 15 10240 227327
    Ubuntu 20.04 15 10240 227327
    SLES 12 2 6144 1054719
    SLES 15 2 6144 1054719

  3. パーティションが再作成されたら、 az vm repair restore コマンドを使用して、修復された OS ディスクを VM の元の OS ディスクとスワップして VM を復元します。 詳細については、「 Azure 仮想マシン修復コマンドを使用して Linux VM を修復するの手順 5 を参照してください。

シナリオ 2: ブート イメージの UEFI パーティションが破損している

UEFI ブート パーティションが破損している場合、第 2 世代 Linux VM の起動に失敗します。 この問題を解決するには、次の手順に従ってください。

  1. az vm repair create コマンドを使用して、修復 VM を作成します。 修復 VM には、非機能 VM の OS ディスクのコピーがアタッチされます。 詳細については、「 Azure 仮想マシンの修復コマンドを使用して Linux VM を修復するを参照してください。

  2. 次のコマンドを使用して、破損したパーティションをクリーンアップします。

    root@repair-centos7:~# gdisk -l /dev/sdc
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdc: 134217728 sectors, 64.0 GiB
Model: Virtual Disk    
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): <Disk GUID>
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 134217694
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1         1026048         3123199   1024.0 MiB  0700  
   2         3123200       134215679   62.5 GiB    8E00  
   3           10240         1026047   496.0 MiB   EF00  EFI System
  14            2048           10239   4.0 MiB     EF02 

root@repair-centos7:~# fsck.vfat -n /dev/sdc3
fsck.fat 4.1 (2017-01-24)
0x25: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
 Automatically removing dirty bit.
Leaving filesystem unchanged.
/dev/sdc3: 19 files, 1438/63326 clusters

root@repair-centos7:~# fsck.vfat /dev/sdc3
fsck.fat 4.1 (2017-01-24)
0x25: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
? 1
Perform changes ? (y/n) y
/dev/sdc3: 19 files, 1438/63326 clusters
root@repair-centos7:~# fsck.vfat /dev/sdc3
fsck.fat 4.1 (2017-01-24)
/dev/sdc3: 19 files, 1438/63326 clusters

    重要

    • /dev/sdcを OS ディスク デバイスの対応するコピーに置き換えます。
    • 上記のファイル システム チェックを実行する前に、必ず OS ディスクのバックアップを作成し、 -n オプションを使用してドライ ランを実行してください。
    • dosfsck コマンドを使用して、vfat ファイル システムのチェックを実行できます。 どちらのコマンドも同じです。 詳細については、 fsck.vfat を参照してください。

  3. パーティションがクリーンアップされたら、 az vm repair restore コマンドを使用して、修復された OS ディスクを VM の元の OS ディスクとスワップして VM を復元します。 詳細については、「 Azure 仮想マシン修復コマンドを使用して Linux VM を修復するの手順 5 を参照してください。

シナリオ 3: /boot パーティションの内容全体が削除される

/boot パーティション全体またはその他の重要な内容が見つからないので、復旧できない場合は、バックアップから VM を復元するしかありません。 詳細については、「 Azure portal で Azure VM データを復元する方法を参照してください。

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

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