カーネルアップデートの原因を特定する方法

カーネルアップデートの原因を特定する方法

Azureでホストされ、当時人気のあるイメージに展開されたUbuntu 20.04 VMがあります。複数のドッカーコンテナを実行し、毎日17:00に終了し、毎朝06:30に開始します。

今日確認してみると、仮想マシンにアクセスできないことがわかりました。結局、マシンが再び再起動することが判明しました。 Azure のシリアル ログでカーネル パニックが繰り返し発生し、仮想マシンが自動的に再起動されることがわかります。このエラーを追跡しました。https://bugs.launchpad.net/ubuntu/+source/linux-aws-5.13/+bug/1977919

デフォルトでは、Ubuntu 5.13.0-1028.33から20.04.1-azure 5.13.19には、5.13.0-1029で迅速に修正された変更が導入されました。

しかし、私は更新していません。 Azure で更新管理を確認すると、パッチの記録は発生しませんでした。昨日から今日までこのコンピュータにログインした人は誰もいません。

ディスクを別の仮想マシンに接続し、カーネルログを確認します。昨日のスタートアップはこれでした。

Jun  9 06:08:29 myserver kernel: [    0.000000] Linux version 5.13.0-1025-azure (buildd@lcy02-amd64-007)

今日:

Jun 10 06:07:55 myserver kernel: [    0.000000] Linux version 5.13.0-1028-azure (buildd@lcy02-amd64-109)

昨日の起動後、dpkg.logで次のことを確認しました。

2022-06-09 06:33:49 install linux-image-5.13.0-1028-azure:amd64 <none> 5.13.0-1028.33~20.04.1

何がこれを引き起こすのか、どうすればわかりますか?

ベストアンサー1

この/var/log/unattended-upgradesディレクトリは存在しますか?それでは、そこにあるログを読んでください。

このパッケージがインストールされるとunattended-upgrades(最小インストールを選択しない限り、ほとんどのDebianベースのディストリビューションのデフォルト値になる可能性があります)、systemdサービスapt-daily-upgrade.service(または/etc/cron.daily/aptディストリビューションがsystemdを使用していない場合)は毎日自動セキュリティパッチのアップグレードをトリガーします。

おすすめ記事