カーネルの変更を適用した後、Azure Linux 仮想マシンの起動に失敗する

[アーティクル]
07/30/2024

適用対象: ✔️ Linux VM

Note

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

この記事では、カーネルの変更を適用した後に Linux 仮想マシン (VM) を起動できない問題の解決策について説明します。

前提条件

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

カーネル関連のブートの問題を特定する方法

カーネル関連のブートの問題を特定するには、特定のカーネルパニック文字列を確認します。これを行うには、 Azure CLI または Azure portal を使用して、ブート診断ウィンドウまたはシリアルコンソールウィンドウで VM のシリアルコンソールログ出力を表示します。

カーネルパニックは次の出力のように見え、シリアルコンソールログの最後に表示されます。

Probing EDD (edd=off to disable)... ok
Memory KASLR using RDRAND RDTSC...
[  300.206297] Kernel panic - xxxxxxxx
[  300.207216] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G               ------------ T 3.xxx.x86_64 #1

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

ヒント

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

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

特定のカーネル関連のブートの問題を特定します。
Azure シリアルコンソールを使用して、GRUB メニューで VM を中断し、以前のカーネルを選択して起動します。詳細については、「以前のカーネルバージョンでのシステムの起動を参照してください。
対応するセクションに移動して、特定のカーネル関連のブートの問題を解決します。
カーネル関連のブートの問題が解決されたら、最新のカーネルバージョンで起動できるように VM を再起動します。

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

ヒント

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

Azure シリアルコンソールが特定の VM で動作しない場合、またはサブスクリプションのオプションではない場合は、復旧/修復 VM を使用してブートの問題のトラブルシューティングを行います。これを行うには、次の手順を実行します。

vm 修復コマンドを使用して影響を受ける VM の OS ディスクのコピーがアタッチされた修復 VM を作成します。 chrootを使用して、修復 VM に OS ファイルシステムのコピーをマウントします。

Note

または、Azure portalを使用して手動で復旧 VM を作成することもできます。詳細については、「Azure portal で OS ディスクを復旧 VM に接続して Linux VM のトラブルシューティングを行う」を参照してください。
特定のカーネル関連のブートの問題を特定します。
対応するセクションに移動して、特定のカーネル関連のブートの問題を解決します。
カーネル関連のブートの問題が解決されたら、次の操作を実行します。
1. chroot を終了します。
2. 復旧/修復 VM からファイルシステムのコピーのマウントを解除します。
3. az vm repair restore コマンドを実行して、修復された OS ディスクを VM の元の OS ディスクにスワップします。詳細については、「 Azure 仮想マシンの修復コマンドを使用して Linux VM を修復するの手順 5 を参照してください。
4. Azure シリアルコンソールを確認するか、VM に接続して、VM を起動できるかどうかを検証します。
カーネル関連の重要なコンテンツ、 /boot パーティション全体、またはその他の重要なコンテンツが見つからない場合、回復できない場合は、バックアップから VM を復元することをお勧めします。詳細については、「 Azure portal で Azure VM データを復元する方法を参照してください。

古いカーネルバージョンのブートシステム

Azure シリアルコンソールを使用する

Azure シリアルコンソールを使用して VM を再起動します。
1. シリアルコンソールウィンドウの上部にある shutdown ボタンを選択します。
2. [VM の起動 (ハード)] オプションを選択します。
シリアルコンソール接続が再開されると、シリアルコンソールウィンドウの左上隅にカウントダウンカウンターが表示されます。 ESCAPE キーを押して、GRUB メニューで VM を中断します。
下方向キーを押して、以前のカーネルバージョンを選択します。
/etc/default/grub ファイル内のGRUB_DEFAULT変数を手動で変更既定のカーネルバージョンを変更します。これは永続的な変更です。

Note

GRUB メニューに一覧表示されているカーネルバージョンが 1 つしかない場合は、 Offline のトラブルシューティング方法に従って、修復 VM からこの問題をトラブルシューティングします。

修復 VM を使用する (ALAR スクリプト)

Azure Cloud Shell で次の bash コマンドを実行して、修復 VM を作成します。詳細については、「 Azure Linux Auto Repair (ALAR) を使用して Linux VM のカーネルオプションを修正するを参照してください。
```
az vm repair create --verbose -g $RGNAME -n $VMNAME --repair-username rescue --repair-password 'password!234' --copy-disk-name repairdiskcopy
```

