カーネルの変更を適用した後、Azure Linux 仮想マシンの起動に失敗する
適用対象: ✔️ 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 のトラブルシューティングを行う」を参照してください。
対応するセクションに移動して、特定のカーネル関連のブートの問題を解決します。
カーネル関連のブートの問題が解決されたら、次の操作を実行します。
- chroot を終了します。
- 復旧/修復 VM からファイル システムのコピーのマウントを解除します。
az vm repair restoreコマンドを実行して、修復された OS ディスクを VM の元の OS ディスクにスワップします。 詳細については、「 Azure 仮想マシンの修復コマンドを使用して Linux VM を修復するの手順 5 を参照してください。- Azure シリアル コンソールを確認するか、VM に接続して、VM を起動できるかどうかを検証します。
カーネル関連の重要なコンテンツ、
/bootパーティション全体、またはその他の重要なコンテンツが見つからない場合、回復できない場合は、バックアップから VM を復元することをお勧めします。 詳細については、「 Azure portal で Azure VM データを復元する方法を参照してください。
古いカーネル バージョンのブート システム
Azure シリアル コンソールを使用する
Azure シリアル コンソールを使用して VM を再起動します。
- シリアル コンソール ウィンドウの上部にある shutdown ボタンを選択します。
- [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
次のいずれかのコマンドを実行して、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'Note
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_64Note
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 ファイル内の
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 番目のメニュー項目です。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.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 $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
この種のカーネル パニックは、次の原因が考えられます。
原因の詳細と解決策については、次のセクションを参照してください。 コマンドが、 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.soglibc-2.28-127.0.1.el8.x86_64Note
出力には、パッケージ名とバージョンを含め、再インストールする必要があるパッケージが表示されます。 パッケージのバージョンは、影響を受ける 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 に応じて、
yumdownloaderやzypper 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 にスワップします。
ファイルのアクセス許可が正しくありません
人為的エラー (たとえば、/やその他の重要な 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 文字列を使用してベンダーのナレッジ ベースを検索し、システムが実行されている対応するカーネル バージョンで既知の問題を探します。 ベンダーの重要なリソースを次に示します。
-
このツールは、カーネル クラッシュの診断に役立つよう設計されています。 テキスト、 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 フィードバック コミュニティに製品フィードバックを送信することもできます。