Linux 仮想マシンが GRUB のレスキューに起動する

[アーティクル]
04/23/2024

注:

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

この記事では、GRUB の救助の問題を引き起こす複数の条件について説明し、トラブルシューティングのガイダンスを提供します。

ブートプロセス中に、ブートローダーは Linux カーネルを見つけ、ブートコントロールを引き渡そうとします。このハンドオフを実行できない場合、仮想マシン (VM) は GRUB レスキューコンソールに入ります。 GRUB のレスキューコンソールプロンプトは Azure シリアルコンソールログには表示されませんが、Azure ブート診断スクリーンショットに表示できます。

GRUB の救助に関する問題を特定する

Azure portalの [VM ブート診断] ページでブート診断スクリーンショットを表示します。このスクリーンショットは、GRUB のレスキューの問題を診断し、ブートエラーによって問題が発生したかどうかを判断するのに役立ちます。

次のテキストは、GRUB のレスキューの問題の例です。

error: file '/boot/grub2/i386-pc/normal.mod' not found.  
Entering rescue mode...  
grub rescue>

GRUB のレスキューの問題をオフラインでトラブルシューティングする

GRUB のレスキューの問題をトラブルシューティングするには、レスキュー/修復 VM が必要です。 vm 修復コマンドを使用して、影響を受ける VM の OS ディスクのコピーがアタッチされている修復 VM を作成します。 chroot を使用して、修復 VM に OS ファイルシステムのコピーをマウントします。

注:

または、Azure portalを使用して手動でレスキュー VM を作成することもできます。詳細については、「Azure portalを使用して OS ディスクを復旧 VM に接続して Linux VM のトラブルシューティングを行う」を参照してください。
GRUB の救助に関する問題を特定します。次のいずれかの GRUB レスキューの問題が発生した場合は、対応するセクションに移動して解決します。
GRUB のレスキューの問題が解決されたら、次の操作を実行します。
1. レスキュー/修復 VM からファイルシステムのコピーをマウント解除します。
2. コマンドを az vm repair restore 実行して、修復された OS ディスクを VM の元の OS ディスクと交換します。詳細については、「 Azure Virtual Machine 修復コマンドを使用して Linux VM を修復する」の手順 5 を参照してください。
3. AZURE シリアルコンソールを確認するか、VM に接続して VM を起動できるかを確認します。
/boot パーティション全体またはその他の重要な内容が存在せず、復旧できない場合は、バックアップから VM を復元することをお勧めします。詳細については、「Azure portalで Azure VM データを復元する方法」を参照してください。

詳細なエラー、考えられる原因、および解決策については、次のセクションを参照してください。

注:

以降のセクションで説明するコマンドで、を対応するオペレーティングシステム (OS) ディスクデバイスに置き換えます /dev/sdX 。

エラー: 不明なファイルシステム

次のスクリーンショットは、エラーメッセージを示しています。

grub 不明なファイルシステムエラーのスクリーンショット。

このエラーは、次のいずれかの問題に関連付けられている可能性があります。

/boot ファイルシステムの破損。

この問題を解決するには、「 /boot ファイルシステムの破損を修正する」の手順に従います。
GRUB ブートローダーが無効なディスクまたはパーティションを指しています。

この問題を解決するには、 GRUB を再インストールし、GRUB 構成ファイルを再生成します。
ヒューマンエラーが原因で発生した OS ディスクパーティションテーブルの問題。

このような問題を解決するには、「エラー: そのようなパーティションがありません」の手順に従って、/boot パーティションが見つからない場合や正しく作成されていない場合は、/boot パーティションを再作成することをお勧めします。

/boot ファイルシステムの破損を修正する

レスキュー/修復 VM が作成されたかどうかを確認します。作成されていない場合は、「 GRUB レスキューの問題をオフラインでトラブルシューティングする」の手順 1 に従って VM を作成します。
対応する /boot パーティションの破損の問題を解決するには、「 Azure Linux のファイルシステム破損エラーのトラブルシューティング」を参照してください。
「GRUB レスキューの問題をオフラインでトラブルシューティングする」の手順 3 に進み、OS ディスクを交換します。

GRUB を再インストールし、GRUB 構成ファイルを再生成する

レスキュー/修復 VM が作成されたかどうかを確認します。作成されていない場合は、「 GRUB レスキューの問題をオフラインでトラブルシューティングする」の手順 1 に従って VM を作成します。必要なすべてのファイルシステム (/および /boot を含む) をレスキュー/修復 VM にマウントし、 chroot 環境に入ります。
GRUB を再インストールし、次のいずれかのコマンドを使用して、対応する GRUB 構成ファイルを再生成します。
- RHEL/CentOS/Oracle 7.x/8.x Linux VM (UEFI なし ) (BIOS ベース - Gen1)
```
grub2-install /dev/sdX
grub2-mkconfig -o /boot/grub2/grub.cfg
sed -i 's/hd2/hd0/g' /boot/grub2/grub.cfg
```
- RHEL/CentOS/Oracle 7.x/8.x Linux VM と UEFI (Gen2)
```
grub2-install /dev/sdX
grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
sed -i 's/hd2/hd0/g' /boot/efi/EFI/redhat/grub.cfg
```
  VM が CentOS を実行している場合は、grub.cfg ファイルの絶対パス /boot/efi/EFI/centos/grub.cfg でをに置き換えますredhatcentos。
- SLES 12/15 Gen1 と Gen2
```
grub2-install /dev/sdX
grub2-mkconfig -o /boot/grub2/grub.cfg
sed -i 's/hd2/hd0/g' /boot/grub2/grub.cfg
```
- Ubuntu 18.04/20.04
```
grub-install /dev/sdX
update-grub
```
「GRUB レスキューの問題をオフラインでトラブルシューティングする」の手順 3 に進み、OS ディスクを交換します。

エラー 15: ファイルが見つかりません

次のスクリーンショットは、エラーメッセージを示しています。

grub エラー 15 ファイルが見つからないのスクリーンショット。

この問題を解決するには、次の手順を実行します。

レスキュー/修復 VM が作成されたかどうかを確認します。作成されていない場合は、「 GRUB レスキューの問題をオフラインでトラブルシューティングする」の手順 1 に従って VM を作成します。必要なすべてのファイルシステム (/および /boot を含む) をレスキュー/修復 VM にマウントし、 chroot 環境に入ります。
/boot ファイルシステムの内容を調べて、不足している内容を確認します。
GRUB 構成ファイルが見つからない場合は、 GRUB を再インストールし、GRUB 構成ファイルを再生成します。
/boot ファイルシステムのファイルアクセス許可が OK であることを確認します。同じ Linux バージョンを実行している別の VM を使用して、アクセス許可を比較できます。
/boot パーティション全体またはその他の重要な内容が存在せず、復旧できない場合は、バックアップから VM を復元することをお勧めします。詳細については、「Azure portalで Azure VM データを復元する方法」を参照してください。
問題が解決されたら、「 GRUB の問題をオフラインで解決する」の手順 3 に進み、OS ディスクを交換します。

エラー: ファイル '/boot/grub2/i386-pc/normal.mod' が見つかりません

次のスクリーンショットは、エラーメッセージを示しています。

grub エラー normal.mod が見つからないスクリーンショット。

レスキュー/修復 VM が作成されたかどうかを確認します。作成されていない場合は、「 GRUB レスキューの問題をオフラインでトラブルシューティングする」の手順 1 に従って作成します。必要なすべてのファイルシステム (/および /boot を含む) をレスキュー/修復 VM にマウントし、 chroot 環境に入ります。
破損エラーが原因で /boot ファイルシステムをマウントできない場合は、 /boot ファイルシステムの破損を修正します。
chroot 内にある場合は、 /boot/grub2/i386-pc ディレクトリ内の内容を確認します。内容が見つからない場合は、 /usr/lib/grub/i386-pc から内容をコピーします。これを行うには、次のコマンドを使用します。
```
ls -l /boot/grub2/i386-pc
cp -rp /usr/lib/grub/i386-pc /boot/grub2
```
パーティションの内容が /boot 空の場合は、次のコマンドを使用して再作成します。

注:

次の手順は、UEFI (BIOS ベース - Gen1) のない RHEL/CentOS/Oracle 7.x/8.x Linux VM に適用されます。
1. chroot プロセスで、grub を再インストールします。それに応じて、修復/レスキュー VM に接続されている OS ディスクの対応するコピーに置き換えます /dev/sd[X] 。
```
grub2-install /dev/sd[X]
```
2. リポジトリの名前を解決するために有効な DNS エントリがあることを確認 /etc/resolv.conf します。
```
cat /etc/resolv.conf
```
3. カーネルを再インストールします。
```
yum reinstall $(rpm -qa | grep -i kernel)
```
4. grub.cfg ファイルをCreateします。
```
grub2-mkconfig -o /boot/grub2/grub.cfg
sed -i 's/hd2/hd0/g' /boot/grub2/grub.cfg
```
「GRUB レスキューの問題をオフラインでトラブルシューティングする」の手順 3 に進み、OS ディスクを交換します。

エラー: このようなパーティションがありません

次のスクリーンショットは、エラーメッセージを示しています。

このようなパーティションがない grub エラーのスクリーンショット。