次のコマンドを実行して、壊れたカーネルを以前にインストールしたバージョンに置き換えます。

az vm repair run --verbose -g $RGNAME -n $VMNAME --run-id linux-alar2 --parameters kernel --run-on-repair

az vm repair restore --verbose -g $RGNAME -n $VMNAME

Note

システムにインストールされているカーネルバージョンが 1 つしかない場合は、オフラインのトラブルシューティング方法に従って、修復 VM からこの問題をトラブルシューティングします。

既定のカーネルバージョンを手動で変更する

修復 VM (chroot 内) または実行中の VM から既定のカーネルバージョンを変更するには、次の手順に従います。

Note

カーネルのダウングレードロールバックが行われた場合は、古いバージョンではなく最新のカーネルバージョンを選択します。

RHEL 7、Oracle Linux 7、CentOS 7
1. 次のいずれかのコマンドを実行して、GRUB 構成ファイルで使用可能なカーネルの一覧を検証します。
  - Gen1 VM:
```
cat /boot/grub2/grub.cfg | grep menuentry
```
  - Gen2 VM:
```
cat /boot/efi/EFI/*/grub.cfg | grep menuentry
```
2. 次のコマンドを実行して、新しい既定のカーネルを設定し、対応するカーネルタイトルを指定します。
```
# grub2-set-default 'Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64'
```
  Note
  
  Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64を対応するメニューエントリタイトルに置き換えます。
3. 次のコマンドを実行して、新しい既定のカーネルが目的のカーネルであることを確認します。
```
grub2-editenv list
```
4. /etc/default/grub ファイル内のGRUB_DEFAULT変数の値がsavedに設定されていることを確認します。変更するには、GRUB 構成ファイル生成変更を適用してください。
RHEL 8/9 および CentOS 8
1. 次のコマンドを実行して、使用可能なカーネルを一覧表示します。
```
ls -l /boot/vmlinuz-*
```
2. 次のコマンドを実行して、新しい既定のカーネルを設定します。
```
grubby --set-default /boot/vmlinuz-4.18.0-372.19.1.el8_6.x86_64
```
  Note
  
  4.18.0-372.19.1.el8_6.x86_64を対応するカーネルバージョンに置き換えます。
3. 次のコマンドを実行して、新しい既定のカーネルが目的のカーネルであることを確認します。
```
grubby --default-kernel
```
SLES 12/15、Ubuntu 18.04/20.04
1. 次のコマンドを実行して、GRUB 構成ファイルで使用可能なカーネルを一覧表示します。
  - Gen1 VM:
    - SLES 12/15:
```
cat /boot/grub2/grub.cfg | grep menuentry
```
    - Ubuntu 18.04/20.04:
```
cat /boot/grub/grub.cfg | grep menuentry
```
  - Gen2 VM:
```
cat /boot/efi/EFI/*/grub.cfg | grep menuentry
```
2. /etc/default/grub/grub ファイル内のGRUB_DEFAULT変数の値を変更して、新しい既定のカーネルを設定します。システムにインストールされている最新のカーネルバージョンでは、既定値は 0 です。次に使用可能なカーネルは "1>2" に設定されます。
```
vi /etc/default/grub
GRUB_DEFAULT="1>2"
```
  Note
  
  GRUB_DEFAULT変数を構成する方法の詳細については、「SUSE Boot Loader GRUB2 および Ubuntu Grub2/Setup」を参照してください。参照として、最上位レベルのメニュー値は 0、最初の最上位レベルのサブメニュー値は 1、入れ子になった各メニュー値は 0 で始まります。たとえば、"1>2" は最初のサブメニューの 3 番目のメニュー項目です。
3. GRUB 構成ファイルを再生成して変更を適用します。「 GRUB をインストールし、対応する Linux ディストリビューションと VM の生成のために GRUB 構成ファイルを再生成の手順に従います。

カーネルパニック - 同期していません: VFS: unknown-block(0,0) にルート fs をマウントできません

このエラーは、最新のシステム更新プログラム (カーネル) が原因で発生します。これは、RHEL ベースのディストリビューションでよく見られます。この問題、Azure シリアルコンソールから確認できます。次のいずれかのエラーメッセージが表示されます。

"カーネルパニック - 同期されていません: VFS: unknown-block(0,0)にルート fs をマウントできません"

