I remotely manage a couple of raspberry-pi's as vpn servers using ssl over openvpn.
One of these pi's is becoming problematic: it recently somehow gets misconfigured after almost every raspberrypi-kernel or -bootloader upgrade.
Since the problem until now happened using Stretch, I was hoping that a fresh install of Buster on another sd card would fix it, but unfortunately, already the first (remote) upgrade after the fresh install failed similarly.
The upgrade is performed on a Raspberry Pi 2 Model B using the normal apt-get upgrade procedure
There were no related errors/warnings reported on screen during the upgrade
Before the reboot I perform the following checks:
debsums -c raspberrypi-kernel debsums -c raspberrypi-bootloader check for errors in /var/log/apt/term.log check dates and md5sums in /boot check dates and md5sums in /boot/overlays check dates and md5sums in /var/cache/apt/archives/raspberrypi-*
and everything is fine
Note: I get the dates and md5sums from a similarly installed pi
The upgrade was supposed to bring the kernel from 4.19.58 to 4.19.66
After the reboot however,
uname -a still returns 4.19.58
This preventing the openvpn server from starting up properly, and consequently I have to go through several hoops to get access to the problem pi over ssl (the ssl server fortunately still starts up)
/lib/modules folder contains the (new) 4.19.66 subfolders
md5sums of some files in
/boot/overlays do not match any more
raspberrypi-(bootloader kernel) shows problems
It happens on both on Stretch and Buster, and I have used another sd card for the Buster installation. However, as far as I know, all 'code' comes from the sd card and nothing is written to the board...
Is there more that I could check before the reboot to predict problems?
Any hints on how to proceed would be welcome.