How to determine why the kernel updated

I have an Ubuntu 20.04 VM hosted in Azure, deployed from the prevailing image at the time. It runs a couple of docker containers, and shuts down every day at 17h00, and starts up at 06h30 every morning.

When I checked today, the VM was inaccessible. Eventually found that the machine kept rebooting itself. From the Serial Log in Azure, I saw repeated kernel panics, with the VM restarting automatically. Tracked it down to this bug: https://bugs.launchpad.net/ubuntu/+source/linux-aws-5.13/+bug/1977919

Basically, a change was introduced in Ubuntu 5.13.0-1028.33~20.04.1-azure 5.13.19, which was resolved shortly after in 5.13.0-1029.

However, I didn’t do updates. No history of patching has occurred via checking Update Management in Azure. No-one else logged on to the machine between yesterday and today.

Attached the disk to a different VM, and inspected the kernel logs. Start up yesterday looked like this:

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

Today:

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

In the dpkg.log, I saw this right after startup yesterday:

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

How do I determine what triggered this?

Asked By: Marcel

||

Does the /var/log/unattended-upgrades directory exist? If it does, read the logs within.

If the unattended-upgrades package has been installed (which may be the default on most Debian-based distributions unless you choose a minimal installation), then the systemd service apt-daily-upgrade.service (or /etc/cron.daily/apt if the distribution does not use systemd) will trigger an automatic security patch upgrade daily.

Answered By: telcoM

In case it helps anyone else: in my VPS, the solution was to dpkg-reconfigure unattended-upgrades, and choose "Yes" to the dialog that came up afterwards. I then systemctrl restart unattended-upgrades and was able to finally see a proper /var/log/unattended-upgrades/unattended-upgrades.log file (which was not there before).

Answered By: ttsiodras