[  301.026129] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[  301.027122] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G               ------------ T 3.10.0-1160.36.2.el7.x86_64 #1
[  301.027122] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008  12/07/2018
[  301.027122] Call Trace:
[  301.027122]  [<ffffffff82383559>] dump_stack+0x19/0x1b
[  301.027122]  [<ffffffff8237d261>] panic+0xe8/0x21f
[  301.027122]  [<ffffffff8298b794>] mount_block_root+0x291/0x2a0
[  301.027122]  [<ffffffff8298b7f6>] mount_root+0x53/0x56
[  301.027122]  [<ffffffff8298b935>] prepare_namespace+0x13c/0x174
[  301.027122]  [<ffffffff8298b412>] kernel_init_freeable+0x222/0x249
[  301.027122]  [<ffffffff8298ab28>] ? initcall_blcklist+0xb0/0xb0
[  301.027122]  [<ffffffff82372350>] ? rest_init+0x80/0x80
[  301.027122]  [<ffffffff8237235e>] kernel_init+0xe/0x100
[  301.027122]  [<ffffffff82395df7>] ret_from_fork_nospec_begin+0x21/0x21
[  301.027122]  [<ffffffff82372350>] ? rest_init+0x80/0x80
[  301.027122] Kernel Offset: 0xc00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)

"error: file '/initramfs-*.img' が見つかりません"

エラー: ファイル '/initramfs-3.10.0-1160.36.2.el7.x86_64.img' が見つかりません。

この種のエラーは、initramfs ファイルが生成されていないこと、GRUB 構成ファイルに修正プログラムの適用プロセス後に initrd エントリが見つからない、または GRUB の手動構成が間違っていることを示します。

サーバーを再起動する前に、次のいずれかのコマンドを実行して、GRUB 構成を検証し、カーネル更新プログラムがある場合は内容を /boot することをお勧めします。更新が完了し、initramfs ファイルが見つからないことを確認することが重要です。

BIOS ベース - Gen1 システム

# ls -l /boot
# cat /boot/grub2/grub.cfg

UEFI ベース - Gen2 システム

# ls -l /boot
# cat /boot/efi/EFI/*/grub.cfg

Azure Repair VM ALAR スクリプトを使用して不足している initramfs を再生成する

Azure Cloud Shell で次の Bash コマンドラインを実行して、修復 VM を作成します。詳細については、「 Azure Linux Auto Repair (ALAR) を使用して Linux VM の initrd オプションを修正するを参照してください。
```
az vm repair create --verbose -g $RGNAME -n $VMNAME --repair-username rescue --repair-password 'password!234' --copy-disk-name repairdiskcopy
```
initrd/initramfs イメージを再生成し、initrd エントリが見つからない場合は GRUB 構成ファイルを再生成します。そのためには、次のコマンドを実行します。
```
az vm repair run --verbose -g $RGNAME -n $VMNAME --run-id linux-alar2 --parameters initrd --run-on-repair

az vm repair restore --verbose -g $RGNAME -n $VMNAME
```
復元コマンドが実行されたら、元の VM を再起動し、起動できることを検証します。

不足している initramfs を手動で再生成する

重要

以前のカーネルバージョンを使用するか、修復/復旧 VM から chroot 内で VM を起動できる場合は、不足している initramfs を手動で再生成します。
修復 VM から不足している initramfs を手動で再生成するには、 Offline のトラブルシューティングの手順 1 が既に実行されており、それらのコマンドが chroot 内で実行されていることを確認します。

起動に問題がある特定のカーネルバージョンを特定します。対応するカーネルパニックエラーからバージョン情報を抽出できます。

例として、次のスクリーンショットを参照してください。カーネルパニックエラーは、カーネルのバージョンが "3.10.0-1160.59.1.el7.x86_64" であることを示しています。
次のいずれかのコマンドを実行して、不足している initramfs ファイルを再生成します。
- RHEL/CentOS/Oracle Linux 7/8
```
sudo depmod -a 3.10.0-1160.59.1.el7.x86_64
sudo dracut -f /boot/initramfs-3.10.0-1160.59.1.el7.x86_64.img 3.10.0-1160.59.1.el7.x86_64
```
  重要
  
  3.10.0-1160.59.1.el7.x86_64を対応するカーネルバージョンに置き換えます。
