I know my system clock is correct. I'm running debian in a VM and both the host system and the debian VM agree on the time, and it's the official time for my timezone (as per time.gov). But when I launch Tor, it won't build any chains because it says my clock is a few hours and some minutes behind (the time difference it gives is inconsistent, right now (10:46pm) it says that I'm 3 hours and 14 minutes behind the consensus, which is 2am GMT, and it seems to think that it is ALWAYS 2:00am GMT, or at least has been exactly that for the last half hour), and it won't work till I set the time ahead. Why does Tor only work when I tell it that it's in the future? This is for a system which will eventually be a livecd, and I need to make sure it works for any timezone that the disc is loaded in. What's more odd, is that on one of my systems, when I boot it up, it never has time problems and connects consistently.

Thanks for any help, much appreciated!

I went ahead and installed ntp on the vm, and that seems to fix it after being run for a few minutes. But unfortunately, this is meant for distribution on a livecd, and the last thing I want to do is muck up the user's hardware clock. Is there a way to prevent the ntp from changing the hardware clock?

The virtualisation software should (ha!) not propagate operations on the virtual hardware clock to the real hardware clock.

AFAIK the NTP programs do not set the hardware clock but it is done during shutdown, on Slackware 13.0 by the /etc/rc.d/rc.6 script which uses the /sbin/hwclock executable to do it. For belt-and-braces, in the VM's root file system, you could remove hwclock or replace it with /bin/true.

But what you report is strange; the usual advice is that VM's should not run NTP and should rely on the virtualisation software supplying data from the host's clock to the virtual hardware clock.

I'm only using the VM for development and testing, it will be deployed on live systems. Thanks for the good idea of replacing hwclock with true! I think that's what I'll do.

In case you ever do need hwclock, it might be prudent to rename it as hwclock.original and to make the change to true more obvious you could make hwclock a symbolic link to true.

EDIT: on reflection this is a workaround for something that is broken and could better be fixed in case it causes other trouble.