Goal:
To create a Stratum 1 NTP server on a Raspberry Pi 5 using the Adafruit Ultimate GPS Hat for time and PPS signals.
System:
Hardware: Raspberry Pi 5, new SanDisk microSD card, Adafruit Ultimate GPS Hat.
Operating System: A fresh installation of the official Raspberry Pi OS Lite (64-bit), fully updated as of June 19, 2025.
Final Confirmed Status:
After extensive configuration and troubleshooting, we achieved a state where all the underlying data sources were proven to be working perfectly:
GPS/NMEA Data: The gpsd service is running, and cgps -s confirms a stable 3D DGPS FIX. This proves the hardware, serial port (/dev/ttyAMA0), and gpsd daemon are all working correctly.
PPS Data: The pps-gpio driver is active, and sudo ppstest /dev/pps0 shows a perfect, once-per-second assert signal. This proves the hardware, GPIO wiring, and kernel PPS interface are working correctly.
The Final Failure:
Despite both the GPS (SOCK/SHM) and PPS data sources being verifiably active and correct, chrony remains unable to use them. sudo chronyc sources consistently shows:
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#? GPS 0 4 377 12 +421ms[+421ms] +/- 100ms
#? PPS 0 4 0 - +0ns[ +0ns] +/- 0ns
The PPS source always has a Reach of 0, indicating chrony cannot get a single sample from the working /dev/pps0 device.
Specific Failure Points Investigated:
Here is a summary of the specific OS-level issues we found and fixed, which still did not resolve the final chrony issue:
Permissions:
Problem: We discovered the /dev/pps0 device was created with default permissions of crw------- and ownership of root:root, making it impossible for the _chrony user to access.
Fix Applied: We created a udev rule (/etc/udev/rules.d/99-pps.rules) to set the group to dialout and mode to 0660. We also added the _chrony user to the dialout group using usermod. Our final audit confirmed these permissions are now set correctly, but chrony still fails.
Kernel:
Problem: We discovered the kernel was ignoring the dtoverlay=pps-gpio line in /boot/firmware/config.txt. The dmesg log showed the pps_core module loading but never the pps-gpio driver itself.
Workaround Applied: We had to manually force the driver to load by adding pps-gpio to /etc/modules. This workaround was successful and is the reason ppstest now works, but it highlights a fundamental issue with the OS's handling of device tree overlays.
AppArmor:
Problem: We suspected the AppArmor security sandbox was silently blocking chrony. Our investigation with sudo aa-status revealed that the apparmor filesystem is not mounted.
Conclusion: This indicates the entire AppArmor user-space system is in a broken or non-functional state on this fresh OS installation. While we put chrony into "complain mode," it's unclear if it's having any effect because the underlying AppArmor system is not healthy.
Summary for the Forum:
The core issue is that chrony is being blocked from a /dev/pps0 device that is provably working, correctly permissioned, and on a system where the AppArmor security has been set to be permissive. This points to a deep bug in chrony itself or its interaction with the kernel and security modules on this new version of Raspberry Pi OS.
zzashe@time-pi:~ $ sudo chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#? GPS 0 4 377 8 -118ms[ -118ms] +/- 101ms
#? PPS 0 4 0 - +0ns[ +0ns] +/- 0ns
To create a Stratum 1 NTP server on a Raspberry Pi 5 using the Adafruit Ultimate GPS Hat for time and PPS signals.
System:
Hardware: Raspberry Pi 5, new SanDisk microSD card, Adafruit Ultimate GPS Hat.
Operating System: A fresh installation of the official Raspberry Pi OS Lite (64-bit), fully updated as of June 19, 2025.
Final Confirmed Status:
After extensive configuration and troubleshooting, we achieved a state where all the underlying data sources were proven to be working perfectly:
GPS/NMEA Data: The gpsd service is running, and cgps -s confirms a stable 3D DGPS FIX. This proves the hardware, serial port (/dev/ttyAMA0), and gpsd daemon are all working correctly.
PPS Data: The pps-gpio driver is active, and sudo ppstest /dev/pps0 shows a perfect, once-per-second assert signal. This proves the hardware, GPIO wiring, and kernel PPS interface are working correctly.
The Final Failure:
Despite both the GPS (SOCK/SHM) and PPS data sources being verifiably active and correct, chrony remains unable to use them. sudo chronyc sources consistently shows:
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#? GPS 0 4 377 12 +421ms[+421ms] +/- 100ms
#? PPS 0 4 0 - +0ns[ +0ns] +/- 0ns
The PPS source always has a Reach of 0, indicating chrony cannot get a single sample from the working /dev/pps0 device.
Specific Failure Points Investigated:
Here is a summary of the specific OS-level issues we found and fixed, which still did not resolve the final chrony issue:
Permissions:
Problem: We discovered the /dev/pps0 device was created with default permissions of crw------- and ownership of root:root, making it impossible for the _chrony user to access.
Fix Applied: We created a udev rule (/etc/udev/rules.d/99-pps.rules) to set the group to dialout and mode to 0660. We also added the _chrony user to the dialout group using usermod. Our final audit confirmed these permissions are now set correctly, but chrony still fails.
Kernel:
Problem: We discovered the kernel was ignoring the dtoverlay=pps-gpio line in /boot/firmware/config.txt. The dmesg log showed the pps_core module loading but never the pps-gpio driver itself.
Workaround Applied: We had to manually force the driver to load by adding pps-gpio to /etc/modules. This workaround was successful and is the reason ppstest now works, but it highlights a fundamental issue with the OS's handling of device tree overlays.
AppArmor:
Problem: We suspected the AppArmor security sandbox was silently blocking chrony. Our investigation with sudo aa-status revealed that the apparmor filesystem is not mounted.
Conclusion: This indicates the entire AppArmor user-space system is in a broken or non-functional state on this fresh OS installation. While we put chrony into "complain mode," it's unclear if it's having any effect because the underlying AppArmor system is not healthy.
Summary for the Forum:
The core issue is that chrony is being blocked from a /dev/pps0 device that is provably working, correctly permissioned, and on a system where the AppArmor security has been set to be permissive. This points to a deep bug in chrony itself or its interaction with the kernel and security modules on this new version of Raspberry Pi OS.
zzashe@time-pi:~ $ sudo chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#? GPS 0 4 377 8 -118ms[ -118ms] +/- 101ms
#? PPS 0 4 0 - +0ns[ +0ns] +/- 0ns
Statistics: Posted by zzashe — Fri Jun 20, 2025 2:09 am