The saga rolls on! I had lingering doubts about why this was broken, so I did more testing.
I gave the Pi2 a few reboots (many!) and have found that about 1 in 10 reboots, few different weird behaviours including:
1. Randomly reverting to the corrupt clock (say 1 in 10 reboots) possibly due to a race condition;
2. The clock is not being set early enough in the boot sequence so the 'magical' sydtemd has kittens: the system gets stuck in a weird state where it won't even boot but you can log in. Really weird! I've also seen it record timestamps etc and then show status of something starting 45 years ago because it expects the clock to be set before it starts. How cool is that?); and
3. The init sequence never finishes, so you can login but commands like reboot don't work. A 'sync' and hard power cycle is required.
I'm now suspecting that this can all be traced back to the following change:
"popcornmix commented on 11 Jan 2014 @maxnet So suggestion is to disable CONFIG_RTC_HCTOSYS? I have no evidence that it is required by anyone, so I could try that."
Combine that change with systemd now expecting the kernel to have set the clock from the RTC:
http://lists.freedesktop.org/archives/s ... 02526.html
http://mrpogson.com/2015/02/09/systemd- ... ur-poison/
I can confirm the latest kernel from rpi-update has this:
Code: Select all
root@quadpi:~# cat /proc/config.gz |gzip -d |grep CONFIG_RTC_HCTOSYS
# CONFIG_RTC_HCTOSYS is not set
I'm not sure that this can be loaded as a module or enabled by config; that was my first thought to try and address this easily.
So, in summary, someone whining about error messages on boot has got RTC support disabled and broken the 'normal' way for handing the hardware clock being set on boot.
I'm betting that the systemd hwclock stop script from above to set the clock on shutdown combined with making the kernel set the time from the RTC on boot (if it can) would make most of this go away?
I'm open to ideas, but having an unreliable clock for my logging and analysis application (which logs rainfall, temperature, off peak power switching and rainwater tank levels: all very time specific
) makes the Pi pretty useless, especially if repeated reboots can corrupt the clock (I presume that if it hasn't been set by the kernel or the script then writing 1/1/1970 back to it corrupts the clock registers and then they're screwed for the next reboot and clock fix).
@PhilE do you have any idea of a fix for this? There are enough people using Pis for embedded projects that aren't reliably internet connected that having a reliable working hardware clock would be a really nice thing, if not essential. Compiling up a custom kernel to fix this for every release seems... ummm... painful.
Going to see if I can make it a bit more robust with some dependencies on the start, but it's one hell of an ugly bandaid!
[Edit: I still think I'm missing something here. Ideas? Anyone?
[Edit 2: I messed with the dependencies in systemd to no avail. Disabling ntpd stopped the clock corruption. I under the 'start' section of the ntpd start script I added a hwclock -s to force the hardware clock to be set before ntpd runs. No more corruption yet. So yeah, the kernel really should be setting the time during boot
More testing to come...]