rak6502
October 23rd, 2008, 07:57 AM
Over the years, I have clock problems with various Linux distributions and a variety of hardware. I see this issue addressed many times with an answer that the CMOS battery should be replaced. This is not necessarily the problem, and since I just addressed this issue yet again, I'd like to help anyone out there who might be misled.
Here's the solution, which I've had to use on multiple distributions/versions/kernels and with various hardware; both AMD and Intel processors. This assumes you use grub (which is the default for Ubuntu)
Open /boot/grub/menu.lst and look for the kernel section, which looks something like this:
title Ubuntu, kernel 2.6.20-17-generic
root (hd0,0)
kernel /boot/vmlinuz-2.6.20-17-generic root=UUID=4a2fee06-6ef5-491d-8113-576b465998ed ro quiet splash
initrd /boot/initrd.img-2.6.20-17-generic
quiet
savedefault
On the end of the kernel line, I change it by adding clock=tsc, so the kernel line is now:
kernel /boot/vmlinuz-2.6.20-17-generic root=UUID=4a2fee06-6ef5-491d-8113-576b465998ed ro quiet splash clock=tsc
Save /boot/grub/menu.lst with this change, then reboot. No more clock problems.
I should also mention that if this doesn't work for you, here is another kernel line modification that has worked for me in the past:
kernel /boot/vmlinuz-2.6.20-17-generic root=UUID=4a2fee06-6ef5-491d-8113-576b465998ed ro quiet splash noapic nolapic
I believe that clock=tsc is a better option than noapic nolapic, but both have worked for me in every case.
The kernel line in the above examples are for my setup, your UUID will be different and your kernel might be different. The only change is the option(s) added to the end of the line.
More information:
When my clocks have drifted, I've experienced drifting ranging from 5 to 20 minutes per hour. It's good to get ntp running to constantly sync with a timeserver, but when you have too much drift, it seems that ntp cannot compensate. I've seen ntp offered as a solution, but it's only good once you fix the root problem. Once you implement this fix, ntp keeps things perfect.
It's important that I also mention that when a kernel is updated, /boot/grub/menu.lst is modified to reflect the new kernel. Because this line is modified, this change is lost, and must be put back in place. I'm sure somebody can chime in and mention a better way to do this, so the change is retained. I just haven't had the time to look into it.
Finally, I want to mention that I'm surprised that I've encountered this problem so often. Especially the most recent time, which was with a genuine Intel motherboard with a Core 2 Duo processor. I'm not sure why this issue isn't caught in testing and dealt with. Not complaining, just genuinely curious.
If anybody has anything to add that will help people, please feel free. It's been a frustrating issue to deal with, so I hope this is helpful to others.
Here's the solution, which I've had to use on multiple distributions/versions/kernels and with various hardware; both AMD and Intel processors. This assumes you use grub (which is the default for Ubuntu)
Open /boot/grub/menu.lst and look for the kernel section, which looks something like this:
title Ubuntu, kernel 2.6.20-17-generic
root (hd0,0)
kernel /boot/vmlinuz-2.6.20-17-generic root=UUID=4a2fee06-6ef5-491d-8113-576b465998ed ro quiet splash
initrd /boot/initrd.img-2.6.20-17-generic
quiet
savedefault
On the end of the kernel line, I change it by adding clock=tsc, so the kernel line is now:
kernel /boot/vmlinuz-2.6.20-17-generic root=UUID=4a2fee06-6ef5-491d-8113-576b465998ed ro quiet splash clock=tsc
Save /boot/grub/menu.lst with this change, then reboot. No more clock problems.
I should also mention that if this doesn't work for you, here is another kernel line modification that has worked for me in the past:
kernel /boot/vmlinuz-2.6.20-17-generic root=UUID=4a2fee06-6ef5-491d-8113-576b465998ed ro quiet splash noapic nolapic
I believe that clock=tsc is a better option than noapic nolapic, but both have worked for me in every case.
The kernel line in the above examples are for my setup, your UUID will be different and your kernel might be different. The only change is the option(s) added to the end of the line.
More information:
When my clocks have drifted, I've experienced drifting ranging from 5 to 20 minutes per hour. It's good to get ntp running to constantly sync with a timeserver, but when you have too much drift, it seems that ntp cannot compensate. I've seen ntp offered as a solution, but it's only good once you fix the root problem. Once you implement this fix, ntp keeps things perfect.
It's important that I also mention that when a kernel is updated, /boot/grub/menu.lst is modified to reflect the new kernel. Because this line is modified, this change is lost, and must be put back in place. I'm sure somebody can chime in and mention a better way to do this, so the change is retained. I just haven't had the time to look into it.
Finally, I want to mention that I'm surprised that I've encountered this problem so often. Especially the most recent time, which was with a genuine Intel motherboard with a Core 2 Duo processor. I'm not sure why this issue isn't caught in testing and dealt with. Not complaining, just genuinely curious.
If anybody has anything to add that will help people, please feel free. It's been a frustrating issue to deal with, so I hope this is helpful to others.