- SLES 12/15
```
sudo depmod -a 5.3.18-150300.38.53-azure
sudo dracut -f /boot/initrd-5.3.18-150300.38.53-azure 5.3.18-150300.38.53-azure
```
  重要
  
  5.3.18-150300.38.53-azureを対応するカーネルバージョンに置き換えます。
- Ubuntu 18.04
```
sudo depmod -a 5.4.0-1077-azure
sudo mkinitramfs -k -o /boot/initrd.img-5.4.0-1077-azure
```
  重要
  
  5.4.0-1077-azureを対応するカーネルバージョンに置き換えます。
GRUB 構成ファイルを再生成します。「 GRUB のインストールと GRUB 構成ファイルの再生成」の手順に従って対応する Linux ディストリビューションと VM の生成用に GRUB 構成ファイルを再生成します
上記の手順が修復 VM から実行される場合は、オフラインのトラブルシューティングの手順 3 に従います。上記の手順を Azure シリアルコンソールから実行する場合は、オンラインのトラブルシューティング方法に従います。
最新のカーネルバージョンで VM を再起動します。

カーネルパニック - 同期されていません: init を強制終了しようとしました

Azure シリアルコンソールからこの問題を特定します。次のような出力が表示されます。

dracut Warning: Boot has failed. To debug this issue add "rdshell" to the kernel command line.
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: init Not tainted 2.6.32-754.17.1.el6.x86_64 #1
Call Trace:
 [<ffffffff81558bfa>] ? panic+0xa7/0x18b
 [<ffffffff81130370>] ? perf_event_exit_task+0xc0/0x340
 [<ffffffff81086433>] ? do_exit+0x853/0x860
 [<ffffffff811a33b5>] ? fput+0x25/0x30
 [<ffffffff81564272>] ? system_call_after_swapgs+0xa2/0x152
 [<ffffffff81086498>] ? do_group_exit+0x58/0xd0
 [<ffffffff81086527>] ? sys_exit_group+0x17/0x20
 [<ffffffff81564357>] ? system_call_fastpath+0x35/0x3a
 [<ffffffff8156427e>] ? system_call_after_swapgs+0xae/0x152

この種のカーネルパニックは、次の原因が考えられます。

重要なファイルとディレクトリがありません。
重要なシステムコアライブラリとパッケージが見つからない
ファイルのアクセス許可が正しくありません
不足しているパーティション
SELinux の問題

原因の詳細と解決策については、次のセクションを参照してください。コマンドが、 Offline のトラブルシューティングの指示に従って、chroot 環境内の修復/復旧 VM から実行されていることを確認します。

重要なファイルとディレクトリが見つからない

重要な Linux のファイルとディレクトリは、人為的エラーが原因で見つかりません。たとえば、ファイルが誤って削除されたり、ファイルシステムが破損したりします。

OS ディスクのコピーを修復 VM にアタッチし、 chroot を使用して対応するファイルシステムをマウントした後 OS ディスクの内容を検証します。出力は、同じ OS バージョンを実行している稼働中の VM からの出力と比較できます。
```
ls -l /
ls -l /usr/lib
ls -l /usr/lib64
ls -lR / | more
```
不足しているファイルをバックアップから復元します。詳細については、「 Azure 仮想マシンのバックアップからファイルを回復する」を参照してください。不足しているファイルの数によっては、VM の完全復元を実行することをお勧めします。詳細については、「 Azure portal で Azure VM データを復元する方法を参照してください。

重要なシステムコアライブラリとパッケージが見つからない

重要なシステムコアライブラリ、ファイル、またはパッケージは、システムから削除されるか、破損しています。この問題を解決するには、影響を受けるライブラリ、ファイル、またはパッケージを再インストールします。このソリューションは、Red Hat/CentOS/SUSE VM などの RPM ベースのディストリビューションで動作します。その他の Linux ディストリビューションの場合は、バックアップから VM を再インストールすることをお勧めします。

再インストールを実行するには、次の手順に従います。

影響を受ける VM と同じ OS バージョンと世代の生イメージを使用して、復旧 VM を作成します。
問題のトラブルシューティングを行うには、復旧 VM の chroot 環境にアクセスします。
```
sudo chroot /rescue
```
コマンド出力は、次に示すように、不足しているライブラリまたは破損しているライブラリを示します。
```
/bin/bash: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
```

