Kernel version | Linux OdroidN2 6.0.13-meson64 #22.11.2 SMP PREEMPT Sun Dec 18 16:52:19 CET 2022 aarch64 GNU/Linux
SBC model | Odroid N2 (aarch64)
Power supply used | 12V/2A power supply EU plug
SD card used | n.a. (eMMC)
Steps to reproduce & actual behaviour
I’ve recently seen after login the message that due to kernel upgrade a reboot is required:
DietPi v8.13.2 : Reboot required
- Device model : Odroid N2 (aarch64)
- CPU temp : 35 °C / 95 °F : Cool runnings
- LAN IP : 192.168.178.56 (eth0)
- MOTD : Check out the DietPi v8.13 release notes:
DietPi Team : https://github.com/MichaIng/DietPi#the-dietpi-project-team
Image by : DietPi Core Team (pre-image: from scratch)
Patreon Legends : Camry2731, Chris Gelatt
Website : https://dietpi.com/ | https://twitter.com/DietPi_
Contribute : https://dietpi.com/contribute.html
Web Hosting by : https://myvirtualserver.com
reboot : A reboot is required to finalise a recent kernel upgrade
dietpi-launcher : All the DietPi programs in one place
dietpi-config : Feature rich configuration tool for your device
dietpi-software : Select optimised software for installation
htop : Resource monitor
cpu : Shows CPU information and stats
That surprised me a bit because I had installed a cron job running a script on that machine that was supposed to send me a Gotify notiifcation in case a reboot is required:
if [ -f /var/run/reboot-required ]; then
curl -X POST "https://gotify.example.com/message?token=[REDACTED]" -F "title=Reboot required" -F "message=A reboot is required following updates to server `hostname -f` for packages: $(cat /var/run/reboot-required.pkgs)"
This script has worked for me in the past on several other servers with Ubuntu, Debian or Armbian. But for this DietPi machine I have not received any Gotify notification. It seems that on DietPi there’s no /var/run/reboot-required generated after kernel upgrade? At least I was not able to find it. Is it maybe in a different location?
So, basically, I’m just looking for a “trigger” on DietPi that I can use in a script to notify me about a reboot being due. If /var/run/reboot-required is not available, is there anything else I can use? Thanks in advance for your help.
First of all, do you have automatic APT upgrades enabled?
Secondly, the creation of /run/reboot-required is not a strictly defined standard. It is probably done by kernel packages on Ubuntu and probably even the default Debian kernels, but obviously not by the Armbian kernel packages, and I’ve never seen this for RPi kernel either, not to mention other possible SBC vendor kernel packages etc.
So this is not the way our login banner works. Instead, it checks whether modules for the currently loaded kernel exist. This is usually not the case after kernel upgrades, if the old kernel package has been removed or was replaced by the new one. The system is then not able to load kernel packages until reboot, which can cause several issues. I’m not aware of any other reason to do a system reboot after package upgrades, to be true. So your script could instead do something like this:
[ -d "/lib/modules/$(uname -r)" ] || curl -X POST 'https://gotify.example.com/message?token=[REDACTED]' -F 'title=Reboot required' -F "message=A reboot is required following updates to server $(hostname) to apply a kernel upgrade: $(ls -l /lib/modules)"
The only thing I’m a little bit worried about - the script does not exit to the prompt. I need to press Ctrl+C to get back to the bash prompt. I must admit - I’m a total noob regarding bash scripting, so I don’t know whether this behaviour makes any difference or not when I run the script as a cron job.
/var/run is deprecated an a symlink to /run, so /var/run/reboot-required is actually /run/reboot-required if this is what you mean. However, kernel packages (and others) can use this, or do not.
This has nothing to do with DietPi but with the APT packages, most importantly the kernel packages used, which we do not control/maintain. The Ubuntu kernel packages seems to create this file on upgrade, the Armbian kernel packages do obviously not. The systemd package may still create it, even that one can simply run systemctl daemon-reexec if for some reason one wants to have the new version running immediately. However, it doesn’t make sense to trust in this file being created as we basically know the only relevant reason to do a reboot after automated package upgrades and can check for that more explicitly.
Hmm, was it the same before? I’ve not so much experience with these POST form fields and also how Gotify is handling it, how long it takes to send a reply and terminate the connection. Probably check back with the docs and text on console. Would be bad if idle cron jobs would stack up because of this, or even open connections waiting forever (or a timeout?).
Yes, with the old script, it went back to the terminal prompt automatically.
But anyhow, I’ve tested your new script now for several days (both in reboot required and normal condition) and it seems to work just fine without any negative side effects.