このエラーは、次のいずれかのシナリオで RHEL ベースの VM (Red Hat、Oracle Linux、CentOS) で発生します。

/boot パーティションは誤って削除されます。
/boot パーティションは、間違った開始と終了のセクターを使用して再作成されます。

解決策: /boot パーティションを再作成する

/boot パーティションが見つからない場合は、次の手順に従って再作成します。

レスキュー/修復 VM が作成されたかどうかを確認します。作成されていない場合は、「 GRUB レスキューの問題をオフラインでトラブルシューティングする」の手順 1 に従って VM を作成します。
次のコマンドを使用して、パーティションテーブルが dos 型または GPT 型として作成されているかどうかを確認します。
```
sudo fdisk -l /dev/sdX
```
- Dos パーティションテーブル
- GPT パーティションテーブル
パーティションテーブルの種類としてパーティションテーブルに dos がある場合は、 dos システムで /boot パーティションを再作成します。パーティションテーブルの種類としてパーティションテーブルに GPT がある場合は、 GPT システムで /boot パーティションを再作成します。
適切なディスクを使用して GRUB ブートローダーがインストールされていることを確認します。「GRUB の再インストールと GRUB 構成ファイルの再生成」の手順に従って、GRUB 構成ファイルをインストールおよび構成できます。
「GRUB レスキューの問題をオフラインでトラブルシューティングする」の手順 3 に進み、OS ディスクを交換します。

dos システムで /boot パーティションを再作成する

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

sudo fdisk /dev/sdX

最初と最後のセクターの既定値とパーティションの種類 (83) を使用します。次の出力に示すように、ツールの fdisk オプションをa使用して、/boot パーティションテーブルが起動可能としてマークされていることを確認します。

sudo fdisk /dev/sdc

The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.
Welcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): n
Partition type:
   p   primary (1 primary, 0 extended, 3 free)
   e   extended
Select (default p): p
Partition number (1,3,4, default 1): 1
First sector (2048-134217727, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-2099199, default 2099199):
Using default value 2099199
Partition 1 of type Linux and of size 1 GiB is set

Command (m for help): t
Partition number (1,2, default 2): 1
Hex code (type L to list all codes): 83
Changed type of partition 'Linux' to 'Linux'

Command (m for help): a
Partition number (1,2, default 2): 1

Command (m for help): p

Disk /dev/sdc: 68.7 GB, 68719476736 bytes, 134217728 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: dos
Disk identifier: 0x000b7179

Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *        2048     2099199     1048576   83  Linux
/dev/sdc2         2099200   134217727    66059264   8e  Linux LVM

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

不足している /boot パーティションを再作成した後、/boot ファイルシステムが検出されたかどうかをチェックします。のエントリ /dev/sdX1 (不足している /boot パーティション) が表示されるはずです。
```
sudo blkid /dev/sdX1
```
```
sudo blkid /dev/sdc1
/dev/sdc1: UUID="<UUID>" TYPE="ext4"
```
パーティションを再作成した後に blkid /boot ファイルシステムが表示されない場合は、/boot データが存在しなくなったことを意味します。 /boot ファイルシステム (/ etc/fstab /boot エントリにあるのと同じ UUID とファイルシステム形式を使用) を再作成し、その内容をバックアップから復元する必要があります。

GPT システムで /boot パーティションを再作成する

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

sudo gdisk /dev/sdX

次の出力に示すように、最初と最後のセクターの既定値と パーティションの種類 (8300) を使用します。