復旧 VM 内のすべてのシステムパッケージとそれに対応する状態を確認します。同じ OS バージョンを実行している正常な VM と出力を比較します。

sudo rpm --verify --all --root=/rescue

このコマンドの出力例は次のとおりです。

error: Failed to dlopen /usr/lib64/rpm-plugins/systemd_inhibit.so /lib64/librt.so.1: undefined symbol: __pthread_attr_copy, version GLIBC_PRIVATE
S.5....T.  c /etc/dnf/dnf.conf
S.5....T.  c /etc/ssh/sshd_config
.M.......    /boot/efi/EFI/BOOT/BOOTX64.EFI
.M.......    /boot/efi/EFI/BOOT/fbx64.efi
.M.......    /boot/efi/EFI/redhat/BOOTX64.CSV
.M.......    /boot/efi/EFI/redhat/mmx64.efi
.M.......    /boot/efi/EFI/redhat/shimx64-redhat.efi
.M.......    /boot/efi/EFI/redhat/shimx64.efi
missing     /run/motd.d
.M.......  g /var/spool/anacron/cron.daily
.M.......  g /var/spool/anacron/cron.monthly
.M.......  g /var/spool/anacron/cron.weekly
missing     /lib64/libc-2.28.so     <-------
.M.......    /boot/efi/EFI/redhat
S.5....T.  c /etc/security/pwquality.conf

出力行 missing /lib64/libc-2.28.so は、手順 2 の前のエラーに関連しており、 libc-2.28.so パッケージが見つからない場合を示します。ただし、 libc-2.28.so パッケージは変更できます。この場合、出力にはmissingではなく.M.....が表示されます。 libc-2.28.so パッケージは、次の手順の例として参照されます。

復旧 VM で、ライブラリ /lib64/libc-2.28.so が含まれているパッケージを確認します。
```
sudo rpm -qf /lib64/libc-2.28.so
```
```
glibc-2.28-127.0.1.el8.x86_64
```
Note

出力には、パッケージ名とバージョンを含め、再インストールする必要があるパッケージが表示されます。パッケージのバージョンは、影響を受ける VM にインストールされているバージョンとは異なる場合があります。

影響を受ける VM で、インストールされている glibc パッケージのバージョンを確認します。

sudo rpm -qa --all --root=/rescue | grep -i glibc

glibc-common-2.28-211.0.1.el8.x86_64
glibc-gconv-extra-2.28-211.0.1.el8.x86_64
glibc-2.28-211.0.1.el8.x86_64     <----  
glibc-langpack-en-2.28-211.0.1.el8.x86_64

パッケージ glibc-2.28-211.0.1.el8.x86_64をダウンロードします。 OS ベンダーの公式 Web サイトから、または実行している OS に応じて、 yumdownloader や zypper install --download-only <packagename> などのパッケージ管理ツールを使用して、復旧 VM からダウンロードできます。

yumdownloader ツールの使用例を次に示します。
```
cd /tmp
sudo yumdownloader glibc-2.28-211.0.1.el8.x86_64
```
```
Last metadata expiration check: 0:03:24 ago on Thu 25 May 2023 02:36:25 PM UTC.
glibc-2.28-211.0.1.el8.x86_64.rpm               8.7 MB/s | 2.2 MB     00:00    
```

影響を受けるパッケージを復旧 VM に再インストールします。

sudo rpm -ivh --root=/rescue /tmp/glibc-*.rpm --replacepkgs --replacefiles

warning: /tmp/glibc-2.28-211.0.1.el8.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID ad986da3: NOKEY
Verifying...                          ################################# [100%]
Preparing...                          ################################# [100%]
Updating / installing...
   1:glibc-2.28-211.0.1.el8           ################################# [100%]

復旧 VM の chroot 環境にアクセスして、再インストールを検証します。
```
sudo chroot /rescue
```
復旧 VM をオフにし、OS ディスクを影響を受ける VM にスワップします。

ファイルのアクセス許可が正しくありません

人為的エラー (たとえば、/やその他の重要な OS ファイルシステムでchmod 777を実行するなど) により、システム全体のファイルのアクセス許可が正しくありません。この問題を解決するには、ファイルのアクセス許可を復元します。このソリューションは、Red Hat/CentOS/SUSE VM などの RPM ベースのディストリビューションで動作します。その他の Linux ディストリビューションの場合は、バックアップから VM を再インストールすることをお勧めします。

