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... and http://isoredirect.centos.org/centos/4/updates/i386/RPMS/kernel-2.6.9-42.0.2... which then made me wonder if there was a glitch in the build process.
Has anyone else seen this?
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@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... and http://isoredirect.centos.org/centos/4/updates/i386/RPMS/kernel-2.6.9-42.0.2... 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.
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
AMD 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.
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 :) :
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@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@mavis ~]# uptime 09:00:07 up 9 min, 7 users, load average: 0.02, 0.33, 0.24 [root@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@mavis ~]# rpm -q ntp ntp-4.2.0.a.20040617-4.EL4.1 [root@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@mavis ~]# uptime 09:10:59 up 5 min, 7 users, load average: 1.08, 0.96, 0.44 [root@mavis ~]# rpm -q ntp ntp-4.2.0.a.20040617-4.EL4.1 [root@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@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.
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>
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.
-
Johnny Hughes -
Morten Torstensen -
Robert -
Thomas E Dukes -
William L. Maltby