I performed the update yesterday that included installing kernel 2.6.9-42.0.2.EL and replacing ethereal with wireshark. First, the trivial... Wireshark would not run from the KDE menu without editing the menu to change the command from "wireshark" to "kdesu wireshark" because dumpcap is at usr/sbin/dumpcap instead of /usr/bin/dumpcap . Making the change causes wireshark to open root password dialog like ethereal, which it replaced. (And which makes sense.) Now, the puzzling. This is an AMD Athlon XP 2600+ on an ASUS A7N8X deluxe ver 2.0 m/b. The symptom is that ntpd refuses to sync. Dropping back to kernel 2.6.9-34.0.2.EL restores ntpd to proper operation. My first thought was that the smp code must have been incorporated in the non-smp kernel because the system mis-behaves exactly as it has in the past when Anaconda mistakenly installed the smp kernel. What clouds the picture is that when I checked the updates repository, I found both http://isoredirect.centos.org/centos/4/updates/i386/RPMS/kernel-smp-2.6.9-42.0.2.EL.i686.rpm and http://isoredirect.centos.org/centos/4/updates/i386/RPMS/kernel-2.6.9-42.0.2.EL.i686.rpm which then made me wonder if there was a glitch in the build process. Has anyone else seen this?
> -----Original Message----- > From: centos-bounces at centos.org > [mailto:centos-bounces at centos.org] On Behalf Of Robert > Sent: Friday, August 25, 2006 9:41 PM > To: CentOS mailing list > Subject: [CentOS] Problems after performing yum update > > I performed the update yesterday that included installing > kernel 2.6.9-42.0.2.EL and replacing ethereal with wireshark. > First, the trivial... > Wireshark would not run from the KDE menu without editing the > menu to change the command from "wireshark" to "kdesu > wireshark" because dumpcap is at usr/sbin/dumpcap instead of > /usr/bin/dumpcap . Making the change causes wireshark to open > root password dialog like ethereal, which it replaced. (And > which makes sense.) > > Now, the puzzling. This is an AMD Athlon XP 2600+ on an ASUS > A7N8X deluxe ver 2.0 m/b. The symptom is that ntpd refuses > to sync. Dropping back to kernel 2.6.9-34.0.2.EL restores > ntpd to proper operation. My first thought was that the smp > code must have been incorporated in the non-smp kernel > because the system mis-behaves exactly as it has in the past > when Anaconda mistakenly installed the smp kernel. What > clouds the picture is that when I checked the updates > repository, I found both > http://isoredirect.centos.org/centos/4/updates/i386/RPMS/kerne > l-smp-2.6.9-42.0.2.EL.i686.rpm > and > http://isoredirect.centos.org/centos/4/updates/i386/RPMS/kerne > l-2.6.9-42.0.2.EL.i686.rpm > which then made me wonder if there was a glitch in the build process. > > Has anyone else seen this?I am unable to run the 'new' kernel also. My system locks up in about 10 minutes. My box is an IBM NetVista, Intel 2.4 Ghz, 1GB RAM. Haven't had time to look at the cause. Eddie
On Fri, 2006-08-25 at 20:40 -0500, Robert wrote:> I performed the update yesterday that included installing kernel > 2.6.9-42.0.2.EL and replacing ethereal with wireshark. > First, the trivial... > Wireshark would not run from the KDE menu without editing the menu to > change the command from "wireshark" to "kdesu wireshark" because dumpcap > is at usr/sbin/dumpcap instead of /usr/bin/dumpcap . Making the change > causes wireshark to open root password dialog like ethereal, which it > replaced. (And which makes sense.)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> > Now, the puzzling. This is an AMD Athlon XP 2600+ on an ASUS A7N8X > deluxe ver 2.0 m/b. The symptom is that ntpd refuses to sync. Dropping > back to kernel 2.6.9-34.0.2.EL restores ntpd to proper operation. My > first thought was that the smp code must have been incorporated in the > non-smp kernel because the system mis-behaves exactly as it has in the > past when Anaconda mistakenly installed the smp kernel. What clouds the > picture is that when I checked the updates repository, I found both > http://isoredirect.centos.org/centos/4/updates/i386/RPMS/kernel-smp-2.6.9-42.0.2.EL.i686.rpm > and > http://isoredirect.centos.org/centos/4/updates/i386/RPMS/kernel-2.6.9-42.0.2.EL.i686.rpm > which then made me wonder if there was a glitch in the build process. >No glitch in building, maybe a problem with the kernel and your hardware ... we always have a kernel and a kernel-smp. There is also a new ntp in those updates.> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.centos.org/pipermail/centos/attachments/20060826/f85569c7/attachment-0002.sig>
>> Now, the puzzling. This is an AMD Athlon XP 2600+ on an ASUS A7N8X >> deluxe ver 2.0 m/b. The symptom is that ntpd refuses to sync. DroppingAMD 3200+, -42.0.2-x86_64 kernel. My ntpd works just fine, up kernel. Discovers pit/tsc timer, and works great with no lost ticks, even with cpuspeed and idle throttling. I use external servers for ntpd. -- //Morten Torstensen //Email: morten at mortent.org //IM: Cartoon at jabber.no morten.torstensen at gmail.com And if it turns out that there is a God, I don't believe that he is evil. The worst that can be said is that he's an underachiever.
On Fri, 2006-08-25 at 20:40 -0500, Robert wrote:> <snip> > Now, the puzzling. This is an AMD Athlon XP 2600+ on an ASUS A7N8X > deluxe ver 2.0 m/b. The symptom is that ntpd refuses to sync.Any SELINUX messages? On my old fall-back K6-III, I get SELINUX messages. Haven't pursued them yet as I'm vacillating between putting 4.3 + updates on an new EPOX I've built or trying to wait for 4.4. And other things.> <snip>-- Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.centos.org/pipermail/centos/attachments/20060826/4a9c04f0/attachment-0002.sig>
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.
William L. Maltby wrote:> On Fri, 2006-08-25 at 20:40 -0500, Robert wrote: > >> <snip> >> Now, the puzzling. This is an AMD Athlon XP 2600+ on an ASUS A7N8X >> deluxe ver 2.0 m/b. The symptom is that ntpd refuses to sync. >> > > Any SELINUX messages?Just these 6 lines in /var/log/messages each time the machine is booted: Aug 26 09:06:49 mavis kernel: SELinux: Initializing. Aug 26 09:06:49 mavis kernel: SELinux: Starting in permissive mode Aug 26 09:06:49 mavis kernel: selinux_register_security: Registering secondary module capability Aug 26 09:06:50 mavis kernel: SELinux: Registering netfilter hooks Aug 26 09:06:50 mavis kernel: SELinux: Disabled at runtime. Aug 26 09:06:50 mavis kernel: SELinux: Unregistering netfilter hooks Which, I assume, is a result of: # cat /etc/selinux/config # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled. SELINUX=disabled # SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted> On my old fall-back K6-III, I get SELINUX > messages. Haven't pursued them yet as I'm vacillating between putting > 4.3 + updates on an new EPOX I've built or trying to wait for 4.4. > > And other things. > > >> <snip> >>Yes. Always other things. I think I'll abandon this one for the time being and concentrate on a very nice box that a friend GAVE me last Monday. Maybe it will behave properly.