Kernel version | Linux DietPi 6.12.62+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.62-1+rpt1~bookworm (2026-01-19) aarch64 GNU/Linux
Architecture | arm64
SBC model | RPi 4 Model B (aarch64)
Power supply used | official Raspberry one
SD card used | (EG: SanDisk ultra)
Additional Information (if applicable)
Software title | dietpi-banner
Was the software title installed freshly or updated/migrated? No
Can this issue be replicated on a fresh installation of DietPi? Not tested
Bug report ID | none
Steps to reproduce
I don’t know!
Expected behaviour
dietpi-banner should display
DietPi vX.X.X : Update available
and
dietpi-update : Run now to update DietPi from vX.X.X to vY.Y.Y
when an update is available
Actual behaviour
dietpi-banner does not display the update lines
Extra details
it seems to me this is a low-priority but recurring issue. Usually around Christmas, I notice the device has not been updated for a long time. I then run dietpi-update and it works for months before eventually stopping displaying the update lines again
nowadays, the device is usually not connected to the internet when turned on (the internet box takes way longer to boot than the Pi4)
even when it is connected to the internet at boot (like on occasional reboots), the update lines are missing
manually running dietpi-banner and just validating has made the update lines appear one time, but they stopped appearing before I updated the system
I installed some software with apt today and now the update lines are displayed
I’m not expecting a fix but merely guidance as to what to check and report in the future, if the bug reproduce, with this bug report for reference
Yesterday the update notification in the banner was displayed but this morning it was not. (I turn off the device at night.) I thought it would be!
An explicit update check (the 2 commands in your message) made the update notification appear again. Let’s see if it still does tomorrow or if something else needs to be done…
You reply made me look for the documentation of dietpi-update and dietpi-banner that I found there:
#journalctl -u dietpi-postboot -u systemd-timesyncd -u ifup@eth0
juil. 28 23:33:30 DietPi systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...
juil. 28 23:33:30 DietPi systemd[1]: Started systemd-timesyncd.service - Network Time Synchronization.
juil. 28 23:33:31 DietPi systemd[1]: Starting ifup@eth0.service - ifup for eth0...
juil. 28 23:33:31 DietPi systemd[1]: Finished ifup@eth0.service - ifup for eth0.
juil. 28 23:33:31 DietPi systemd[1]: Started dietpi-postboot.service - DietPi-PostBoot.
juil. 28 23:35:06 DietPi systemd[1]: Stopping systemd-timesyncd.service - Network Time Synchronization...
juil. 28 23:35:06 DietPi systemd[1]: systemd-timesyncd.service: Deactivated successfully.
juil. 28 23:35:06 DietPi systemd[1]: Stopped systemd-timesyncd.service - Network Time Synchronization.
juil. 29 12:17:01 DietPi systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...
juil. 29 12:17:01 DietPi systemd[1]: Started systemd-timesyncd.service - Network Time Synchronization.
juil. 29 12:17:01 DietPi systemd-timesyncd[3860]: Contacted time server 5.39.80.51:123 (0.debian.pool.ntp.org).
juil. 29 12:17:01 DietPi systemd-timesyncd[3860]: Initial clock synchronization to Wed 2026-07-29 12:17:01.771560 CEST.
juil. 29 12:17:02 DietPi systemd[1]: Stopping systemd-timesyncd.service - Network Time Synchronization...
juil. 29 12:17:02 DietPi systemd[1]: systemd-timesyncd.service: Deactivated successfully.
juil. 29 12:17:02 DietPi systemd[1]: Stopped systemd-timesyncd.service - Network Time Synchronization.
juil. 29 13:17:01 DietPi systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...
juil. 29 13:17:02 DietPi systemd[1]: Started systemd-timesyncd.service - Network Time Synchronization.
juil. 29 13:17:02 DietPi systemd-timesyncd[7106]: Contacted time server 5.39.80.51:123 (0.debian.pool.ntp.org).
juil. 29 13:17:02 DietPi systemd-timesyncd[7106]: Initial clock synchronization to Wed 2026-07-29 13:17:02.026836 CEST.
juil. 29 13:17:03 DietPi systemd[1]: Stopping systemd-timesyncd.service - Network Time Synchronization...
juil. 29 13:17:03 DietPi systemd[1]: systemd-timesyncd.service: Deactivated successfully.
juil. 29 13:17:03 DietPi systemd[1]: Stopped systemd-timesyncd.service - Network Time Synchronization.
juil. 29 14:17:01 DietPi systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...
juil. 29 14:17:01 DietPi systemd[1]: Started systemd-timesyncd.service - Network Time Synchronization.
juil. 29 14:17:01 DietPi systemd-timesyncd[10350]: Contacted time server 82.64.81.218:123 (0.debian.pool.ntp.org).
juil. 29 14:17:01 DietPi systemd-timesyncd[10350]: Initial clock synchronization to Wed 2026-07-29 14:17:01.717309 CEST.
juil. 29 14:17:02 DietPi systemd[1]: Stopping systemd-timesyncd.service - Network Time Synchronization...
juil. 29 14:17:02 DietPi systemd[1]: systemd-timesyncd.service: Deactivated successfully.
juil. 29 14:17:02 DietPi systemd[1]: Stopped systemd-timesyncd.service - Network Time Synchronization.
juil. 29 15:17:01 DietPi systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...
juil. 29 15:17:02 DietPi systemd[1]: Started systemd-timesyncd.service - Network Time Synchronization.
juil. 29 15:17:01 DietPi systemd-timesyncd[13687]: Contacted time server 79.143.250.33:123 (0.debian.pool.ntp.org).
juil. 29 15:17:01 DietPi systemd-timesyncd[13687]: Initial clock synchronization to Wed 2026-07-29 15:17:01.628100 CEST.
juil. 29 15:17:02 DietPi systemd[1]: Stopping systemd-timesyncd.service - Network Time Synchronization...
juil. 29 15:17:02 DietPi systemd[1]: systemd-timesyncd.service: Deactivated successfully.
juil. 29 15:17:02 DietPi systemd[1]: Stopped systemd-timesyncd.service - Network Time Synchronization.
juil. 29 16:17:02 DietPi systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...
juil. 29 16:17:02 DietPi systemd[1]: Started systemd-timesyncd.service - Network Time Synchronization.
juil. 29 16:17:01 DietPi systemd-timesyncd[16920]: Contacted time server 82.64.173.137:123 (0.debian.pool.ntp.org).
juil. 29 16:17:01 DietPi systemd-timesyncd[16920]: Initial clock synchronization to Wed 2026-07-29 16:17:01.760269 CEST.
juil. 29 16:17:02 DietPi systemd[1]: Stopping systemd-timesyncd.service - Network Time Synchronization...
juil. 29 16:17:02 DietPi systemd[1]: systemd-timesyncd.service: Deactivated successfully.
juil. 29 16:17:02 DietPi systemd[1]: Stopped systemd-timesyncd.service - Network Time Synchronization.
juil. 29 17:17:01 DietPi systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...
juil. 29 17:17:01 DietPi systemd[1]: Started systemd-timesyncd.service - Network Time Synchronization.
juil. 29 17:17:00 DietPi systemd-timesyncd[20159]: Contacted time server 82.64.230.205:123 (0.debian.pool.ntp.org).
juil. 29 17:17:00 DietPi systemd-timesyncd[20159]: Initial clock synchronization to Wed 2026-07-29 17:17:00.820123 CEST.
juil. 29 17:17:01 DietPi systemd[1]: Stopping systemd-timesyncd.service - Network Time Synchronization...
juil. 29 17:17:01 DietPi systemd[1]: systemd-timesyncd.service: Deactivated successfully.
juil. 29 17:17:01 DietPi systemd[1]: Stopped systemd-timesyncd.service - Network Time Synchronization.
juil. 29 18:17:01 DietPi systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...
juil. 29 18:17:01 DietPi systemd[1]: Started systemd-timesyncd.service - Network Time Synchronization.
juil. 29 18:17:00 DietPi systemd-timesyncd[23395]: Contacted time server 51.77.92.168:123 (0.debian.pool.ntp.org).
juil. 29 18:17:00 DietPi systemd-timesyncd[23395]: Initial clock synchronization to Wed 2026-07-29 18:17:00.958011 CEST.
juil. 29 18:17:01 DietPi systemd[1]: Stopping systemd-timesyncd.service - Network Time Synchronization...
juil. 29 18:17:01 DietPi systemd[1]: systemd-timesyncd.service: Deactivated successfully.
juil. 29 18:17:01 DietPi systemd[1]: Stopped systemd-timesyncd.service - Network Time Synchronization.
juil. 29 19:17:01 DietPi systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...
I read the start of the full output of journalctl to confirm my guess: the time is wrong in the first lines of the above log. And etho0 link is up at ‘23:34:37’.
There’s no explicit failure of systemd-timesyncd at the first try, but only latter attempts report successful contact to the ntp server.
interestingly, the system time seems to have changed in the journalctl log outside of the systemd-timesyncd.service, between those 2 successive lines:
So indeed network time sync takes too long. When dietpi-postboot starts, it almost immediately starts the DietPi update check, which includes a time sync check. Practically, it waits for the /run/systemd/timesync/synchronized flag to appear, which signals that systemd-timesyncd finished its initial network time synchronization. But it has a timeout of 60 seconds. As can be seen from the log, there are >90 seconds between dietpi-postboot start and systemd-timesyncd stop, without the Initial clock synchronization line you see later in the hourly sync. Without that, HTTPS network requests often fail with “TLS certificate is not yet valid” errors, so does the check for a DietPi update. But we will see the true error of dietpi-update/dietpi-postboot.
Since there are no DHCP-related logs, I assume you use a static IP. That, and with Ethernet, network should be usable almost instantly after ifup@eth0 finished. But I see by times that, for some reason, systemd-timesyncd does not keep trying to synchronize at boot for a longer time. We should probably allow a longer timeout for the first sync at boot via MAX_LOOPS_CHECK environment variable (which exists already), or better a CLI option. Or do a systemd-timesyncd restart if the sync did not finish yet, as this forces an immediate sync attempt, AFAIK. The delay might be mostly coming from the fact that systemd-timesyncd gives up for a longer pause, if the first X sync attempts fail, as it starts before ifup@eth0 (expectedly, for pulling in the offline timestamp at /var/lib/systemd/timesync/clock early, when running in daemon mode).
After an usual reboot (dietpi+internet box taking longer), local console output is:
tail -f /boot/dietpi/postboot.log
E: Impossible de récupérer https://deb.debian.org/debian-security/dists/bookworm-security/InRelease Erreur temporaire de résolution de « deb.debian.org »
E: Impossible de récupérer https://deb.debian.org/debian/dists/bookworm-backports/InRelease Erreur temporaire de résolution de « deb.debian.org »
E: Impossible de récupérer https://dietpi.com/apt/dists/bookworm/InRelease Erreur temporaire de résolution de « dietpi.com »
E: Impossible de récupérer https://dietpi.com/apt/dists/all/InRelease Erreur temporaire de résolution de « dietpi.com »
E: Impossible de récupérer https://archive.raspberrypi.com/debian/dists/bookworm/InRelease Erreur temporaire de résolution de « archive.raspberrypi.com »
E: Le téléchargement de quelques fichiers d'index a échoué, ils ont été ignorés, ou les anciens ont été utilisés à la place.
[FAILED] DietPi-Update | APT update
- Command: apt-get -y -eany update
[FAILED] DietPi-Update | Unable to continue, DietPi-Update will now terminate.
[ INFO ] DietPi-Update | No APT upgrades were found, not creating file: /run/dietpi/.apt_updates
After a dietpi reboot only, with the fiber box staying on, local console output is:
try #1:
tail -f /boot/dietpi/postboot.log
[ OK ] DietPi-TimeSync | Time sync completed
[ .... ] DietPi-TimeSync | systemctl stop systemd-timesyncd
[ OK ] DietPi-TimeSync | systemctl stop systemd-timesyncd
[ .... ] DietPi-TimeSync | mkdir -p /run/systemd/timesync
[ OK ] DietPi-TimeSync | mkdir -p /run/systemd/timesync
[ INFO ] DietPi-Update | Getting latest version from: https://raw.githubusercontent.com/MichaIng/DietPi/master/.update/version
[ OK ] DietPi-Update | Got valid latest version: 10.5.2
[ OK ] DietPi-Update | Update available:
[ INFO ] DietPi-Update | Current version : v10.0.1
[ INFO ] DietPi-Update | Latest version : v10.5.2
try #2:
tail -f /boot/dietpi/postboot.log
[ .... ] DietPi-Update | Checking IPv6 network connectivity (2/2)
[ OK ] DietPi-Update | Checking IPv6 network connectivity
[ .... ] DietPi-Update | Checking DNS resolver (1/2)
[ OK ] DietPi-Update | Checking DNS resolver
[ .... ] DietPi-TimeSync | systemctl start systemd-timesyncd
[ OK ] DietPi-TimeSync | systemctl start systemd-timesyncd
[ INFO ] DietPi-TimeSync | Waiting for time sync (1/60)
[ INFO ] DietPi-TimeSync | Waiting for time sync (2/60)
[ INFO ] DietPi-TimeSync | Waiting for time sync (3/60)
[ INFO ] DietPi-TimeSync | Waiting for time sync (4/60)
[ INFO ] DietPi-TimeSync | Waiting for time sync (5/60)
[ INFO ] DietPi-TimeSync | Waiting for time sync (6/60)
[ INFO ] DietPi-TimeSync | Waiting for time sync (7/60)
[ INFO ] DietPi-TimeSync | Waiting for time sync (8/60)
[ INFO ] DietPi-TimeSync | Waiting for time sync (9/60)
[ INFO ] DietPi-TimeSync | Waiting for time sync (10/60)
[ INFO ] DietPi-TimeSync | Waiting for time sync (11/60)
[ INFO ] DietPi-TimeSync | Waiting for time sync (12/60)
[ INFO ] DietPi-TimeSync | Waiting for time sync (13/60)
[ INFO ] DietPi-TimeSync | Waiting for time sync (14/60)
[ OK ] DietPi-TimeSync | Time sync completed
[ .... ] DietPi-TimeSync | systemctl stop systemd-timesyncd
[ OK ] DietPi-TimeSync | systemctl stop systemd-timesyncd
[ .... ] DietPi-TimeSync | mkdir -p /run/systemd/timesync
[ OK ] DietPi-TimeSync | mkdir -p /run/systemd/timesync
[ INFO ] DietPi-Update | Getting latest version from: https://raw.githubusercontent.com/MichaIng/DietPi/master/.update/version
[ OK ] DietPi-Update | Got valid latest version: 10.5.2
[ OK ] DietPi-Update | Update available:
[ INFO ] DietPi-Update | Current version : v10.0.1
[ INFO ] DietPi-Update | Latest version : v10.5.2
Still no update message. The cause seems larger than ‘boots without internet access’, but I don’t know where to go from here. Something happens, or rather does not happen, between when dietpi-update detects an update is available and when dietpi-banner runs, failing to display the update available messages.
So the issue happens if you boot the router/modem along with the RPi? That would make a lot of sense, since those boxes usually take a lot longer before providing Internet access. As you use a static IP, you also do not see in logs if/whether it responds to DHCP requests, or sends RAs already or not, so things look all fine, while Internet access is still down.
And booting the box earlier solves it, that is good.
v10.5.2 was detected correctly, so a message should be shown after this was done. It is possible that you login before the update check finished. Try
dietpi-banner 1
If that does really not show the update notification, check whether the flag file exists:
cat /run/dietpi/.update_available
But that is quote hard tied to update check, and hardcoded in the banner as well.
Please excuse the delay, I’ve been quite unavailable these last days.
dietpi-banner 1, while the device is connected, does not display the update message.
cat /run/dietpi/.update_available
cat: /run/dietpi/.update_available: Aucun fichier ou dossier de ce type
No file found by cat.
The device AutoStart option is 7 “Automatic login to local terminal”. So yes, the login is probably done before the update check is finished.
I was expecting the ‘update available’ to be set later if it fails to be set at boot. But even when it is manually, it isn’t preserved after reboot. Is there cases where it makes sense to reset this flag when no update has been applied? Maybe when an update is no longer available, if that happens?
I’ve run dietpi-update 2 then dietpi-banner 1 and cat /run/dietpi/.update_available. Update detected and advertised. Then I reboot, the system autologins, no ‘update available’ notification, yet cat /run/dietpi/.update_available still returns 10.5.2. Maybe dietpi-banner ran while dietpi-update was checking for updates?
What could be done about it, if it merits being changed?
I’m tempted to comment out the rm /run/dietpi/.update_available line in /boot/dietpi/dietpi-update / Check_DietPi_Update() and see what happens.
Okay, so you are just logging in before the update check went through.
dietpi-update does not remove /run/dietpi/.update_available, unless an update has just been completed, or an update check returned that no update is available.
The issue is that /run is a tmpfs (RAM disk), hence that flag is naturally lost after reboot. Since a new update check is done on boot anyway, this is usually not an issue. But for fast autologin, indeed you do not see the result of the update check yet. Similarly, fetching the MOTD can fail in this situation, depending on how fast e.g. WiFi authentication and/or DHCP lease happens, or when disabling “Boot wait for network”.
Yes /var is not a tmpfs. But manually copying that file back and forth every reboot does not seem a sane solution. You could check journalctl logs to see where network setup starts, and finishes, where systemd-timesyncd syncs with network time, and where dietpi-postboost.service starts, to check which part takes too long. If it is the network time sync, while network is fully configured already, I have already an idea how to address that.