sudo 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): n
Partition number (1-128, default 1): 1
First sector (34-134217694, default = 1026048) or {+-}size{KMGTP}:
Last sector (1026048-2050047, default = 2050047) or {+-}size{KMGTP}:
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300):
Changed type of partition to 'Linux filesystem'

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): 6D915856-445A-4513-97E4-C55F2E1AD6C0
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 6076 sectors (3.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1         1026048         2050047   500.0 MiB   8300  Linux filesystem
   2         2050048       134215679   63.0 GiB    8E00
  14            2048           10239   4.0 MiB     EF02
  15           10240         1024000   495.0 MiB   EF00  EFI System Partition

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.

次のコマンドを使用して、システムによって /boot ファイルシステムが検出されているかどうかを確認します。
```
sudo blkid /dev/sdX1
```
のエントリ /dev/sdX1 (不足している /boot パーティション) が表示されるはずです。
```
sudo blkid /dev/sdc1
/dev/sdc1: UUID="<UUID>" BLOCK_SIZE="4096" TYPE="xfs" PARTLABEL="Linux filesystem" PARTUUID="<PARTUUID>"
```
パーティションを再作成した後に /boot ファイルシステムが表示されない場合は、/boot データが存在しなくなったことを意味します。 /boot ファイルシステムを再作成し ( /etc/fstab /boot エントリにあるのと同じ UUID を使用して)、その内容をバックアップから復元する必要があります。

エラー: シンボル 'grub_efi_get_secure_boot' が見つかりません

次のスクリーンショットは、エラーメッセージを示しています。

grub エラー 'grub_efi_get_secure_boot' が見つからないのスクリーンショット。

Linux カーネルバージョン 4.12.14 (SLES 12 SP5 で使用) は、セキュアブートオプションをサポートしていません。そのため、VM のデプロイ中にセキュアブートが有効になっている場合 (つまり、[ セキュリティの種類 ] フィールドが [信頼された起動仮想マシン] に設定されている場合)、Gen2 VM イメージでこの SUSE カーネルバージョンを使用して開始しようとすると、仮想マシンはコンソールからセキュアブートエラーを生成します。

ソリューション

ブートエラーを解決するには、次の手順に従います。

レスキュー/修復 VM が作成されたかどうかを確認します。作成されていない場合は、「 GRUB レスキューの問題をオフラインでトラブルシューティングする」の手順 1 に従って VM を作成します。 / と /boot を含むすべての必要なファイルシステムをマウントし、 chroot 環境に入ります。
chroot 環境で次の YaST コマンドを実行します。
```
yast2 bootloader
```
[ セキュアブートサポートを有効にする] オプションから "x" をオフにし、 F10 を選択して変更を保存します。
「GRUB レスキューの問題をオフラインでトラブルシューティングする」の手順 3 に従って、OS ディスクを交換します。

その他の GRUB レスキューエラー

次のスクリーンショットは、エラーメッセージを示しています。

別の grub レスキューの問題のスクリーンショット。

この種のエラーは、次のいずれかのシナリオでトリガーされます。

GRUB 構成ファイルがありません。
間違った GRUB 構成が使用されます。
/boot パーティションまたはその内容がありません。

このエラーを解決するには、次の手順に従います。

レスキュー/修復 VM が作成されたかどうかを確認します。作成されていない場合は、「 GRUB レスキューの問題をオフラインでトラブルシューティングする」の手順 1 に従って VM を作成します。 / と /boot を含むすべての必要なファイルシステムをマウントし、 chroot 環境に入ります。
/etc/default/grub 構成ファイルが構成されていることを確認します。保証された Azure Linux イメージには、既に必要な構成があります。詳細については、次の記事を参照してください。
GRUB を再インストールし、GRUB 構成ファイルを再生成します。

注:

見つからないファイルが /boot/grub/menu.lst の場合、このエラーは古い OS バージョン (RHEL 6.x、Centos 6.x、Ubuntu 14.04) 用です。代わりに GRUB バージョン 1 がこれらのシステムで使用されるため、コマンドは異なります。 GRUB バージョン 1 については、この記事では説明しません。
/boot パーティション全体が見つからない場合は、「エラー: そのようなパーティションなし」の手順に従います。
問題が解決されたら、「 GRUB の問題をオフラインで解決する」の手順 3 に進み、OS ディスクを交換します。

次の手順

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

サードパーティの情報に関する免責事項

この資料に記載されているサードパーティ製品は、マイクロソフトと関連のない他社の製品です。明示的か黙示的かにかかわらず、これらの製品のパフォーマンスや信頼性についてマイクロソフトはいかなる責任も負わないものとします。

サードパーティのお問い合わせ窓口に関する免責事項

Microsoft では、このトピックに関する追加情報を見つけるのに役立つサードパーティの連絡先情報を提供しています。将来予告なしに変更されることがあります。 Microsoft は、第三者の連絡先情報の正確性を保証しません。

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

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

Linux 仮想マシンが GRUB のレスキューに起動する

GRUB の救助に関する問題を特定する

GRUB のレスキューの問題をオフラインでトラブルシューティングする

エラー: 不明なファイルシステム

/boot ファイル システムの破損を修正する

GRUB を再インストールし、GRUB 構成ファイルを再生成する

エラー 15: ファイルが見つかりません

エラー: ファイル '/boot/grub2/i386-pc/normal.mod' が見つかりません

エラー: このようなパーティションがありません

解決策: /boot パーティションを再作成する

dos システムで /boot パーティションを再作成する

GPT システムで /boot パーティションを再作成する

エラー: シンボル 'grub_efi_get_secure_boot' が見つかりません

ソリューション

その他の GRUB レスキュー エラー

次の手順

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

フィードバック

フィードバック

その他のリソース

/boot ファイルシステムの破損を修正する

その他の GRUB レスキューエラー