Bug 109904

You fail to say what rpm version you're using.  Get the latest
version.  There have been bugs in rpm which look like this.

There's no rpm updates available at 
http://updates.redhat.com/9/en/os/i386/. I'm using RPM that ships 
with RH9.

[root@firewall root]# rpm -qa | grep rpm
rpm-python-4.2-0.69
rpm-devel-4.2-0.69
rpm-4.2-0.69
rpm-build-4.2-0.69
[root@firewall root]# 

Is there any rpm software update that I should use before the glibc 
updates ?

Same problem. Custom kernel 2.4.22. After upgrade to new
glibc-2.3.2-27.9.6 rpm and other application stop working including
mozilla, gkrellm, etc. It looks like problem related to NTPL. Your
comments about "similar" bug with rpm is wrong since they have different
error code db4 error(16) and here we got db4 error(11). 
The only solution as was pointed out is to use for applications 
LD_ASSUME_KERNEL option. I used LD_ASSUME_KERNEL=2.2.5 mozilla for
instance to run mozilla. BTW, searching on a web I found as well
nosysinfo option which can be passed to kernel. Well, I would say it
solves some problems not all. For instance it solve mozilla problem,
but not gkrellm. It solves rpm problem, but only for user, not for
root which I don't understand at all. I mean, as a user I can do rpm
-qa and as a root I can't (only with LD_ASSUME_KERNEL trick).
Valentine.

By the way I was wondering how you downgrade your system.
I've tried to use rpm -ivh --replacepkgs and got conflicts. Should I
force and/or remove those packages (remove seems to be dangereous
since it glibc).
Valentine.

I could downgrade glibc RPMs using rpm -Uvh --force ..... worked fine 
here.

I think I've found a typo in glibc-nptl-check.patch.
Until glibc-2.3.2-27.9.7 is built, you can do one of:
1) use RHL kernels
2) export LD_ASSUME_KERNEL=2.4.1
3) temporarily (till upgrade to 27.9.7) mv /lib/tls /lib/notls
The patch was doing:
+dl_redhat_nptl_check (const char *cp)
+{
+  if (GL(dl_sysinfo) == DL_SYSINFO_DEFAULT)
+    return;
+  cp = strchr (cp, 'n');
+  if (__builtin_expect (cp == NULL || cp[1] != 'p'
+                       || cp[2] != 't' || cp[3] != 'l', 0)
+      && GL(dl_osversion) < 0x20545
+      && GL(dl_osversion) > 0x20413)
+    {
+#ifdef __NR_set_tid_address
+      INTERNAL_SYSCALL_DECL (err);
+      int ret;
+      ret = INTERNAL_SYSCALL (set_tid_address, err, 1, NULL);
+      if (INTERNAL_SYSCALL_ERROR_P (ret, err))
+#endif
+       GL(dl_osversion) = 0x20413;
+    }
+}

while it ought to do if (GL(dl_sysinfo) != DL_SYSINFO_DEFAULT)
in the third line, so that the check works like:
1) if kernel provides AT_SYSINFO (RHL9 kernels or 2.6.x), use NPTL (unless overridden with LD_ASSUME_KERNEL which is done elsewhere)
2) if uname -r contains "nptl" substring (e.g. FC1 kernels), use NPTL
3) otherwise, try set_tid_address(0) syscall, if succeeds, use NPTL
4) otherwise use linuxthreads only
but because of the typo did in 1) if kernel does not provide AT_SYSINFO, use NPTL

FYI this hasn't been discovered because that glibc has been tested
against RHL9, FC1 and RHEL3 kernels only and for all of them NPTL
was used as it should.

when we can expect glibc-2.3.2-27.9.7?

Testing version (on people.redhat.com) when it gets through the build system
(shouldn't take more than 1 hour), as official errata depends how long
it will take through QA.

Please try ftp://people.redhat.com/jakub/glibc/errata/2.3.2-27.9.7/

Got another work around till 2.3.2-27.9.7 comes out.  Boot into a RH
kernel do a force install with nodeps  of the i386 version of glibc
and then reboot into your custom kernel and that should fix it
temporarily.  Hope this get fixed quickly!!  I'm going to try Jakub's
new versions next.

Jakub, i've download your 2.3.2-27.9.7 RPMs, freshed them and things 
seems to be OK. The machine I'm using for these tests have only a few 
services running. I've have no XFree installed, i cannot test mozzila 
and other stuff. Anyway, 'rpm -qi something' and 'rpm -qa' seems to 
be OK, which werent with the errata RPMs. Apache is running fine, 
squid is running fine, iptables is running fine, PPPoE is starting 
fine ...... probably need more tests, i'll keep the machine running 
with this glibc and let's see what will happen.

Can you please:
a) make sure LD_ASSUME_KERNEL is unset
b) ldd /bin/echo
c) strace /bin/echo
?
Thanks.