ファイルのアクセス許可を復元するには、OS ディスクのコピーを修復 VM にアタッチし、 chroot を使用して対応するファイルシステムをマウントした後、次のコマンドを実行します。

rpm -a --setperms
rpm --setugids --all
chmod u+s /bin/sudo
chmod 660 /etc/sudoers.d/*
chmod 644 /etc/ssh/*.pub
chmod 640 /etc/ssh/*.key

Note

運用システムを実行している場合は、このコマンドを実行しないでください。

対応するファイルのアクセス許可を手動で回復した後も問題が解決しない場合は、バックアップから restore を実行。

不足しているパーティション

/usr、/opt、/var、/home、/tmp、および/のファイルシステムが異なるパーティションに分散されている場合、パーティションレベルの問題が原因でデータにアクセスできなくなる可能性があります。これは、パーティションのサイズ変更操作中の誤りなどが原因である可能性があります。

このシナリオでは、元のパーティションテーブルレイアウトを文書化し、元の各パーティションの開始セクターと終了セクターを正確に文書化し、新しいファイルシステムの作成など、システム上でそれ以上変更を加えなければ、 fdisk (MBR パーティションテーブルの場合) や gdisk (GPT パーティションテーブルの場合) などのツールを使用して、同じ元のレイアウトを使用してパーティションを再作成して、不足しているファイルシステムにアクセスします。

この方法が機能しない場合は、バックアップから restore を実行。

SELinux の問題

SELinux のアクセス許可が正しくないと、システムが重要なファイルにアクセスできなくなる可能性があります。この問題を解決するには、次の手順に従ってください。

間違った SELinux アクセス許可が原因でシステムに問題があるかどうかを確認するには、GRUB linux16 行に selinux=0 カーネルオプションを追加して、SELinux を無効にしてシステムを起動します。
システムが起動できる場合は、次のコマンドを実行して起動時に SELinux の再ラベル付けをトリガーし、システムを再起動します。
```
touch /.autorelabel
```
それでも VM を起動できない場合は、バックアップから完全な VM 復元を行います。詳細については、「 Azure portal で Azure VM データを復元する方法を参照してください。

カーネル関連のブートに関するその他の問題

この記事では、Azure で識別される最も一般的な Linux カーネルパニックについて説明します。一般的なカーネルパニックシナリオの詳細については、「 Azure Linux VM でのカーネルパニック - 一般的なカーネルパニックイベント」を参照してください。

ブートやセキュアシェル (SSH) のシナリオを引き起こさない可能性がある、その他の重要なカーネルパニックが考えられます。

オフラインのトラブルシューティングで説明されているように、chroot 環境内の修復 VM からコマンドを実行してください。システムが以前のカーネルバージョンで既に起動されている場合は、Online のトラブルシューティングで説明されているように、ルート特権またはsudoを使用して、元の VM からこれらのコマンドを実行することもできます。

最近のカーネルのアップグレード

最近のカーネルアップグレード後にカーネルパニックが開始した場合は、以前のカーネルバージョンで VM を起動します。詳細については、「以前のカーネルバージョンでのシステムの起動を参照してください。

Linux ディストリビューションベンダーによってリリースされた新しいカーネルバージョンが既に存在するかどうかを確認し、インストールすることもできます。最新のカーネルバージョンをインストールする方法の詳細については、「 Kernel 更新プロセスを参照してください。

最近のカーネルのダウングレード

最近のカーネルダウングレード後にカーネルパニックが開始した場合は、インストールされている最新のカーネルに戻ります。 Linux ディストリビューションベンダーによってリリースされた新しいカーネルバージョンが既に存在するかどうかを確認し、インストールすることもできます。最新のカーネルバージョンをインストールする方法の詳細については、「 Kernel 更新プロセスを参照してください。

最新のカーネルバージョンでシステムを起動するには、「既定のカーネルバージョンを手動で変更するの指示に従いますが、GRUB メニューに一覧表示されている最初のカーネルを選択します。手動による変更では、 GRUB_DEFAULT 値を 0 に設定し、対応する GRUB 構成ファイルを再生成できます。

カーネルモジュールの変更

新しいカーネルモジュールまたは不足しているカーネルモジュールに関連するカーネルパニックが発生する可能性があります。問題を引き起こす特定のカーネルモジュール (存在する場合) の詳細を取得するには、対応するカーネルパニックトレースを確認します。

読み込まれたカーネルモジュールと、 /etc/modprobe.d/*.conf ファイル内の無効なカーネルモジュールを検証するには、次のいずれかのコマンドを実行します。

RHEL/CentOS/Oracle Linux 7/8
```
lsinitrd /boot/initramfs-3.10.0-1160.59.1.el7.x86_64.img
lsmod
cat /etc/modprobe.d/*.conf
```
重要

3.10.0-1160.59.1.el7.x86_64を対応するカーネルバージョンに置き換えます。
SLES 12/15
```
lsinitrd /boot/initrd-5.3.18-150300.38.53-azure
lsmod
cat /etc/modprobe.d/*.conf
```
重要

5.3.18-150300.38.53-azureを対応するカーネルバージョンに置き換えます。
Ubuntu 18.04
```
lsinitramfs /boot/initrd.img-5.4.0-1077-azure
lsmod
cat /etc/modprobe.d/*.conf
```
重要

5.4.0-1077-azureを対応するカーネルバージョンに置き換えます。

特定のカーネルモジュールを削除するには、次のコマンドを実行必要に応じて initramfs を生成します。

rmmod <kernel_module_name>

システムサービスが特定のカーネルモジュールを使用している場合は、 systemctl disable <serviceName> または systemctl stop <serviceName> コマンドを実行して無効にします。

オペレーティングシステムの最近の構成の変更

問題の原因となる可能性がある最近のカーネル構成の変更を特定します。問題を解決するには、これらの設定を調整するか、構成の変更をロールバックします。

次のコマンドを実行して、次のいずれかのファイルで構成されている永続的なカーネルパラメーターを見つけます。

cat /etc/systctl.conf
cat /etc/sysctl.d/*

次のコマンドを実行して、現在のカーネルパラメーターとその現在の値を分析します。

sysctl -a

Note

chroot 環境からではなく、実行中のシステムでこのコマンドを実行します。

見つからない可能性があるファイル

この種の問題の詳細については、「重要なファイルとディレクトリの読み取りを参照してください。

ファイルに対する間違ったアクセス許可

この種の問題の詳細については、「 Wrong ファイルのアクセス許可を参照してください。

不足しているパーティション

この種の問題の詳細については、「パーティションの作成」を参照してください。

カーネルのバグ

Azure シリアルコンソールからこの問題を特定します。この種の問題は、次の出力のようになります。

[5275698.017004] kernel BUG at XXX/YYY.c:72!
[5275698.017004] invalid opcode: 0000 [#1] SMP

この種のカーネルパニックは、カーネルのバグやサードパーティのカーネルバグに関連付けられています。

カーネルのバグを修正するには、カーネル BUG 文字列を使用してベンダーのナレッジベースを検索し、システムが実行されている対応するカーネルバージョンで既知の問題を探します。ベンダーの重要なリソースを次に示します。

Red Hat Kernel Oops Analyzer

このツールは、カーネルクラッシュの診断に役立つよう設計されています。テキスト、 vmcore-dmesg.txt、または 1 つ以上のカーネルoops メッセージを含むファイルを入力すると、カーネルクラッシュの問題の診断手順が示されます。
Red Hat のナレッジベース

Red Hat リソースにアクセスするには、Microsoft Azure アカウントと Red Hat アカウントをリンクします。詳細については、「 Microsoft Azure のお客様が Red Hat カスタマーポータルにアクセスする方法を参照してください。
SUSE のナレッジベース
Ubuntu のナレッジベース

最新のカーネルバージョンで既に修正されている可能性のあるバグを除外するために、すべてのシステムを最新の状態に保つことをお勧めします。詳細については、カーネルの更新プロセスに関するページを参照してください。

ベンダーからさらに分析が要求された場合は、コアダンプを生成するために kdump を構成して有効にします。

カーネル更新プロセス

使用可能な最新のカーネルバージョンをインストールするには、次のいずれかのコマンドを実行します。

RHEL/CentOS/Oracle Linux
```
yum update kernel
```
SLES 12/15
```
zypper refresh
zypper update kernel*
```
Ubuntu 18.04/20.04
```
apt update
apt install linux-azure
```

特定のカーネルバージョンを再インストールするには、次のいずれかのコマンドを実行します。再インストールしようとしているのと同じカーネルバージョンで起動されていないことを確認します。詳細については、「以前のカーネルバージョンでのシステムの起動を参照してください。

RHEL/CentOS/Oracle Linux
```
yum reinstall kernel-3.10.0-1160.59.1.el7.x86_64
```
重要

3.10.0-1160.59.1.el7.x86_64を対応するカーネルバージョンに置き換えます。
SLES 12/15
```
zypper refresh
zypper install -f kernel-azure-5.3.18-150300.38.75.1.x86_64
```
重要

kernel-azure-5.3.18-150300.38.75.1.x86_64を対応するカーネルバージョンに置き換えます。
- Ubuntu 18.04/20.04
```
apt update
apt install --reinstall linux-azure=5.4.0.1091.68
```
  重要
  
  5.4.0.1091.68を対応するカーネルバージョンに置き換えます。

システムを更新し、利用可能な最新の変更を適用するには、次のいずれかのコマンドを実行します。

RHEL/CentOS/Oracle Linux
```
yum update
```
SLES 12/15
```
zypper refresh
zypper update
```
Ubuntu 18.04/20.04
```
apt update
apt upgrade
```

カーネルパニックは、次のいずれかの項目に関連している可能性があります。詳細については、「実行時のカーネルパニックを参照してください。

アプリケーションワークロードの変更。
アプリケーション開発またはアプリケーションのバグ。
パフォーマンス関連の問題など。

次のステップ

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

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

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

次の方法で共有

カーネルの変更を適用した後、Azure Linux 仮想マシンの起動に失敗する

前提条件

カーネル関連のブートの問題を特定する方法

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

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

古いカーネルバージョンのブートシステム

Azure シリアルコンソールを使用する

修復 VM を使用する (ALAR スクリプト)

既定のカーネルバージョンを手動で変更する

カーネルパニック - 同期していません: VFS: unknown-block(0,0) にルート fs をマウントできません

Azure Repair VM ALAR スクリプトを使用して不足している initramfs を再生成する

不足している initramfs を手動で再生成する

カーネルパニック - 同期されていません: init を強制終了しようとしました

重要なファイルとディレクトリが見つからない

重要なシステムコアライブラリとパッケージが見つからない

ファイルのアクセス許可が正しくありません

不足しているパーティション

SELinux の問題

カーネル関連のブートに関するその他の問題

最近のカーネルのアップグレード

最近のカーネルのダウングレード

カーネルモジュールの変更

オペレーティングシステムの最近の構成の変更

見つからない可能性があるファイル

ファイルに対する間違ったアクセス許可

不足しているパーティション

カーネルのバグ

カーネル更新プロセス

次のステップ

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

フィードバック

その他のリソース

次の方法で共有

カーネルの変更を適用した後、Azure Linux 仮想マシンの起動に失敗する

前提条件

カーネル関連のブートの問題を特定する方法

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

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

古いカーネル バージョンのブート システム

Azure シリアル コンソールを使用する

修復 VM を使用する (ALAR スクリプト)

既定のカーネル バージョンを手動で変更する

カーネル パニック - 同期していません: VFS: unknown-block(0,0) にルート fs をマウントできません

Azure Repair VM ALAR スクリプトを使用して不足している initramfs を再生成する

不足している initramfs を手動で再生成する

カーネル パニック - 同期されていません: init を強制終了しようとしました

重要なファイルとディレクトリが見つからない

重要なシステム コア ライブラリとパッケージが見つからない

ファイルのアクセス許可が正しくありません

不足しているパーティション

SELinux の問題

カーネル関連のブートに関するその他の問題

最近のカーネル のアップグレード

最近のカーネルのダウングレード

カーネル モジュールの変更

オペレーティング システムの最近の構成の変更

見つからない可能性があるファイル

ファイルに対する間違ったアクセス許可

不足しているパーティション

カーネルのバグ

カーネル更新プロセス

次のステップ

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

フィードバック

その他のリソース

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

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

古いカーネルバージョンのブートシステム

Azure シリアルコンソールを使用する

既定のカーネルバージョンを手動で変更する

カーネルパニック - 同期していません: VFS: unknown-block(0,0) にルート fs をマウントできません

カーネルパニック - 同期されていません: init を強制終了しようとしました

重要なシステムコアライブラリとパッケージが見つからない

最近のカーネルのアップグレード

カーネルモジュールの変更

オペレーティングシステムの最近の構成の変更