Hello everyone,
I have encountered a bug regarding offline time retention on a completely fresh, unmodified install of Raspberry Pi OS Lite 32-bit (Trixie).
Because my Pi Zero 2W lacks a hardware RTC and `fake-hwclock` is no longer installed by default, the system relies on `systemd-timesyncd` to read the modification time of `/var/lib/systemd/timesync/clock` to establish a baseline "epoch" time when booting offline.
However, on this specific OS image, this mechanism fails. The system boots to September 2025 (the systemd build date) instead of the last known synced time.
The Root Cause:
Upon investigation, `/var/lib/systemd/timesync/clock` is initialized as a directory instead of a file. Furthermore, it is created with broken `0644` permissions (directories require the executable bit to be traversable).
Here is the output from a completely fresh flash:
Because it is a directory, `systemd-timesyncd` cannot read or write to it properly on boot. While it does update the `mtime` of the directory when online, it fails to read it upon the next offline boot.
Reproduction Steps:
1. Flash `2025-10-01-raspios-trixie-armhf-lite.img.xz` using Raspberry Pi Imager.
2. Boot the Pi, connect to WiFi, and allow NTP to sync.
3. Unplug the Pi, disable your router/WiFi, and plug the Pi back in.
4. Run `date`. It will report Sept 2025 instead of the last known time.
5. Run `stat /var/lib/systemd/timesync/clock` to see the broken 0644 directory.
System Info:
1. Can anyone else reproduce this on the Trixie Lite image? Is it actually a bug?
2. Does anyone know which build script or package rule mistakenly created this path as a directory during the image creation?
3. To work around this safely, should I simply `rm -rf` the directory and `touch` it as a standard 0644 file?
Thank you!
I have encountered a bug regarding offline time retention on a completely fresh, unmodified install of Raspberry Pi OS Lite 32-bit (Trixie).
Because my Pi Zero 2W lacks a hardware RTC and `fake-hwclock` is no longer installed by default, the system relies on `systemd-timesyncd` to read the modification time of `/var/lib/systemd/timesync/clock` to establish a baseline "epoch" time when booting offline.
However, on this specific OS image, this mechanism fails. The system boots to September 2025 (the systemd build date) instead of the last known synced time.
The Root Cause:
Upon investigation, `/var/lib/systemd/timesync/clock` is initialized as a directory instead of a file. Furthermore, it is created with broken `0644` permissions (directories require the executable bit to be traversable).
Here is the output from a completely fresh flash:
Code:
stat /var/lib/systemd/timesync/clock File: /var/lib/systemd/timesync/clock Size: 4096 Blocks: 8 IO Block: 4096 directoryDevice: 179,2 Inode: 33912 Links: 2Access: (0644/drw-r--r--) Uid: ( 991/systemd-timesync) Gid: ( 991/systemd-timesync)Access: 2026-06-02 22:58:59.744735940 +0100Modify: 2026-06-02 22:58:59.744735940 +0100Change: 2026-06-02 22:58:59.744735940 +0100 Birth: 2025-10-01 01:16:14.068517602 +0100Reproduction Steps:
1. Flash `2025-10-01-raspios-trixie-armhf-lite.img.xz` using Raspberry Pi Imager.
2. Boot the Pi, connect to WiFi, and allow NTP to sync.
3. Unplug the Pi, disable your router/WiFi, and plug the Pi back in.
4. Run `date`. It will report Sept 2025 instead of the last known time.
5. Run `stat /var/lib/systemd/timesync/clock` to see the broken 0644 directory.
System Info:
- Hardware: Raspberry Pi Zero 2W
- OS: Raspbian GNU/Linux 13 (trixie) 32-bit (2025-10-01)
- Kernel: 6.12.47+rpt-rpi-v7
- systemd: 257 (257.8-1~deb13u2+rpi1-g094e686)
1. Can anyone else reproduce this on the Trixie Lite image? Is it actually a bug?
2. Does anyone know which build script or package rule mistakenly created this path as a directory during the image creation?
3. To work around this safely, should I simply `rm -rf` the directory and `touch` it as a standard 0644 file?
Thank you!
Statistics: Posted by zsonglorman — Tue Jun 02, 2026 10:25 pm
/fit-in/580x348/filters:format(webp)/english-betterindia/media/media_files/2026/08/04/4-2026-08-04-18-31-45.png)
/pic9729642.png)
