Clock skew detected

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. …

About these ads

5 Responses to “Clock skew detected”


  1. 1 nightmorph 2009/01/17 at 2:25 PM

    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.

  2. 2 K.Mandla 2009/01/17 at 8:41 PM

    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. :|

  3. 3 nightmorph 2009/01/21 at 7:25 PM

    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. :)

    • 4 K.Mandla 2009/01/22 at 10:13 AM

      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.

  4. 5 nightmorph 2009/01/22 at 4:28 PM

    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.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




Welcome!



Visit the Wiki!

Some recent desktops


May 6, 2011
Musca 0.9.24 on Crux Linux
150Mhz Pentium 96Mb 8Gb CF
 


May 14, 2011
IceWM 1.2.37 and Arch Linux
L2300 core duo 3Gb 320Gb

Some recent games


Apr. 21, 2011
Oolite on Xubuntu 11.04
L2300 core duo 3Gb 320Gb

Enter your email address to subscribe to this blog and receive notifications of new posts.

Join 405 other followers

License

This work is licensed under the GNU Free Documentation License. Please see the About page for details.

Blog Stats

  • 3,961,275 hits

Archives


Follow

Get every new post delivered to your Inbox.

Join 405 other followers

%d bloggers like this: