Bug 109904
Summary: | problems after [RHSA-2003:325-01] glibc upgrades | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Leonardo Rodrigues <leolistas> |
Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
Status: | CLOSED ERRATA | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 9 | CC: | fweimer, herrold, lukasz, me, moneta.mace, rdieter, vkuznet, wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | 2.3.2-27.9.7 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2003-11-13 21:28:24 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Leonardo Rodrigues
2003-11-12 20:07:45 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. 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. 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 |