[CentOS] Problems after performing yum update

Sat Aug 26 15:09:45 UTC 2006
Robert <kerplop at sbcglobal.net>

Johnny Hughes wrote:

> Just for the record ... we had already taken action on that one to try
> and get a bug corrected upstream (pretty good for someone who "Doesn't
> know what is to give something back" ... sorry different thread :) :
>
> http://bugs.centos.org/view.php?id=1459
>
>   
Thanks for all you do!
If ->*A*<- Robert implied the negativism above, it wasn't me.

> No glitch in building, maybe a problem with the kernel and your
> hardware ... we always have a kernel and a kernel-smp.
>   
I've never been crazy about this m/b.  For openers, there's the Adaptec 
2940 card  whose  BIOS cannot be reached via <cntl-A> during POST, which 
could be a problem if the card did anything other than drive a scanner 
and a DAT drive.
> There is also a new ntp in those updates.
>   
Indeed. The behavior was so familiar that I tried the kernel first and 
got lucky. The new ntp works fine with the old kernel.
With 2.6.9-42.0.2.EL ntpd is clearly in trouble:

[root at mavis ~]# ntpq
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  
jitter
==============================================================================
  xxxxxxxxxxxxxx xxxxxxxxxxxxxx  16 u    -   64    0    0.000    0.000 
4000.00
  xxxxxxxxxxxxxx xxxxxxxxxxxxxx   1 u   42   64  177   66.814  -183.39 
2210.68
  xxxxxxxxxxxxxx xxxxxxxxxxxxxx   1 u   42   64  177   62.124  -3012.7 
1711.21
  xxxxxxxxxxxxxx xxxxxxxxxxxxxx   1 u   39   64  177   52.048  -1387.5 
1354.81
  xxxxxxxxxxxxxx xxxxxxxxxxxxxx   2 u   34   64  177   27.800  -814.06 
1739.73
  xxxxxxxxxxxxxx xxxxxxxxxxxxxx   2 u   38   64  177   43.541  -2526.2 
1372.69
  xxxxxxxxxxxxxx xxxxxxxxxxxxxx   2 u   37   64  177   21.179  -3646.6 
2201.41
  xxxxxxxxxxxxxx xxxxxxxxxxxxxx   2 u   32   64  177   55.460  -1441.6 
1360.43
*LOCAL(0)        LOCAL(0)        10 l   30   64  177    0.000    0.000   
0.004
ntpq> q
[root at mavis ~]# uptime
 09:00:07 up 9 min,  7 users,  load average: 0.02, 0.33, 0.24
[root at mavis ~]# uname -a
Linux mavis.localdomain 2.6.9-42.0.2.EL #1 Tue Aug 22 23:56:05 CDT 2006 
i686 athlon i386 GNU/Linux
[root at mavis ~]# rpm -q ntp
ntp-4.2.0.a.20040617-4.EL4.1
[root at mavis ~]#
                                                  
With 2.6.9-34.0.2.EL, ntp has congratulated itself <5 minutes :

ntpq> pe
     remote           refid      st t when poll reach   delay   offset  
jitter
==============================================================================
 xxxxxxxxxxxxxxx xxxxxxxxxxxxxx  16 u    -   64    0    0.000    0.000 
4000.00
 xxxxxxxxxxxxxxx xxxxxxxxxxxxxx  16 u    -   64    0    0.000    0.000 
4000.00
-xxxxxxxxxxxxxxx xxxxxxxxxxxxxx   1 u   17   64   17   68.750    3.182  
13.392
*xxxxxxxxxxxxxxx xxxxxxxxxxxxxx   1 u   18   64   17   61.884    1.768   
0.192
+xxxxxxxxxxxxxxx xxxxxxxxxxxxxx   1 u   16   64   17   52.622    1.312   
1.097
 xxxxxxxxxxxxxxx xxxxxxxxxxxxxx   2 u   16   64   17   29.031    5.313   
1.475
+xxxxxxxxxxxxxxx xxxxxxxxxxxxxx   2 u   17   64   17   42.836    2.494   
0.274
-xxxxxxxxxxxxxxx xxxxxxxxxxxxxx   2 u   12   64   17   21.412    4.334   
0.305
-xxxxxxxxxxxxxxx xxxxxxxxxxxxxx   2 u   16   64   17   55.781    0.205   
0.692
 LOCAL(0)        LOCAL(0)        10 l   12   64   17    0.000    0.000   
0.001
ntpq> q
[root at mavis ~]# uptime
 09:10:59 up 5 min,  7 users,  load average: 1.08, 0.96, 0.44
[root at mavis ~]# rpm -q ntp
ntp-4.2.0.a.20040617-4.EL4.1
[root at mavis ~]# uname -a
Linux mavis.localdomain 2.6.9-34.0.2.EL #1 Fri Jul 7 19:24:57 CDT 2006 
i686 athlon i386 GNU/Linux
[root at mavis 
~]#                                                             
>
>> Has anyone else seen this?
>>     
>
> I always run a ntpdate at startup against my time server then start the
> ntpd service.  I am using the new smp kernel and ntpd on 3 machines and
> it seems to be working. None of my machines are AMD though.
>   
I think I might try pulling that SCSI card in the next day or so just 
because this m/b BIOS wants to ignore it.


Thanks again to all who responded.