# Dietpi-banner does not display 'update available' messages

**URL:** <https://dietpi.com/forum/t/dietpi-banner-does-not-display-update-available-messages/25360>\
**Category:** Troubleshooting\
**Tags:** raspberry-pi-4\
**Created:** [26 July 2026 19:56 UTC](https://dietpi.com/forum/t/dietpi-banner-does-not-display-update-available-messages/25360 "2026-07-26T19:56:36Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![raph82](https://dietpi.com/forum/user_avatar/dietpi.com/raph82/32/8259_2.png) [@raph82](https://dietpi.com/forum/u/raph82)\
**Post date:** [26 July 2026 19:56 UTC](https://dietpi.com/forum/t/dietpi-banner-does-not-display-update-available-messages/25360/1 "2026-07-26T19:56:36Z")

</div>

### Creating a bug report/issue

I have searched the existing open and closed issues

#### Required Information

- DietPi version | `cat /boot/dietpi/.version`

G\_DIETPI\_VERSION\_CORE=10  
G\_DIETPI\_VERSION\_SUB=0  
G\_DIETPI\_VERSION\_RC=1  
G\_GITBRANCH=‘master’  
G\_GITOWNER=‘MichaIng’

- Distro version | `bookworm 0`
- 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

1. 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

---

<div class="post-metadata">

**Author:** ![MichaIng](https://dietpi.com/forum/user_avatar/dietpi.com/michaing/32/7_2.png) [@MichaIng](https://dietpi.com/forum/u/MichaIng)\
**Post date:** [26 July 2026 21:14 UTC](https://dietpi.com/forum/t/dietpi-banner-does-not-display-update-available-messages/25360/2 "2026-07-26T21:14:03Z")

</div>

This an explicit update check enable the banner notification?

```sh
dietpi-update 2
dietpi-banner 1

```

---

<div class="post-metadata">

**Author:** ![raph82](https://dietpi.com/forum/user_avatar/dietpi.com/raph82/32/8259_2.png) [@raph82](https://dietpi.com/forum/u/raph82)\
**Post date:** [27 July 2026 07:41 UTC](https://dietpi.com/forum/t/dietpi-banner-does-not-display-update-available-messages/25360/3 "2026-07-27T07:41:16Z")

</div>

Yes!

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:

- [System Maintenance - DietPi.com Docs](https://dietpi.com/docs/dietpi_tools/system_maintenance/#dietpi-update)
- [System Configuration - DietPi.com Docs](https://dietpi.com/docs/dietpi_tools/system_configuration/#dietpi-banner)

These tools get better the more I know about them 😉

Thank you!

---

<div class="post-metadata">

**Author:** ![MichaIng](https://dietpi.com/forum/user_avatar/dietpi.com/michaing/32/7_2.png) [@MichaIng](https://dietpi.com/forum/u/MichaIng)\
**Post date:** [27 July 2026 20:09 UTC](https://dietpi.com/forum/t/dietpi-banner-does-not-display-update-available-messages/25360/4 "2026-07-27T20:09:21Z")

</div>

Is the automatic DietPi update check enabled?

```sh
grep CONFIG_CHECK_DIETPI_UPDATES /boot/dietpi.txt

```

The flag is at `/run/dietpi/.update_available` in the `/run` tmpfs, hence it is lost on reboot. But it should check for an update at boot.

---

<div class="post-metadata">

**Author:** ![raph82](https://dietpi.com/forum/user_avatar/dietpi.com/raph82/32/8259_2.png) [@raph82](https://dietpi.com/forum/u/raph82)\
**Post date:** [28 July 2026 20:23 UTC](https://dietpi.com/forum/t/dietpi-banner-does-not-display-update-available-messages/25360/5 "2026-07-28T20:23:23Z")

</div>

Yes it is:

```auto
# grep CONFIG_CHECK_DIETPI_UPDATES /boot/dietpi.txt
CONFIG_CHECK_DIETPI_UPDATES=1

```

Is the next step to check the logs for error during the boot update check?

Sorry for the lack of formatting, I’m replying by email as I can’t login on the forum with the GitHub connector.  
Thanks again and have a good day!

---

<div class="post-metadata">

**Author:** ![MichaIng](https://dietpi.com/forum/user_avatar/dietpi.com/michaing/32/7_2.png) [@MichaIng](https://dietpi.com/forum/u/MichaIng)\
**Post date:** [28 July 2026 22:05 UTC](https://dietpi.com/forum/t/dietpi-banner-does-not-display-update-available-messages/25360/6 "2026-07-28T22:05:29Z")

</div>

Right, first of all check whether the postboot service did run successfully:

```sh
sudo systemctl status dietpi-postboot

```

It logs/outputs to local console only, and the update check output in particular is hidden, so you need to unhide it:

```sh
sudo sed -i 's| > /dev/null 2>&1||' /boot/dietpi/postboot

```

On next boot, you should see its output on the console, after the pre-login banner.

And since I guess network and/or network time sync takes too long, we can check this directly:

```sh
sudo journalctl -u dietpi-postboot -u systemd-timesyncd -u ifup@eth0

```

---

<div class="post-metadata">

**Author:** ![raph82](https://dietpi.com/forum/user_avatar/dietpi.com/raph82/32/8259_2.png) [@raph82](https://dietpi.com/forum/u/raph82)\
**Post date:** [29 July 2026 21:27 UTC](https://dietpi.com/forum/t/dietpi-banner-does-not-display-update-available-messages/25360/7 "2026-07-29T21:27:55Z")

</div>

I ran the 3 commands:

```auto
#systemctl status dietpi-postboot

● dietpi-postboot.service - DietPi-PostBoot
Loaded: loaded (/etc/systemd/system/dietpi-postboot.service; enabled; preset: enabled)
Drop-In: /etc/systemd/system/dietpi-postboot.service.d
└─dietpi.conf
Active: active (exited) since Tue 2026-07-28 23:33:31 CEST; 23h ago
Process: 730 ExecStart=/boot/dietpi/postboot (code=exited, status=0/SUCCESS)
Main PID: 730 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 3935)
CPU: 9.377s
CGroup: /system.slice/dietpi-postboot.service

juil. 28 23:33:31 DietPi systemd[1]: Started dietpi-postboot.service - DietPi-PostBoot.

```

Seems OK.

```auto
#sed -i 's| > /dev/null 2>&1||' /boot/dietpi/postboot

```

Did its job.

I also ran the third today for reference:

```auto
#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:

`juil. 28 23:42:33 DietPi pulseaudio[1617]: W: [pulseaudio] main.c: Unable to contact D-Bus: org.freedesktop.DBus.Err>`  
`juil. 29 11:36:51 DietPi systemd[1]: Starting dpkg-db-backup.service - Daily dpkg database backup service...`

I’ll continue the report tomorrow with the `dietpi-postboot` part of the log!

By the way, this system auto-logins to the console as root.

---

<div class="post-metadata">

**Author:** ![MichaIng](https://dietpi.com/forum/user_avatar/dietpi.com/michaing/32/7_2.png) [@MichaIng](https://dietpi.com/forum/u/MichaIng)\
**Post date:** [30 July 2026 12:25 UTC](https://dietpi.com/forum/t/dietpi-banner-does-not-display-update-available-messages/25360/8 "2026-07-30T12:25:44Z")

</div>

> [@raph82](#):
>
> ```auto
> 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.
> 
> ```

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).

---

<div class="post-metadata">

**Author:** ![raph82](https://dietpi.com/forum/user_avatar/dietpi.com/raph82/32/8259_2.png) [@raph82](https://dietpi.com/forum/u/raph82)\
**Post date:** [30 July 2026 19:00 UTC](https://dietpi.com/forum/t/dietpi-banner-does-not-display-update-available-messages/25360/9 "2026-07-30T19:00:09Z")

</div>

> [@MichaIng](#):
>
> 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.

Static IP over Ethernet, yes 😉

I think the LAN is up before the WAN by about a minute or so.

The new line in today’s log is:

```auto
juil. 29 23:32:47 DietPi systemd[1]: Started dietpi-postboot.service - DietPi-PostBoot.

```

Nothing else from PostBoot, so maybe the investigation should look this way?

Full log:

```auto
sudo journalctl -u dietpi-postboot -u systemd-timesyncd -u ifup@eth0
juil. 29 23:32:46 DietPi systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...
juil. 29 23:32:46 DietPi systemd[1]: Started systemd-timesyncd.service - Network Time Synchronization.
juil. 29 23:32:47 DietPi systemd[1]: Starting ifup@eth0.service - ifup for eth0...
juil. 29 23:32:47 DietPi systemd[1]: Finished ifup@eth0.service - ifup for eth0.
juil. 29 23:32:47 DietPi systemd[1]: Started dietpi-postboot.service - DietPi-PostBoot.
juil. 29 23:34:19 DietPi systemd[1]: Stopping systemd-timesyncd.service - Network Time Synchronization...
juil. 29 23:34:19 DietPi systemd[1]: systemd-timesyncd.service: Deactivated successfully.
juil. 29 23:34:19 DietPi systemd[1]: Stopped systemd-timesyncd.service - Network Time Synchronization.
juil. 30 12:17:02 DietPi systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...
juil. 30 12:17:02 DietPi systemd[1]: Started systemd-timesyncd.service - Network Time Synchronization.
juil. 30 12:17:02 DietPi systemd-timesyncd[4006]: Contacted time server 162.159.200.1:123 (0.debian.pool.ntp.org).
juil. 30 12:17:02 DietPi systemd-timesyncd[4006]: Initial clock synchronization to Thu 2026-07-30 12:17:02.237262 CEST.
juil. 30 12:17:03 DietPi systemd[1]: Stopping systemd-timesyncd.service - Network Time Synchronization...
juil. 30 12:17:03 DietPi systemd[1]: systemd-timesyncd.service: Deactivated successfully.
juil. 30 12:17:03 DietPi systemd[1]: Stopped systemd-timesyncd.service - Network Time Synchronization.
juil. 30 13:17:01 DietPi systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...
juil. 30 13:17:01 DietPi systemd[1]: Started systemd-timesyncd.service - Network Time Synchronization.
juil. 30 13:17:01 DietPi systemd-timesyncd[7250]: Contacted time server 162.159.200.1:123 (0.debian.pool.ntp.org).
juil. 30 13:17:01 DietPi systemd-timesyncd[7250]: Initial clock synchronization to Thu 2026-07-30 13:17:01.874643 CEST.
juil. 30 13:17:02 DietPi systemd[1]: Stopping systemd-timesyncd.service - Network Time Synchronization...
juil. 30 13:17:02 DietPi systemd[1]: systemd-timesyncd.service: Deactivated successfully.
juil. 30 13:17:02 DietPi systemd[1]: Stopped systemd-timesyncd.service - Network Time Synchronization.
juil. 30 14:17:01 DietPi systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...
juil. 30 14:17:01 DietPi systemd[1]: Started systemd-timesyncd.service - Network Time Synchronization.
juil. 30 14:17:01 DietPi systemd-timesyncd[10498]: Contacted time server 45.147.99.202:123 (0.debian.pool.ntp.org).
juil. 30 14:17:01 DietPi systemd-timesyncd[10498]: Initial clock synchronization to Thu 2026-07-30 14:17:01.489778 CEST.
juil. 30 14:17:02 DietPi systemd[1]: Stopping systemd-timesyncd.service - Network Time Synchronization...
juil. 30 14:17:02 DietPi systemd[1]: systemd-timesyncd.service: Deactivated successfully.
juil. 30 14:17:02 DietPi systemd[1]: Stopped systemd-timesyncd.service - Network Time Synchronization.
juil. 30 15:17:01 DietPi systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...
juil. 30 15:17:01 DietPi systemd[1]: Started systemd-timesyncd.service - Network Time Synchronization.
juil. 30 15:17:01 DietPi systemd-timesyncd[13819]: Contacted time server 82.66.40.79:123 (0.debian.pool.ntp.org).
juil. 30 15:17:01 DietPi systemd-timesyncd[13819]: Initial clock synchronization to Thu 2026-07-30 15:17:01.689734 CEST.
juil. 30 15:17:02 DietPi systemd[1]: Stopping systemd-timesyncd.service - Network Time Synchronization...
juil. 30 15:17:02 DietPi systemd[1]: systemd-timesyncd.service: Deactivated successfully.
juil. 30 15:17:02 DietPi systemd[1]: Stopped systemd-timesyncd.service - Network Time Synchronization.
juil. 30 16:17:01 DietPi systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...
juil. 30 16:17:01 DietPi systemd[1]: Started systemd-timesyncd.service - Network Time Synchronization.
juil. 30 16:17:02 DietPi systemd-timesyncd[17056]: Contacted time server 188.165.224.178:123 (0.debian.pool.ntp.org).
juil. 30 16:17:02 DietPi systemd-timesyncd[17056]: Initial clock synchronization to Thu 2026-07-30 16:17:02.308650 CEST.
juil. 30 16:17:03 DietPi systemd[1]: Stopping systemd-timesyncd.service - Network Time Synchronization...
juil. 30 16:17:03 DietPi systemd[1]: systemd-timesyncd.service: Deactivated successfully.
juil. 30 16:17:03 DietPi systemd[1]: Stopped systemd-timesyncd.service - Network Time Synchronization.
juil. 30 17:17:01 DietPi systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...
juil. 30 17:17:01 DietPi systemd[1]: Started systemd-timesyncd.service - Network Time Synchronization.
juil. 30 17:17:02 DietPi systemd-timesyncd[20285]: Contacted time server 161.97.71.210:123 (0.debian.pool.ntp.org).
juil. 30 17:17:02 DietPi systemd-timesyncd[20285]: Initial clock synchronization to Thu 2026-07-30 17:17:02.722378 CEST.
juil. 30 17:17:03 DietPi systemd[1]: Stopping systemd-timesyncd.service - Network Time Synchronization...
juil. 30 17:17:03 DietPi systemd[1]: systemd-timesyncd.service: Deactivated successfully.
juil. 30 17:17:03 DietPi systemd[1]: Stopped systemd-timesyncd.service - Network Time Synchronization.
juil. 30 18:17:01 DietPi systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...
juil. 30 18:17:01 DietPi systemd[1]: Started systemd-timesyncd.service - Network Time Synchronization.
juil. 30 18:17:02 DietPi systemd-timesyncd[23517]: Contacted time server 188.213.26.33:123 (0.debian.pool.ntp.org).
juil. 30 18:17:02 DietPi systemd-timesyncd[23517]: Initial clock synchronization to Thu 2026-07-30 18:17:02.955540 CEST.
juil. 30 18:17:03 DietPi systemd[1]: Stopping systemd-timesyncd.service - Network Time Synchronization...
juil. 30 18:17:03 DietPi systemd[1]: systemd-timesyncd.service: Deactivated successfully.
juil. 30 18:17:03 DietPi systemd[1]: Stopped systemd-timesyncd.service - Network Time Synchronization.
juil. 30 19:17:01 DietPi systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...

```

---

<div class="post-metadata">

**Author:** ![raph82](https://dietpi.com/forum/user_avatar/dietpi.com/raph82/32/8259_2.png) [@raph82](https://dietpi.com/forum/u/raph82)\
**Post date:** [31 July 2026 20:06 UTC](https://dietpi.com/forum/t/dietpi-banner-does-not-display-update-available-messages/25360/10 "2026-07-31T20:06:28Z")

</div>

> [@MichaIng](#):
>
> It logs/outputs to local console only

Oops, I overlooked that.

To make it easier to report, in /boot/dietpi/postboot, I changed a couple lines from

```auto
                        /boot/dietpi/dietpi-update 2 &
                else
                        /boot/dietpi/func/run_ntpd &

```

to

```auto
                        /boot/dietpi/dietpi-update 2 > /boot/dietpi/postboot.log 2>&1 &
                else
                        /boot/dietpi/func/run_ntpd > /boot/dietpi/postboot.log 2>&1 &

```

After an usual reboot (dietpi+internet box taking longer), local console output is:

```auto
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:

```auto
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:

```auto
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.

---

<div class="post-metadata">

**Author:** ![MichaIng](https://dietpi.com/forum/user_avatar/dietpi.com/michaing/32/7_2.png) [@MichaIng](https://dietpi.com/forum/u/MichaIng)\
**Post date:** [31 July 2026 20:52 UTC](https://dietpi.com/forum/t/dietpi-banner-does-not-display-update-available-messages/25360/11 "2026-07-31T20:52:37Z")

</div>

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.

> [@raph82](#):
>
> Still no update message.

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

```sh
dietpi-banner 1

```

If that does really not show the update notification, check whether the flag file exists:

```sh
cat /run/dietpi/.update_available

```

But that is quote hard tied to update check, and hardcoded in the banner as well.

---

<div class="post-metadata">

**Author:** ![raph82](https://dietpi.com/forum/user_avatar/dietpi.com/raph82/32/8259_2.png) [@raph82](https://dietpi.com/forum/u/raph82)\
**Post date:** [6 August 2026 20:38 UTC](https://dietpi.com/forum/t/dietpi-banner-does-not-display-update-available-messages/25360/12 "2026-08-06T20:38:15Z")

</div>

Please excuse the delay, I’ve been quite unavailable these last days.

> [@MichaIng](#):
>
> It is possible that you login before the update check finished. Try
> 
> ```auto
> dietpi-banner 1
> 
> ```
> 
> If that does really not show the update notification, check whether the flag file exists:
> 
> ```auto
> cat /run/dietpi/.update_available
> 
> ```

`dietpi-banner 1`, while the device is connected, does not display the update message.

```auto
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.

---

<div class="post-metadata">

**Author:** ![MichaIng](https://dietpi.com/forum/user_avatar/dietpi.com/michaing/32/7_2.png) [@MichaIng](https://dietpi.com/forum/u/MichaIng)\
**Post date:** [6 August 2026 23:08 UTC](https://dietpi.com/forum/t/dietpi-banner-does-not-display-update-available-messages/25360/13 "2026-08-06T23:08:55Z")

</div>

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”.

---

<div class="post-metadata">

**Author:** ![raph82](https://dietpi.com/forum/user_avatar/dietpi.com/raph82/32/8259_2.png) [@raph82](https://dietpi.com/forum/u/raph82)\
**Post date:** [17 August 2026 20:14 UTC](https://dietpi.com/forum/t/dietpi-banner-does-not-display-update-available-messages/25360/14 "2026-08-17T20:14:07Z")

</div>

> [@MichaIng](#):
>
> or when disabling “Boot wait for network”

I’ll try enabling this!

I found how to do it [in another post](https://dietpi.com/forum/t/boot-waiting-for-network/17940):

`dietpi-config` \> `Network Options: Misc` \> `Boot wait for network`

I was also tempted to tinker and move `.update_available` outside of `/run` so that it is preserved on reboot. I guess `/var/lib/dietpi/services/` would do?

---

<div class="post-metadata">

**Author:** ![MichaIng](https://dietpi.com/forum/user_avatar/dietpi.com/michaing/32/7_2.png) [@MichaIng](https://dietpi.com/forum/u/MichaIng)\
**Post date:** [17 August 2026 21:26 UTC](https://dietpi.com/forum/t/dietpi-banner-does-not-display-update-available-messages/25360/15 "2026-08-17T21:26:10Z")

</div>

> [@raph82](#):
>
> I was also tempted to tinker and move `.update_available` outside of `/run` so that it is preserved on reboot. I guess `/var/lib/dietpi/services/` would do?

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.

---

<div class="post-metadata">

**Author:** ![Falconcrest](https://dietpi.com/forum/user_avatar/dietpi.com/falconcrest/32/97_2.png) [@Falconcrest](https://dietpi.com/forum/u/Falconcrest)\
**Post date:** [21 August 2026 09:35 UTC](https://dietpi.com/forum/t/dietpi-banner-does-not-display-update-available-messages/25360/16 "2026-08-21T09:35:55Z")

</div>

Sorry, but I’d like to share my personal experience with this as well.

I can’t really explain it technically, but on various Raspberry Pi models—from the Zero, Zero 2, Pi 2, Pi 3, Pi 4, and Pi 5 all the way to the Nano Pi—I’ve noticed an effect (at least to me) where the Pi Banner doesn’t always show updates that are 100% certain to be available.

Often they do, but not always.

So I’ve gotten into the habit of running an `apt update` on the console after logging in, even if no updates are shown.

That way, I can definitely see whether there are updates or not.

Unfortunately, I can’t say exactly when this issue started for me, but I’ll go out on a limb and say it wasn’t always like this—or maybe I just didn’t notice it because I assumed it worked 100% of the time.

It might just be a problem on my end.

Because I’ve read something about `systemd-timesynd`…

I use `chrony` since I have two NTP servers on my LAN. But I’m sure that has nothing to do with it at all.

---

<div class="post-metadata">

**Author:** ![Joulinar](https://dietpi.com/forum/user_avatar/dietpi.com/joulinar/32/57_2.png) [@Joulinar](https://dietpi.com/forum/u/Joulinar)\
**Post date:** [21 August 2026 09:58 UTC](https://dietpi.com/forum/t/dietpi-banner-does-not-display-update-available-messages/25360/17 "2026-08-21T09:58:18Z")

</div>

Just to avoid any misunderstandings. The previous case concerned the display of DietPi updates after a reboot, not Debian apt packages.

As for the Debian apt packages, DietPi checks for them exactly once a day or after a reboot and saves the result. This is then displayed in the banner. This means that if new Debian apt packages were added between the nightly check and the user’s login, they will of course not be displayed.

What I’ve noticed is that security updates are now released almost every day. At this frequency, it’s entirely possible that there will be a mismatch between what’s displayed in the banner and the actual number of available packages after an `apt update`.

---

<div class="post-metadata">

**Author:** ![Falconcrest](https://dietpi.com/forum/user_avatar/dietpi.com/falconcrest/32/97_2.png) [@Falconcrest](https://dietpi.com/forum/u/Falconcrest)\
**Post date:** [21 August 2026 10:39 UTC](https://dietpi.com/forum/t/dietpi-banner-does-not-display-update-available-messages/25360/18 "2026-08-21T10:39:59Z")

</div>

You’re right, I should have read it more carefully.

Thanks for the correction; now I know how to proceed.  
👍

---

<div class="post-metadata">

**Author:** ![MichaIng](https://dietpi.com/forum/user_avatar/dietpi.com/michaing/32/7_2.png) [@MichaIng](https://dietpi.com/forum/u/MichaIng)\
**Post date:** [22 August 2026 17:27 UTC](https://dietpi.com/forum/t/dietpi-banner-does-not-display-update-available-messages/25360/19 "2026-08-22T17:27:12Z")

</div>

When using a custom time sync daemon, then the DietPi + APT update check skips the time sync check, hence may run into an error at boot, if chrony is not fast.

Same check as above (replacing `systemd-timesyncd` with `chrony` service, to see what is done when.

A possible solution that makes sense anyway ks to move the update check into an own service, which run after `time-sync.target`.

Of course this does not effect the daily update check# juat the one done at boot via `dietpi-postboot.service`.

---

<div class="post-metadata">

**Author:** ![Falconcrest](https://dietpi.com/forum/user_avatar/dietpi.com/falconcrest/32/97_2.png) [@Falconcrest](https://dietpi.com/forum/u/Falconcrest)\
**Post date:** [22 August 2026 20:10 UTC](https://dietpi.com/forum/t/dietpi-banner-does-not-display-update-available-messages/25360/20 "2026-08-22T20:10:46Z")

</div>

I’m not entirely sure, but whilst using Chrony, I’ve noticed on around 2–3 Pi that an error occurs when running `dietpi -update` after the first attempt. Running the command again resolves the issue. Curiously, however, this only happens on the approximately 5 per cent of my Pi’s that I’ve described.  
Unfortunately, I can’t provide any detailed information.  
At the moment, I see this as a ‘minor glitch’, so it’s hardly worth mentioning.  
That’s right, during the chrony installation, systemd-timesyncd is uninstalled.  
Otherwise, it works perfectly for me.

Could I set it up so that it checks for updates every time I log in via SSH, using `dietpi-update 2`?

[Next page](https://dietpi.com/forum/t/dietpi-banner-does-not-display-update-available-messages/25360.md?page=2)