-----Original Message-----
From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On
Behalf Of Mailing List
Sent: Monday, April 25, 2011 13:57
To: CentOS mailing list
Subject: Re: [CentOS] CentOs 5.6 and Time Sync
From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On
Behalf Of Mailing List
Sent: Monday, April 25, 2011 13:57
To: CentOS mailing list
Subject: Re: [CentOS] CentOs 5.6 and Time Sync
On 4/13/2011 7:35 AM, Mailing List wrote:
Hi,
I have upgraded my Dell C521 to the latest 5.6. I have always used
ntp to sync this machine and then the rest of the machines in the
network would sync from it. Since the update I cannot keep the right
time on the machine. This is with / without ntp. I have attempted
various scenario's with no luck. I am now trying the old kernel now
Hi,
I have upgraded my Dell C521 to the latest 5.6. I have always used
ntp to sync this machine and then the rest of the machines in the
network would sync from it. Since the update I cannot keep the right
time on the machine. This is with / without ntp. I have attempted
various scenario's with no luck. I am now trying the old kernel now
AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
3gb of ram.
TIA.
Brian.
3gb of ram.
TIA.
Brian.
List,
I was not able to resolve my issue with the time on this machine.
I
went ahead and rolled the update back to 5.5 and disabled the update to
5.6.
What I would like to know is if CentOS 6 might be ok when it rolls
out, or am I just going to have to keep with 5.5 till EOL?
Thanks to all with there help.
working for you kernel from 5.5, not the whole distribution.
2) If I was in your position and had time, my method would be[1]
a) get the srpm for the last known working kernel (2.6.18-194.32 ???)
b) get the srpm for the first known not working kernel (2.6.18-238 ???)
c) expand each of the above srpms into their own rpm build tree
i.e., rpmdev-setuptree;rpm -i kern1; mv rpmbuild rpmbuild.kern1;
rpmdev-setuptree;rpm -i kern2; mv rpmbuild rpmbuild.kern2
d) start looking at the differences in the patches applied in kern1 vs.
those in kern2, i.e., read/diff the kernel.spec files
see if there were any new ones that seemed likely to be causing the
problem...
RTFS if necessary to make better guesses.
Rebuild kernel 2 with patches taken out/modified based on my
investigations and test them and see if I guessed right.
If no luck, think about opening an TUV bug with lots of the info you
have sent here, they may be interested even if you don't have a
subscription.
[1] Been there, done that:
http://www.gossamer-threads.com/lists/drbd/users/9616
