カーネルの変更を適用した後、Azure Linux 仮想マシンの起動に失敗する
注:
この記事で参照されている CentOS は Linux ディストリビューションであり、End Of Life (EOL) に到達します。 使用を検討し、それに応じて計画します。 詳細については、「 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 ファイル システムのコピーをマウントします。
注:
または、Azure portalを使用して手動でレスキュー VM を作成することもできます。 詳細については、「Azure portalを使用して OS ディスクを復旧 VM に接続して Linux VM のトラブルシューティングを行う」を参照してください。
対応するセクションに移動して、特定のカーネル関連のブートの問題を解決します。
カーネル関連のブートの問題が解決されたら、次の操作を実行します。
- chroot を終了します。
- レスキュー/修復 VM からファイル システムのコピーをマウント解除します。
- コマンドを
az vm repair restore実行して、修復された OS ディスクを VM の元の OS ディスクと交換します。 詳細については、「 Azure Virtual Machine 修復コマンドを使用して Linux VM を修復する」の手順 5 を参照してください。 - Azure シリアル コンソールを見るか、VM に接続して VM を起動できるかどうかを検証します。
重要なカーネル関連のコンテンツ、パーティション全体
/boot、またはその他の重要なコンテンツが見つからない場合、回復できない場合は、バックアップから VM を復元することをお勧めします。 詳細については、「Azure portalで Azure VM データを復元する方法」を参照してください。
古いカーネル バージョンのブート システム
Azure シリアル コンソールを使用する
Azure シリアル コンソールを使用して VM を再起動します。
- シリアル コンソール ウィンドウの上部にある シャットダウン ボタンを選択します。
- [ VM の再起動 (ハード)] オプションを選択します。
シリアル コンソール接続が再開されると、シリアル コンソール ウィンドウの左上隅にカウントダウン カウンターが表示されます。 ESCAPE キーを押して、GRUB メニューで VM を中断します。
下方向キーを押して、以前のカーネル バージョンを選択します。
「既定の
GRUB_DEFAULTカーネル バージョンを手動で変更する」の指示に従って、/etc/default/grub ファイル内の変数を変更します。 これは永続的な変更です。
注:
GRUB メニューに表示されるカーネル バージョンが 1 つだけの場合は、 オフライントラブルシューティング の方法に従って、修復 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
注:
システムにインストールされているカーネル バージョンが 1 つだけの場合は、 オフライントラブルシューティング の方法に従って、修復 VM からこの問題をトラブルシューティングします。
既定のカーネル バージョンを手動で変更する
修復 VM (chroot 内) または実行中の VM から既定のカーネル バージョンを変更するには、次の手順に従います。
注:
カーネルのダウングレード ロールバックが完了した場合は、古いカーネル バージョンではなく、最新のカーネル バージョンを選択します。
RHEL 7、Oracle Linux 7、CentOS 7
次のいずれかのコマンドを実行して、GRUB 構成ファイルで使用可能なカーネルの一覧を検証します。
Gen1 VM:
cat /boot/grub2/grub.cfg | grep menuentryGen2 VM:
cat /boot/efi/EFI/*/grub.cfg | grep menuentry
次のコマンドを実行して、新しい既定のカーネルを設定し、対応するカーネル タイトルを指定します。
# grub2-set-default 'Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64'注:
を対応するメニューエントリタイトルに置き換えます
Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64。次のコマンドを実行して、新しい既定のカーネルが目的のカーネルであることを検証します。
grub2-editenv list/etc/default/grub ファイル内の変数の
GRUB_DEFAULT値が にsaved設定されていることを確認します。 これを変更するには、 GRUB 構成ファイルを再生成 して変更を適用してください。
RHEL 8/9 および CentOS 8
次のコマンドを実行して、使用可能なカーネルを一覧表示します。
ls -l /boot/vmlinuz-*次のコマンドを実行して、新しい既定のカーネルを設定します。
grubby --set-default /boot/vmlinuz-4.18.0-372.19.1.el8_6.x86_64注:
を対応するカーネル バージョンに置き換えます
4.18.0-372.19.1.el8_6.x86_64。次のコマンドを実行して、新しい既定のカーネルが目的のカーネルであることを検証します。
grubby --default-kernel
SLES 12/15、Ubuntu 18.04/20.04
次のコマンドを実行して、GRUB 構成ファイルで使用可能なカーネルを一覧表示します。
Gen1 VM:
SLES 12/15:
cat /boot/grub2/grub.cfg | grep menuentryUbuntu 18.04/20.04:
cat /boot/grub/grub.cfg | grep menuentry
Gen2 VM:
cat /boot/efi/EFI/*/grub.cfg | grep menuentry
/etc/default/grub ファイル内の変数の値を
GRUB_DEFAULT変更して、新しい既定のカーネルを設定します。 システムにインストールされている最新のカーネル バージョンの場合、既定値は 0 です。 次に使用可能なカーネルは "1>2" に設定されます。vi /etc/default/grub GRUB_DEFAULT="1>2"注:
変数を構成
GRUB_DEFAULTする方法の詳細については、 SUSE ブート ローダー GRUB2 と Ubuntu Grub2/Setup に関するページを参照してください。 参考として、最上位の menuentry 値は 0、最初の最上位レベルのサブメニュー値は 1、入れ子になった各 menuentry 値は 0 から始まります。 たとえば、"1>2" は最初のサブメニューの 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' が見つかりません"
error: ファイル '/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.cfgUEFI ベース - 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 repairdiskcopyinitrd/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 $VMNAMErestore コマンドが実行されたら、元の VM を再起動し、起動できることを検証します。
不足している initramfs を手動で再生成する
重要
- 以前のカーネル バージョンを使用するか、修復/レスキュー VM から chroot 内で VM を起動できる場合は、不足している initramfs を手動で再生成します。
- 修復 VM から不足している initramfs を手動で再生成するには、 オフライン トラブルシューティング の手順 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 を再インストールし、 対応する Linux ディストリビューションと VM の生成用に GRUB 構成ファイルを再生成する」の手順に従います
上記の手順が修復 VM から実行される場合は、「 オフライントラブルシューティング」の手順 3 に従います。 上記の手順を Azure Serial コンソールから実行する場合は、 オンライントラブルシューティング 方法に従います。
最新のカーネル バージョンで 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
この種のカーネル パニックは、次の考えられる原因によって発生します。
原因の詳細と解決策については、次のセクションを参照してください。 「オフライントラブルシューティング」の指示に従って、コマンドが 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.soglibc-2.28-127.0.1.el8.x86_64注:
出力には、パッケージ名とバージョンなど、再インストールする必要があるパッケージが表示されます。 パッケージのバージョンは、影響を受ける VM にインストールされているバージョンとは異なる場合があります。
影響を受ける VM で、 インストールされている glibc パッケージのバージョンを確認します。
sudo rpm -qa --all --root=/rescue | grep -i glibcglibc-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 に
yumdownloaderzypper install --download-only <packagename>応じて、パッケージ管理ツールを使用して、レスキュー VM からダウンロードできます。ツールの使用例を次に
yumdownloader示します。cd /tmp sudo yumdownloader glibc-2.28-211.0.1.el8.x86_64Last 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 --replacefileswarning: /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 にスワップします。
ファイルのアクセス許可が間違っている
システム全体のファイルのアクセス許可が間違っているのは、人的エラー (たとえば、他のユーザーが実行 chmod 777 している OS ファイル システムなど) が原因で / 変更されます。 この問題を解決するには、ファイルのアクセス許可を復元します。 このソリューションは、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
注:
運用システムを実行する場合は、このコマンドを実行しないでください。
対応するファイルのアクセス許可を手動で回復した後も問題が解決しない場合は、 バックアップから復元を実行します。
パーティションがありません
、、、/home、および / ファイル システムが異なるパーティションに分散されている場合/usr、パーティション レベルの問題が原因でデータにアクセスできない可能性があります。これは、パーティションのサイズ変更操作中の間違いなどによって発生する可能性があります。 /tmp/var/opt
このシナリオでは、元のパーティション テーブル レイアウトを文書化し、元のパーティションごとに正確な開始と終了のセクターを記述し、新しいファイル システムの作成など、システム上でそれ以上の変更を行っていない場合は、 fdisk (MBR パーティション テーブルの場合) や gdisk (GPT パーティション テーブルの場合) などのツールを使用して同じ元のレイアウトを使用してパーティションを再作成して、不足しているファイル システムにアクセスします。
この方法が機能しない場合は、 バックアップからの復元を実行します。
SELinux の問題
SELinux のアクセス許可が間違っていると、システムが重要なファイルにアクセスできなくなる可能性があります。 この問題を解決するには、次の手順を実行します。
システムに間違った SELinux アクセス許可が原因で問題が発生しているかどうかを確認するには、 SELinux=0 カーネル オプションを GRUB linux16 行に追加して、SELinux を無効にしてシステムを起動します。
システムが起動できる場合は、次のコマンドを実行して、起動時に SELinux の再ラベル付けをトリガーし、システムを再起動します。
touch /.autorelabelVM がまだ起動できない場合は、バックアップから完全な VM の復元を行います。 詳細については、「Azure portalで Azure VM データを復元する方法」を参照してください。
その他のカーネル関連のブートの問題
この記事では、Azure で特定される最も一般的な Linux カーネル パニックについて説明します。 一般的なカーネル パニック シナリオの詳細については、「 Azure Linux VM でのカーネル パニック - 一般的なカーネル パニック イベント」を参照してください。
ブートやセキュア シェル (SSH) のシナリオを引き起こさない可能性がある、他にも重要なカーネル パニックが考えられます。
「オフライントラブルシューティング」で説明されているように、chroot 環境内の修復 VM からコマンドを実行してください。 システムが以前のカーネル バージョンで既に起動されている場合は、「オンライントラブルシューティング」で説明されているように、ルート特権または sudoを使用して、元の VM からこれらのコマンドを実行することもできます。
最近のカーネル アップグレード
最近のカーネル アップグレード後にカーネルパニックが開始された場合は、以前のカーネル バージョンで VM を起動します。 詳細については、「 古いカーネル バージョンでのブート システム」を参照してください。
Linux ディストリビューション ベンダーによってリリースされた新しいカーネル バージョンが既にある場合は、チェックしてインストールすることもできます。 最新のカーネル バージョンをインストールする方法の詳細については、「 カーネル更新プロセス」を参照してください。
最近のカーネル のダウングレード
最近のカーネル ダウングレード後にカーネル パニックが開始した場合は、インストールされている最新のカーネルに戻ります。 Linux ディストリビューション ベンダーによってリリースされた新しいカーネル バージョンが既にある場合は、チェックしてインストールすることもできます。 最新のカーネル バージョンをインストールする方法の詳細については、「 カーネル更新プロセス」を参照してください。
最新のカーネル バージョンでシステムを起動するには、「既定のカーネル バージョンを 手動で変更する」の手順に従いますが、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 stop <serviceName> コマンドをsystemctl disable <serviceName>実行して無効にします。
オペレーティング システムの最近の構成の変更
問題が発生する可能性がある最近のカーネル構成の変更を特定します。 問題を解決するには、これらの設定を調整するか、構成の変更をロールバックします。
次のコマンドを実行して、次のいずれかのファイルで構成されている永続的なカーネル パラメーターを見つけます。
cat /etc/systctl.conf
cat /etc/sysctl.d/*
次のコマンドを実行して、現在のカーネル パラメーターとその現在の値を分析します。
sysctl -a
注:
chroot 環境ではなく、実行中のシステムでこのコマンドを実行します。
見つからない可能性があるファイル
この種の問題の詳細については、「 重要なファイルとディレクトリが見つからない」を参照してください。
ファイルに対する間違ったアクセス許可
この種の問題の詳細については、「 間違ったファイルのアクセス許可」を参照してください。
パーティションがありません
この種の問題の詳細については、「 パーティションが見つからない」を参照してください。
カーネルのバグ
Azure シリアル コンソールからこの問題を特定します。 この種の問題は、次の出力のようになります。
[5275698.017004] kernel BUG at XXX/YYY.c:72!
[5275698.017004] invalid opcode: 0000 [#1] SMP
この種のカーネル パニックは、カーネルバグやサードパーティのカーネルバグに関連付けられています。
カーネルバグを修正するには、カーネル BUG 文字列を使用してベンダーのナレッジ ベースを検索し、システムが実行されている対応するカーネル バージョンで既知の問題を探します。 いくつかの重要なベンダー リソースを次に示します。
-
このツールは、カーネル クラッシュの診断に役立つよう設計されています。 テキスト、 vmcore-dmesg.txt、または 1 つ以上のカーネル oops メッセージを含むファイルを入力すると、カーネル クラッシュの問題の診断について説明します。
-
Red Hat リソースにアクセスするには、Microsoft Azure アカウントと Red Hat アカウントをリンクします。 詳細については、「 Microsoft Azure のお客様が Red Hat カスタマー ポータルにアクセスする方法」を参照してください。
最新のカーネル バージョンで既に修正されている可能性のあるバグを除外するために、すべてのシステムを最新の状態に保つことをお勧めします。 詳細については、「 カーネルの更新プロセス」を参照してください。
ベンダーからさらに分析が必要な場合は、kdump を構成して有効にしてコア ダンプを生成します。
カーネル更新プロセス
使用可能な最新のカーネル バージョンをインストールするには、次のいずれかのコマンドを実行します。
RHEL/CentOS/Oracle Linux
yum update kernelSLES 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 updateSLES 12/15
zypper refresh zypper updateUbuntu 18.04/20.04
apt update apt upgrade
カーネル パニックは、次のいずれかの項目に関連している可能性があります。 詳細については、「 実行時のカーネル パニック」を参照してください。
- アプリケーション ワークロードの変更。
- アプリケーション開発またはアプリケーションのバグ。
- パフォーマンス関連の問題など。
次の手順
特定のブート エラーがカーネル関連のブートの問題でない場合は、「Azure Linux Virtual Machinesブート エラーのトラブルシューティング」を参照して、さらにトラブルシューティング オプションを確認してください。
お問い合わせはこちらから
質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示