I’ve been cursing this error for at least a year or more, all the way back to my early days of rebuilding Arch kernels.
make: *** Warning: Clock skew detected. Your build may be incomplete.
Now it seems like I’ve found a way to shut it up. Judging by this and by a few other sources, this is all it takes to “fix” it.
find -exec touch \{\} \;
It works, although if you’re doing something like compiling a kernel, it will cause everything to need rebuilt, since it resets the timestamps on every file. A small price to pay for peace and quiet, if you ask me. …
Motho ke motho ka botho 
Why not just run an initscript like ntpdate to set the initial time at boot, then ntpd to keep your time constantly updated while your system is running?
Your hardware must be having serious issues if it’s getting that much clock skew while just compiling.
I might try that if the problem persists. Usually I try to avoid too many extras, but that might save me the trouble.
I should say though that these seem to crop up between booting into a live CD and chrooting into a system I’m troubleshooting, and when I boot directly into the system.
Of course this machine is so old it might be having hardware problems too. 😐
When you get multi-hour clock skew based on which OS you’re booting, that’s often a sign that one OS isn’t using the hardware clock, as timezones are coming into play.
Often, the hardware manufacturer sets the hardware clock to UTC, and the operating system can either use that — align itself to the UTC time — or it’s free to ignore it and go on “local” time. Local time is the time you set manually, either during installation or during normal desktop usage.
Machines that dual-boot Windows with Linux are famous for hitting this issue because Windows uses local time, while most Linuxes like using UTC. To avoid the issue, the Linux install has to be set to “local” in /etc/conf.d/clockor equivalent.
I notice this happening on my dual-boot Gentoo/Ubuntu laptop. I have my clock in Gentoo set to “local”, as I’m using the PST8PDT timezone. Ubuntu seems to be using something more UTC-like, like America/Los_Angeles, which is not the same TZ. Thus, whenever I go to Gentoo from Ubuntu, I’ve got disk errors and checking to do, as the OS thinks it’s now in the future. Etc.
Normally, just syncing up timezone and clock configs between environments should fix the issue. If software fails, perhaps you’ll have additional options in your BIOS? And if that fails, perhaps you do, indeed, have hardware issues. 🙂
Thanks, that was exceptionally educational and very helpful, actually. That might explain why this machine in particular always seems to have clock issues, particularly when I try to compile things.
If you get the chance, may I ask one more thing? I have noticed that occasionally, if I pick up an exceptionally fresh upload from another time zone and try to compile it, I get occasional errors of the same nature. Is that a possibility too? Can the times stamped from someone else’s source files trigger clock skew warnings on a machine in a different time zone? Perhaps I’m reaching, but I could swear one time that was the case.
That is indeed one possibility.
Or, if your built-in clock really is unstable (which is common in both very old and new machines; some x86-64 chipsets are famous for having crap timers), then it could be just wobbling all over the place rapidly, jumping many hours at a stretch. I’ve seen heavy CPU usage throw off the internal clock, too, which made me wonder just what timer was being used, for the CPU cycles to throw it off so much! Certain chipsets with buggy ACPI implementations can also throw off the timer, since the CPU speed shifts can do funny things to the cloc,.
You may want to take a look at your kernel configuration and see which timers or RTC you’re using — most computers have more than one. The kernel config options explain this a bit further in their help screens (press ?). If you have an HPET timer available, it’s often a good idea to use this, as it’s generally a very stable, high-resolution timer.