fredex wrote: > I haven't contacted RH yet because my RHEL4 box is currently down due > to a hardware problem, and I know they won't talk to me if I say I > can reproduce it on a Centos box! :) Stupid question, but is the box in question an i586 by any chance? There used to be issues with NPTL and i586 long time ago in FC2, which were mostly fixed in FC3. The fix for RHEL4 was simply not to support i586 architecture (CentOS project re-added it). So if it is an old i586 box, Red Hat ain't gonna talk to you since RHEL4 is not supposed to run on an i586. The problem with NPTL on i586 (in FC2) was that Red Hat provided only i386 and i686 versions of glibc package. NPTL can't be efficiently implemented on an i386 (it would be horribly slow). So i386 doesn't support it, and things were not working on i586 machines (kernel was supporting it, but glibc didn't). Many packages were broken because of that, most notably db3 (or db4, don't remember which one was shipped with FC2) and cyrus-imapd. Workaround in FC3 was i386 package that wasn't really i386-clean. It contained NPTL support using instructions that were available only on i486 and later processors (the glibc package should really have been labeled i486, not i386). In short, i386 version of glibc in FC3 can't run on real i386 processor (it needs i486 at minimum). However, since they provided only i586 and i686 kernels, it wasn't possible (or at least trivial) to install FC3 on real i386. And I really doubt anybody would ever attempt to install FC3 on real i386 box. I believe (somebody correct me if I'm wrong) that CentOS 4 contains the same hack in i386 version of glibc (in order to support i586 processors). If you are experiencing problem on i586 box, it might be possible that maintainer of glibc package in CentOS forgot to include that "use i486 instructions for NPTL support when building i386 glibc" hack into the latest version of glibc (4.4 shipped with new version of glibc).