[Bug] /var/lib/systemd/timesync/clock is a 0644 directory on fresh Trixie Lite install (Breaks offline time retention)

[zsonglorman]

Describe the bug

On a fresh, unmodified installation of the 2025-10-01 Trixie Lite 32-bit image, the system fails to retain its last known time across offline reboots.

This occurs because /var/lib/systemd/timesync/clock is mistakenly initialized as a directory with broken 0644 permissions, rather than a standard file. systemd-timesyncd expects a file and cannot properly read this directory's modification time on boot, causing the system to fallback to the September 2025 systemd build epoch.

Steps to reproduce

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. Power cycle the Pi without network access.
4. Run date. It will report Sept 2025 instead of the last known time.
5. Run stat /var/lib/systemd/timesync/clock.

Expected behaviour

/var/lib/systemd/timesync/clock should be a standard -rw-r--r-- file. systemd-timesyncd should read its mtime on boot to set the baseline clock.

Actual behaviour

The path is created as a directory with file permissions (0644), breaking functionality.

stat /var/lib/systemd/timesync/clock
  File: /var/lib/systemd/timesync/clock
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: 179,2   Inode: 33912       Links: 2
Access: (0644/drw-r--r--)  Uid: (  991/systemd-timesync)   Gid: (  991/systemd-timesync)
Access: 2026-06-02 22:58:59.744735940 +0100
Modify: 2026-06-02 22:58:59.744735940 +0100
Change: 2026-06-02 22:58:59.744735940 +0100
 Birth: 2025-10-01 01:16:14.068517602 +0100

System Info:

• Hardware: Raspberry Pi Zero 2W
• OS: Raspbian GNU/Linux 13 (trixie) 32-bit (2025-10-01), exact image: 2025-10-01-raspios-trixie-armhf-lite.img.xz
• Kernel: 6.12.47+rpt-rpi-v7
• systemd: 257 (257.8-1~deb13u2+rpi1-g094e686)

Questions:

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?

[XECDesign]

I think what you're seeing is this bug that was fixed shortly after the image you are using was released.

a46065d

It's meant to resolve itself when you update raspberrypi-sys-mods. Is that not what you're seeing?

RPi-Distro/raspberrypi-sys-mods@9dcf847

[zsonglorman]

Thanks, yes probably this is the issue that I was seeing, thank you for confirmation. I made the steps as seen in your linked commit to re-create the file, and now it works just fine.

[XECDesign]

May I ask why you're running an older image and not updating? Or did you update and the automatic fix didn't work? I am sure I would've tested it before pushing it out, so if it doesn't work, that would be surprising.

Heads up that running an out-of-date system may leave it vulnerable to attacks.

[zsonglorman]

May I ask why you're running an older image and not updating? Or did you update and the automatic fix didn't work? I am sure I would've tested it before pushing it out, so if it doesn't work, that would be surprising.

Heads up that running an out-of-date system may leave it vulnerable to attacks.

I appreciate your comment and the heads-up on the security risks.
To answer your question: I'm managing a fleet of 30 (and counting) RPi Zero 2Ws. They are placed in remote, physically inaccessible locations, and I configure them entirely via Ansible over Tailscale.

Because these act as remote gateways, my primary goal is absolute operational stability. In the past, I've had automatic updates (specifically a bug shipped in a third-party networking package) which killed network access, taking several units completely offline until we could organize expensive physical site visits to re-flash them.

To prevent that, my current philosophy is to flash a specific base OS release, deploy my Ansible playbooks to freeze the configuration state, and disable all automatic updates. The main packages I use include tailscale, python, bluetooth, bluez.

To give you some context on why this specific time sync bug was such a headache: the power and network at these remote sites might get unstable from time to time (e.g., router power loss or WiFi drops). Even when offline, the Pis must continue operating locally via BLE. However, when the system time defaults back to 2025 after a brief power cycle, both Tailscale and SSL certificates fail to validate. This prevents them from securely reconnecting when the internet comes back, effectively locking me out of the systems.

That said, I am definitely struggling with the dilemma you mentioned: balancing this strict stability against the accumulation of security vulnerabilities. Since I'm treating these RPIs more as "embedded systems" than general-purpose Linux desktops, what is the Foundation's recommended best practice for fleet management? Should I be running controlled apt upgrade batches via Ansible on a monthly schedule (to avoid being vulnerable), or is there a better pattern that you'd recommend?

[XECDesign]

@tdewey-rpi May have some guidance here, since this is an area he's dealing with directly.

Raspberry Pi OS is more of a general purpose distribution, but we have rpi-image-gen which may be more suitable for your needs. If you limit the attack surface by only installing what you need and restrict access to only expose the services you need and you can be relatively safe even running older versions of packages. It may not be best practice, but a realistic compromise embedded applications have to make. We also have some tooling for OTA updates and A/B booting. Putting it all together, you should be able to get a much more reliable setup you can update and rollback as needed.