I've set up my Raspberry Pi from scratch with BerryBoot set up multiple OS's to boot into.

Whenever I boot into 'OpenELEC 2013.01', the time and date gets set correctly, but whenever I boot into 'Debian Wheezy Raspbian 2012.12', the time on the console is way off. The only 'hint' I get is that while booting, the RPi seems to spend a long time at the (last) point in the boot process, where the console says

[...] Starting NTP server: ntpd

which then changes to

[ ok ] Starting NTP server: ntpd

I have set the timezone and locales correctly with raspi-config for Raspbian, but the time is always around the last time I manually set with sudo date -s "2013-03-15 11:00.

Does anyone of you have a hint for help? It's really bothersome to manually set the time before I git-commit and push some code to my remote repository (and I often forget it, so that the repo is quite messed up).

  • I don't have an answer for you but you could make a script to update the time and then run the git commit. This would help in the short term at least. Mar 15 '13 at 12:35
  • That's what I've been trying to do, but ntpdate complains that it cannot find a suitable server for synchronization, even if I can ping ch.pool.ntp.org.
    – Habi
    Mar 15 '13 at 13:11

Make sure you have installed both fake-hwclock and ntp.

The purpose of fake-hwclock is to “Save/restore system clock on machines without working RTC hardware” (from the package description). On my system, it is triggered by a Cron script that runs hourly.

In contrast, ntp runs as a service to synchronize your RPi via the Network Time Protocol continuously. To make sure it is running, check it like this: service ntp status. It replaces the older ntpdate tool for most purposes.

On my system, these tools worked out of the box. I did not even have to install them separately. What I did though was to run rpi-update recently.

Considering your error messages, it seems more likely that you have a connectivity problem with the NTP server(s) specified in your /etc/ntp.conf. I have these entries:

server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst

You can check connectivity by pinging each of them like this: ping -c3 0.debian.pool.ntp.org. Feel free to use my server list instead of yours.

  • Thanks for the thourough answer, but this is all known and setup like this on my Pi: Both fake-hwclock and ntp are already at the newest version. service ntp status tells me that the NTP server is running. If I ping the servers in /etc/ntp.con, I get responses from them. I've got the same servers as you, but added ch.pool.ntp.org before it, since I'm in Switzerland. From what I see everything is correctly setup, but nonetheless I don't get the correct time. The only difference is that I don't run fake-hwclock hourly, but I don't think that's it. Or is it?
    – Habi
    Mar 18 '13 at 8:41
  • Have you searched /var/log/syslog or the output of dmesg for error messages mentioning ntp? You could also activate ntpd's log file by uncommenting the line #statsdir /var/log/ntpstats/ in /etc/ntp.conf. I believe ntpd refuses to synchronize time if local time deviates too much. In this case, you might have to synchronize time manually via ntpdate or date -s, then perhaps execute fake-hwclock save and see if everything is fine during the next boot process. Mar 19 '13 at 11:01
  • dmesg | grep ntp is empty, while grep ntp /var/log/syslog starts off with Mar 19 21:19:44 raspberrypi ntpdate[6329]: the NTP socket is in use, exiting just after (the presumed) boot time. It also tells me that ntp is exiting (Mar 19 21:22:10 raspberrypi ntpd[2107]: ntpd exiting on signal 15). Here's the full output: pastebin.com/pB0URjfY
    – Habi
    Mar 25 '13 at 10:25
  • Signal 15 is SIGTERM, the termination signal. Judging from the logfile, it seems that two services are competing for one port: ntpd and ntpdate. Try to avoid running ntpdate as a service. To remove it from all runlevels, you can type something like insserv -r ntpdate. Mar 26 '13 at 12:15

The pi does not have a hardware clock.

That's not a big deal in one sense, since computer systems usually keep time with software. They do this based on the frequency of the processor, which is pretty accurate. On a systems which do have a hardware clock (most desktops, laptops, etc -- this is why you may have a little battery on your motherboard), the base time of day is taken from the hardware clock at boot, and you can later check the extent to which the software clock has deviated from the hardware clock. It probably won't be noticeable.

However, it is a big deal in another sense, since without a hardware clock, the system cannot determine the initial time. Debian (and I presume openELEC) get it from a network source, which is the purpose of ntpd.

So it sounds like ntpd is unable to do this on your wheezy for some reason (the fact that the daemon starts OK does not indicate that it has made a connection). An obvious reason would be that ntpd cannot connect to an external server because, eg, it is being blocked by a firewall on your network.

  • I don't think that the firewall blocks external servers, since I boot into Raspbian and OpenELEC from the same location, here on my desk.
    – Habi
    Mar 15 '13 at 13:09
  • The norm for linux distros inc. debian is to not block anything, although the potential is built into the kernel and tools to configure such are included (qv. iptables). So if you haven't set something up explicitly and your router isn't blocking the pi that's not the issue. I have not looked into the details of how ntpd works, but that's whats responsible for setting the time on a debian pi. Although I don't use openELEC, I'd presume it uses ntpd too, so this is a subtle problem.
    – goldilocks
    Mar 15 '13 at 15:53

I seem to have found an answer. Strangely, while booting into Raspbian, the network here at work seems to block outgoing calls to any timeservers, so I have to use the internal ones, which I just added to /etc/ntp.conf.

The reason why it works on OpenELEC but not on Raspbian still baffles me, but it seems that OpenELEC circumvents the block somehow.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.