Bug#728529: [DSE-Dev] Bug#728529: libselinux1: causes ld.so error in smartctl/smartd
On Mon, Nov 11, 2013 at 10:23:25AM +0100, Laurent Bigonville wrote: Le Mon, 11 Nov 2013 09:40:52 +0100, Sven Hartge s...@svenhartge.de a écrit : On 11.11.2013 09:34, Laurent Bigonville wrote: Le Mon, 11 Nov 2013 09:26:38 +0100, Sven Hartge s...@svenhartge.de a écrit : On 11.11.2013 09:22, Laurent Bigonville wrote: Le Mon, 11 Nov 2013 09:13:46 +0100, Sven Hartge s...@svenhartge.de a écrit : I see you reverted the fix you made and reassigned the bug to eglibc6 with the commend affected software needs to be recompiled. I don't know if I like this solution. What, if I am not able to recompile an affected program? A binNMU for smartmontools has just been schedule. The new rebuilt version (6.2+svn3841-1+b1) of smartmontools should arrive soon on the archive. All fine and dandy, but what if I have a software showing the same problem, where I am not able to recompile, because I don't have any source code for said software? (This is a hypotethical case.) Calling ldd /usr/sbin/smartctl was also triggering the same assertion. I tired to run ldd on all the executables that are depending against libselinux and only the executables from the smartmontools package were showing this issue, so the other packages in the archive /should/ be safe. Everything from the package pools of Debian may be safe, yes. But there are other programs from third party vendors, which may show the same problem, which cannot be rebuild, because they are proprietary software. What about them? The only versions of libselinux that have been compiled against libpthread are 2.1.13(all revisions) and 2.2-2 The version from wheezy and even squeeze were not, so there is no regressions between stable release here. The way I see it is that libselinux1 and/or libc6 changed in an binary-incompatible way and should be fixed in a way which does not require a rebuild of eventually affected software. Well here it's not a simple ABI change, the loader itself is asserting, that's why I've reassigned the bug to eglibc. It's possible to trigger the assertion in wheezy, so I don't think it's a libc regression. It's more likely due to changes in libselinux, libpcre3 and/or smartmontools. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728529: [DSE-Dev] Bug#728529: libselinux1: causes ld.so error in smartctl/smartd
On Sat, Nov 15, 2014 at 02:07:44PM +0100, Aurelien Jarno wrote: On Mon, Nov 11, 2013 at 10:23:25AM +0100, Laurent Bigonville wrote: Le Mon, 11 Nov 2013 09:40:52 +0100, Sven Hartge s...@svenhartge.de a écrit : On 11.11.2013 09:34, Laurent Bigonville wrote: Le Mon, 11 Nov 2013 09:26:38 +0100, Sven Hartge s...@svenhartge.de a écrit : On 11.11.2013 09:22, Laurent Bigonville wrote: Le Mon, 11 Nov 2013 09:13:46 +0100, Sven Hartge s...@svenhartge.de a écrit : I see you reverted the fix you made and reassigned the bug to eglibc6 with the commend affected software needs to be recompiled. I don't know if I like this solution. What, if I am not able to recompile an affected program? A binNMU for smartmontools has just been schedule. The new rebuilt version (6.2+svn3841-1+b1) of smartmontools should arrive soon on the archive. All fine and dandy, but what if I have a software showing the same problem, where I am not able to recompile, because I don't have any source code for said software? (This is a hypotethical case.) Calling ldd /usr/sbin/smartctl was also triggering the same assertion. I tired to run ldd on all the executables that are depending against libselinux and only the executables from the smartmontools package were showing this issue, so the other packages in the archive /should/ be safe. Everything from the package pools of Debian may be safe, yes. But there are other programs from third party vendors, which may show the same problem, which cannot be rebuild, because they are proprietary software. What about them? The only versions of libselinux that have been compiled against libpthread are 2.1.13(all revisions) and 2.2-2 The version from wheezy and even squeeze were not, so there is no regressions between stable release here. The way I see it is that libselinux1 and/or libc6 changed in an binary-incompatible way and should be fixed in a way which does not require a rebuild of eventually affected software. Well here it's not a simple ABI change, the loader itself is asserting, that's why I've reassigned the bug to eglibc. It's possible to trigger the assertion in wheezy, so I don't think it's a libc regression. It's more likely due to changes in libselinux, libpcre3 and/or smartmontools. Some more remarks about this bug. It's possible to reproduce this bug with smartmontools from wheezy, and the same way with (e)glibc from wheezy or jessie. Therefore the bug doesn't seems to come from there. To be able to reproduce this bug, smartmontools needs to be build with the following conditions: - with binutils = 2.23.52.20130522-1, but using bfd, not gold - against libselinux1-dev linked against libpcre3 (which in turn might be linked or not against libthread) - against libpcre3 linked against libpthread At runtime it should not be (indirectly) linked against libpthread. That's why it works in jessie/sid, as libpcre3 is linked against libpthread. When comparing the resulting binaries, one might remark the following differences (- is working, + is not working): - 82: 0 NOTYPE WEAK DEFAULT UND pthread_cancel -740: 0 NOTYPE WEAK DEFAULT UND pthread_cancel +123: 00402f70 0 FUNCWEAK DEFAULT UND pthread_cancel@GLIBC_2.2.5 (7) +719: 00402f70 0 FUNCWEAK DEFAULT UND pthread_cancel@@GLIBC_2.2 The above difference is not present when linking with gold. It might to be related to one of the bug in the ld/15149 series [1]. Aurelien [1] https://sourceware.org/bugzilla/show_bug.cgi?id=15149 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728529: libselinux1: causes ld.so error in smartctl/smartd
Package: libselinux1 Version: 2.2-1 Severity: critical Justification: breaks unrelated software Hi! The recent upgrade auf libselinux1 to version 2.2-1 in unstable causes smartctl and smartd to fail with the following message: system:~# smartctl Inconsistency detected by ld.so: dl-version.c: 224: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed! Downgrading libselinux1 to 2.1.13-3 solves the problem. So far only smartctl/smartd is affected, but since this bug affects an unrelated package, the severity of critical seems correct. Please also see and maybe merge bug #728507 against smartmontools. Grüße, Sven. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (600, 'unstable'), (500, 'experimental'), (400, 'testing') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.11-1-amd64 (SMP w/12 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: [DSE-Dev] Bug#728529: libselinux1: causes ld.so error in smartctl/smartd
Processing commands for cont...@bugs.debian.org:
retitle 728529 libselinux1: Missing explicit link against libpthread
Bug #728529 {Done: Laurent Bigonville bi...@debian.org} [libselinux1]
libselinux1: causes ld.so error in smartctl/smartd
Changed Bug title to 'libselinux1: Missing explicit link against libpthread'
from 'libselinux1: causes ld.so error in smartctl/smartd'
severity 728529 grave
Bug #728529 {Done: Laurent Bigonville bi...@debian.org} [libselinux1]
libselinux1: Missing explicit link against libpthread
Severity set to 'grave' from 'critical'
reassign 728507 libselinux1 2.2-2
Bug #728507 [smartmontools] smartmontools: smartd fails to start Inconsistency
detected by ld.so:
Bug reassigned from package 'smartmontools' to 'libselinux1'.
No longer marked as found in versions smartmontools/6.2+svn3841-1.
Ignoring request to alter fixed versions of bug #728507 to the same values
previously set
Bug #728507 [libselinux1] smartmontools: smartd fails to start Inconsistency
detected by ld.so:
Marked as found in versions libselinux/2.2-2.
reassign 728113 libselinux1 2.1.9-5
Bug #728113 [smartmontools] [smartmontools] Fails to run on a Wheezy/Jessie
mixed system
Bug reassigned from package 'smartmontools' to 'libselinux1'.
No longer marked as found in versions smartmontools/6.2+svn3841-1.
Ignoring request to alter fixed versions of bug #728113 to the same values
previously set
Bug #728113 [libselinux1] [smartmontools] Fails to run on a Wheezy/Jessie mixed
system
Marked as found in versions libselinux/2.1.9-5.
forcemerge 728529 728507 728113
Bug #728529 {Done: Laurent Bigonville bi...@debian.org} [libselinux1]
libselinux1: Missing explicit link against libpthread
Bug #728113 [libselinux1] [smartmontools] Fails to run on a Wheezy/Jessie mixed
system
Severity set to 'grave' from 'normal'
Marked Bug as done
Marked as fixed in versions libselinux/2.2-2.
Marked as found in versions libselinux/2.2-2 and libselinux/2.2-1.
Bug #728507 [libselinux1] smartmontools: smartd fails to start Inconsistency
detected by ld.so:
Severity set to 'grave' from 'important'
Marked Bug as done
Marked as fixed in versions libselinux/2.2-2.
Marked as found in versions libselinux/2.2-1 and libselinux/2.1.9-5.
Bug #728529 {Done: Laurent Bigonville bi...@debian.org} [libselinux1]
libselinux1: Missing explicit link against libpthread
Marked as found in versions libselinux/2.2-2 and libselinux/2.1.9-5.
Merged 728113 728507 728529
thanks
Stopping processing here.
Please contact me if you need assistance.
--
728113: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728113
728507: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728507
728529: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728529
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728529: [DSE-Dev] Bug#728529: libselinux1: causes ld.so error in smartctl/smartd
retitle 728529 libselinux1: Missing explicit link against libpthread severity 728529 grave reassign 728507 libselinux1 2.2-2 reassign 728113 libselinux1 2.1.9-5 forcemerge 728529 728507 728113 thanks Le Sat, 02 Nov 2013 17:04:31 +0100, Sven Hartge s...@svenhartge.de a écrit : Hi! Hi, The recent upgrade auf libselinux1 to version 2.2-1 in unstable causes smartctl and smartd to fail with the following message: system:~# smartctl Inconsistency detected by ld.so: dl-version.c: 224: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed! Downgrading libselinux1 to 2.1.13-3 solves the problem. Thanks for the bugreport, explicitly linking libselinux against libpthread seems to fix this. So far only smartctl/smartd is affected, but since this bug affects an unrelated package, the severity of critical seems correct. Please also see and maybe merge bug #728507 against smartmontools. Merged, I'm a bit puzzled about #728113 but it also seems related. Cheers Laurent Bigonville -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
