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
仮想マシンのブートの概要
- 不明なデバイス
ブート ローダーがオペレーティング システムを読み込んでいません。 - SCSI ディスク (0,0)
ブート ローダーがオペレーティング システムを読み込んでいません。 - SCSI ディスク (0,1)
ブート ローダーがオペレーティング システムを読み込んでいません。 - ネットワーク アダプター (000D3A4DD64D)
ブート イメージが見つかりませんでした。
オペレーティング システムが読み込まれていませんでした。 仮想マシンが正しく構成されていない可能性があります。 VM を終了して構成し直すか、[再起動] をクリックして現在のブート シーケンスを再試行します。
- 不明なデバイス
エラー 2
IPv4 経由で PXE を起動する
トラブルシューティングを行う前に
Scenario 1: ブート イメージの UEFI パーティションが見つからない、ブート イメージ内の Scenario 2: UEFI パーティションが破損しているに必要なオフライン VM 修復を実行するには、Azure CLI または Azure Cloud Shell にアクセスできることを確認してください。
シナリオ 1: ブート イメージに UEFI パーティションがない
UEFI ブート ローダー パーティションが見つからないか削除されている場合、第 2 世代 Linux VM は起動に失敗します。
この問題を解決するには、次の手順に従ってください。
az vm repair create コマンドを使用して、修復 VM を作成します。 修復 VM には、非機能 VM の OS ディスクのコピーがアタッチされます。 詳細については、「 Azure 仮想マシンの修復コマンドを使用して Linux VM を修復するを参照してください。
次のコマンドを使用してパーティションを再作成します。
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 パーティションが再作成されたら、 az vm repair restore コマンドを使用して、修復された OS ディスクを VM の元の OS ディスクとスワップして VM を復元します。 詳細については、「 Azure 仮想マシン修復コマンドを使用して Linux VM を修復するの手順 5 を参照してください。
シナリオ 2: ブート イメージの UEFI パーティションが破損している
UEFI ブート パーティションが破損している場合、第 2 世代 Linux VM の起動に失敗します。 この問題を解決するには、次の手順に従ってください。
az vm repair create コマンドを使用して、修復 VM を作成します。 修復 VM には、非機能 VM の OS ディスクのコピーがアタッチされます。 詳細については、「 Azure 仮想マシンの修復コマンドを使用して Linux VM を修復するを参照してください。
次のコマンドを使用して、破損したパーティションをクリーンアップします。
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 を参照してください。
パーティションがクリーンアップされたら、 az vm repair restore コマンドを使用して、修復された OS ディスクを VM の元の OS ディスクとスワップして VM を復元します。 詳細については、「 Azure 仮想マシン修復コマンドを使用して Linux VM を修復するの手順 5 を参照してください。
シナリオ 3: /boot パーティションの内容全体が削除される
/boot パーティション全体またはその他の重要な内容が見つからないので、復旧できない場合は、バックアップから VM を復元するしかありません。 詳細については、「 Azure portal で Azure VM データを復元する方法を参照してください。
お問い合わせはこちらから
質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。