Just tested in X (running Nvidia X driver), mozilla, gnome term,
etc... all seem to be running fine with Jakub's new glibc rpms.

Sure ..... let's see everything:

1) Let's check if the correct RPMs are installed:
[root@firewall root]# rpm -qa | grep glibc
glibc-common-2.3.2-27.9.7
glibc-devel-2.3.2-27.9.7
glibc-utils-2.3.2-27.9.7
glibc-debug-2.3.2-27.9.7
glibc-kernheaders-2.4-8.10
glibc-2.3.2-27.9.7
glibc-profile-2.3.2-27.9.7
[root@firewall root]#

   Yes, they are :)


2) Let's check if LD_ASSUME_KERNEL is unset:

[root@firewall root]# set | grep LD_ASSUME_KERNEL
[root@firewall root]# 

   Yes, its unset.

3) ldd /bin/echo

[root@firewall root]# ldd /bin/echo
        libc.so.6 => /lib/i686/libc.so.6 (0x4001c000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[root@firewall root]# 

4) strace /bin/echo

[root@firewall root]# strace /bin/echo
execve("/bin/echo", ["/bin/echo"], [/* 21 vars */]) = 0
uname({sys="Linux", node="firewall", ...}) = 0
set_tid_address(0)                      = -1 ENOSYS (Function not 
implemented)
brk(0)                                  = 0x804bda8
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or 
directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=24446, ...}) = 0
old_mmap(NULL, 24446, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40016000
close(3)                                = 0
open("/lib/i686/libc.so.6", O_RDONLY)   = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 [\1\000"..., 
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1552740, ...}) = 0
old_mmap(NULL, 1279684, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 
0x4001c000
old_mmap(0x4014f000, 12288, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED, 3, 0x133000) = 0x4014f000
old_mmap(0x40152000, 9924, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40152000
close(3)                                = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40155000
munmap(0x40016000, 24446)               = 0
brk(0)                                  = 0x804bda8
brk(0x804cda8)                          = 0x804cda8
brk(0)                                  = 0x804cda8
brk(0x804d000)                          = 0x804d000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=31202800, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40156000
mmap2(NULL, 180224, PROT_READ, MAP_PRIVATE, 3, 0xafc) = 0x40356000
mmap2(NULL, 24576, PROT_READ, MAP_PRIVATE, 3, 0xb2e) = 0x40016000
mmap2(NULL, 4096, PROT_READ, MAP_PRIVATE, 3, 0xb36) = 0x40382000
close(3)                                = 0
fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 1), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -
1, 0) = 0x40383000
write(1, "\n", 1
)                       = 1
munmap(0x40383000, 4096)                = 0
exit_group(0)                           = ?
[root@firewall root]#


   Is there any other information that you may need ? Some debug 
stuff ???

Forget to post this ..... architeture being used is 686 here

[root@firewall root]# rpm -q --qf '%{arch}\n' glibc    
i686
[root@firewall root]# 

This looks as expected.  Thanks.

Jakub, do the fact that I'm using a custom kernel built from original 
sources (not redhat sources) have something to do with this problem ? 
I mean, would this problem happen if I were using RH compiled kernels 
or a custom kernel compiled based on redhat patched kernel sources ?

I'm using 2.4.22 compiled based on sources from www.kernel.org, only 
a few patchs on netfilter.

Yes, see above. If you were using RHL kernel, it would work (which is
what was tested during QA).  Only old kernels without NPTL support
don't work with -27.9.6.

I am afraid but the problem exists also with RH Kernel:

My server with RHL 9 and XD2:
[root@pinguino NEW]# uname -a
Linux pinguino 2.4.20-20.9 #1 Mon Aug 18 11:45:58 EDT 2003 i686 i686
i386 GNU/Linux

After upgrade (via up2date) a lot of applications dont' work anymore:
mozilla, galeon, up2date and so on.

Example for up2date:
[root@pinguino NEW]# up2date
Traceback (most recent call last):
  File "/usr/sbin/up2date", line 993, in ?
    main()
  File "/usr/sbin/up2date", line 772, in main
    from up2date_client import gui
  File "gui.py", line 20, in ?
  File "/usr/share/rhn/__init__.py", line 43, in ?
    File "/usr/share/rhn/__init__.py", line 43, in ?
ImportError: /usr/lib/libfontconfig.so.1: undefined symbol:
FT_Get_PS_Font_Info

Problems are always related to libfontconfig.
[root@pinguino NEW]# rpm -q fontconfig
fontconfig-2.2.0-0.ximian.6.3

I tried to reinstall fontconfig without changes. I had to degrade
glibc packages to previous versions

Marco Coli

Errata has been reissued for this: https://rhn.redhat.com/errata/RHSA-2003-325.html
As for comment #20, this looks like Ximian bug, I'd suggest filing
it there instead.

I have just installed glibces from
ftp://people.redhat.com/jakub/glibc/errata/2.3.2-27.9.7/
on my all RH machines, now it seems OK