[Bug 920942] [NEW] ldconfig makes system loader ld-linux.so.2 to be link to 3rd party loader resides in /lib directory on Ubuntu 11.04
Venkatesh
920942 at bugs.launchpad.net
Tue Jan 24 12:15:38 UTC 2012
Public bug reported:
ldconfig unlink or removes the existing system loader ld-linux.so that
was linked to /lib/i386-linux-gnu/ld-2.13.so and creates symlink with
3rd party loader which resides in /lib/ld-.so, This creates system
unusable and gets kernel panic on reboot. This ldconfig behavior can be
reproduced when I was doing any pkg installation or upgrade system using
apt-get install(Only when 3rd party loaders say for ex. ld-.so present
in /lib directory)
Simple General steps to reproduce:
------------------------------------------------------
1) Create shared library loader ld-test.so.2 providing SONAME of system loader that is "ld-linux.so.2" and copy loader ld-test.so.2 to /lib directory
2) Now just run command "ldconfig"
3) after completing ldconfig system is in unusable state that means no commands work, workaround for commands to work is to set LD_LIBRARY_PATH="/lib/i386-linux-gnu" . But kernel panic occurs if we reboot system.
I looked into this issue and then found that what apt-get install is
doing and came to know that the ldconfig which is doing this symbolic
link to 3rd party loader. Then I gone through ldconfig source code
(glibc 2.13) and understood little bit of ldconfig algorithm and came to
know that the ldconfig basically searches based on SONAME of each
library,Checked our 3rd party library SONAME using "readelf -d
/lib/ld-.so.2" utility.
As 3rd party loader ld-.so and system loader /li/ld-linux.so.2 has same
SONAME, I am thinking this is causing the ldconfig to link to 3rd party
loader. Not sure exactly thats why I have created simple shared library
which is having same SONAME as the system loader having and tested the
system upgrade using apt-get and then I have encountered into same
issue(system unusable) and apt-get upgrade works fine without any issues
after creating loader with different SONAME.
But as other versions (Ubuntu 10.xx)or different distribution
(RHEl,SLES)of linux works fine with this 3rd party loader having same
SONAME, only on this Ubuntu 11.04 creating problem. How is it
functioning different here?Is there any specific change with respect to
ldconfig loading/linking of 3rd party loaders kept in /lib directory? or
having similar SONAME for both loaders creating this problem, if yes
then why its not happening on earlier versions? Which is the better
place/path in the system to keep 3rd party loaders both in case of a
public or private?
Hope above info is enough to understand the issue and appreciate your kind help on this issue.
Please let me know in case if you require any more info.
Thanks and Regards
Venkatesh Prasad C
venkiprs at gmail.com
** Affects: eglibc (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to eglibc in Ubuntu.
https://bugs.launchpad.net/bugs/920942
Title:
ldconfig makes system loader ld-linux.so.2 to be link to 3rd party
loader resides in /lib directory on Ubuntu 11.04
Status in “eglibc” package in Ubuntu:
New
Bug description:
ldconfig unlink or removes the existing system loader ld-linux.so that
was linked to /lib/i386-linux-gnu/ld-2.13.so and creates symlink with
3rd party loader which resides in /lib/ld-.so, This creates system
unusable and gets kernel panic on reboot. This ldconfig behavior can
be reproduced when I was doing any pkg installation or upgrade system
using apt-get install(Only when 3rd party loaders say for ex. ld-.so
present in /lib directory)
Simple General steps to reproduce:
------------------------------------------------------
1) Create shared library loader ld-test.so.2 providing SONAME of system loader that is "ld-linux.so.2" and copy loader ld-test.so.2 to /lib directory
2) Now just run command "ldconfig"
3) after completing ldconfig system is in unusable state that means no commands work, workaround for commands to work is to set LD_LIBRARY_PATH="/lib/i386-linux-gnu" . But kernel panic occurs if we reboot system.
I looked into this issue and then found that what apt-get install is
doing and came to know that the ldconfig which is doing this symbolic
link to 3rd party loader. Then I gone through ldconfig source code
(glibc 2.13) and understood little bit of ldconfig algorithm and came
to know that the ldconfig basically searches based on SONAME of each
library,Checked our 3rd party library SONAME using "readelf -d
/lib/ld-.so.2" utility.
As 3rd party loader ld-.so and system loader /li/ld-linux.so.2 has
same SONAME, I am thinking this is causing the ldconfig to link to 3rd
party loader. Not sure exactly thats why I have created simple shared
library which is having same SONAME as the system loader having and
tested the system upgrade using apt-get and then I have encountered
into same issue(system unusable) and apt-get upgrade works fine
without any issues after creating loader with different SONAME.
But as other versions (Ubuntu 10.xx)or different distribution
(RHEl,SLES)of linux works fine with this 3rd party loader having same
SONAME, only on this Ubuntu 11.04 creating problem. How is it
functioning different here?Is there any specific change with respect
to ldconfig loading/linking of 3rd party loaders kept in /lib
directory? or having similar SONAME for both loaders creating this
problem, if yes then why its not happening on earlier versions? Which
is the better place/path in the system to keep 3rd party loaders both
in case of a public or private?
Hope above info is enough to understand the issue and appreciate your kind help on this issue.
Please let me know in case if you require any more info.
Thanks and Regards
Venkatesh Prasad C
venkiprs at gmail.com
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/920942/+subscriptions
More information about the foundations-bugs
mailing list