Bug 109904 - problems after [RHSA-2003:325-01] glibc upgrades
Summary: problems after [RHSA-2003:325-01] glibc upgrades
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc   
(Show other bugs)
Version: 9
Hardware: i686 Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-11-12 20:07 UTC by Leonardo Rodrigues
Modified: 2016-11-24 15:11 UTC (History)
8 users (show)

Fixed In Version: 2.3.2-27.9.7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-11-13 21:28:24 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2003:325 normal SHIPPED_LIVE : Updated glibc packages provide security and bug fixes 2003-11-12 05:00:00 UTC

Description Leonardo Rodrigues 2003-11-12 20:07:45 UTC
I got problems after upgrading glibc using RPMs from [RHSA-2003:325-
01]. I've checked the i686 or i386 architeture and installed the 
correct one (i686).

RPM fails, apparently, with ANY options I use:

[root@firewall updates-9]# rpm -qi wget
rpmdb: unable to join the environment
error: db4 error(11) from dbenv->open: Resource temporarily 
error: cannot open Packages index using db3 - Resource temporarily 
unavailable (11)
error: cannot open Packages database in /var/lib/rpm
package wget is not installed

wget is installed for sure !

[root@firewall updates-9]# wget --version
GNU Wget 1.8.2

[root@firewall updates-9]# rpm -q --qf '%{arch}\n' glibc
rpmdb: unable to join the environment
error: db4 error(11) from dbenv->open: Resource temporarily 
error: cannot open Packages index using db3 - Resource temporarily 
unavailable (11)
error: cannot open Packages database in /var/lib/rpm
package glibc is not installed
[root@firewall updates-9]# 

Ohhh yes, glibc is installed for sure :))

Doing some research, I found that doing:
export LD_ASSUME_KERNEL=2.4.1
would solve, for example, the 'rpm' problems. Everything worked fine 
with LD_ASSUME_KERNEL but stops working after 'unset 

Anyway, I've downgraded (rpm -Uvh --force) glibc to glibc-2.3.2-
27.9.i686.rpm and assume this is not right. I had to use 
LD_ASSUME_KERNEL=2.4.1 for being able to downgrade glibc RPMs.

The problem is fully reproductible.

1. Checking correct architeture of glibc:
[root@firewall updates-9]# rpm -q --qf '%{arch}\n' glibc

2. Downloaded all needed RPMs and 'freshen' them all:
rpm -Fvh glibc-2*i686.rpm glibc-common* glibc-debug* glibc-devel* 
glibc-profile* glibc-utils* nscd-* nptl-*

3. RPM goes with no problem at all. nptl-devel wasnt freshed because 
it wasnt installed. All others were freshed correctly.

4. Checking if new RPMs were installed (have to use LD_ASSUME_KERNEL 
for getting this)

[root@firewall updates-9]# rpm -qa | grep glibc

5. There is goes ....... 'unset LD_ASSUME_KERNEL' and errors that I 
post in the Description are always reproductible.

Comment 1 Ulrich Drepper 2003-11-12 21:33:35 UTC
You fail to say what rpm version you're using.  Get the latest
version.  There have been bugs in rpm which look like this.

Comment 2 Leonardo Rodrigues 2003-11-12 21:41:50 UTC
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
[root@firewall root]# 

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

Comment 3 Valentine Kouznetsov 2003-11-12 22:01:12 UTC
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).

Comment 4 Valentine Kouznetsov 2003-11-12 22:04:41 UTC
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).

Comment 5 Leonardo Rodrigues 2003-11-12 22:09:24 UTC
I could downgrade glibc RPMs using rpm -Uvh --force ..... worked fine 

Comment 6 Jakub Jelinek 2003-11-12 22:18:57 UTC
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
+      int ret;
+      ret = INTERNAL_SYSCALL (set_tid_address, err, 1, NULL);
+      if (INTERNAL_SYSCALL_ERROR_P (ret, err))
+       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

Comment 7 Jakub Jelinek 2003-11-12 22:21:21 UTC
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.

Comment 8 Łukasz Trąbiński 2003-11-12 22:31:22 UTC
when we can expect glibc-2.3.2-27.9.7?

Comment 9 Jakub Jelinek 2003-11-12 22:35:02 UTC
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.

Comment 10 Jakub Jelinek 2003-11-13 01:08:41 UTC
Please try ftp://people.redhat.com/jakub/glibc/errata/2.3.2-27.9.7/

Comment 11 Roy W. Reter 2003-11-13 01:24:16 UTC
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.

Comment 12 Leonardo Rodrigues 2003-11-13 01:50:14 UTC
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.

Comment 13 Jakub Jelinek 2003-11-13 01:56:51 UTC
Can you please:
a) make sure LD_ASSUME_KERNEL is unset
b) ldd /bin/echo
c) strace /bin/echo

Comment 14 Roy W. Reter 2003-11-13 02:07:24 UTC
Just tested in X (running Nvidia X driver), mozilla, gnome term,
etc... all seem to be running fine with Jakub's new glibc rpms.

Comment 15 Leonardo Rodrigues 2003-11-13 02:14:22 UTC
Sure ..... let's see everything:

1) Let's check if the correct RPMs are installed:
[root@firewall root]# rpm -qa | grep glibc
[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 
brk(0)                                  = 0x804bda8
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or 
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) = 
old_mmap(0x4014f000, 12288, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED, 3, 0x133000) = 0x4014f000
old_mmap(0x40152000, 9924, PROT_READ|PROT_WRITE, 
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
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 ???

Comment 16 Leonardo Rodrigues 2003-11-13 02:15:35 UTC
Forget to post this ..... architeture being used is 686 here

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

Comment 17 Jakub Jelinek 2003-11-13 08:11:57 UTC
This looks as expected.  Thanks.

Comment 18 Leonardo Rodrigues 2003-11-13 09:30:08 UTC
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.

Comment 19 Jakub Jelinek 2003-11-13 09:47:00 UTC
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.

Comment 20 Marco Coli 2003-11-13 19:24:12 UTC
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 ?
  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:

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

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

Marco Coli

Comment 21 Jakub Jelinek 2003-11-13 21:28:24 UTC
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.

Comment 22 Łukasz Trąbiński 2003-11-13 22:16:51 UTC
I have just installed glibces from
on my all RH machines, now it seems OK

Note You need to log in before you can comment on or make changes to this bug.