Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 695 - Merging glibc-2.2.5 on a live system blows up
Summary: Merging glibc-2.2.5 on a live system blows up
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: x86 Linux
: Highest normal (vote)
Assignee: Daniel Robbins (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-02-14 11:13 UTC by Karl Trygve Kalleberg (RETIRED)
Modified: 2003-02-04 19:42 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Karl Trygve Kalleberg (RETIRED) gentoo-dev 2002-02-14 11:13:37 UTC
On a system with 2.2.4-rX I tried updating to 2.2.5, which proved fatal.

I do not have the complete build log, but from the end:
sh: error while loading shared libraries: libdl.so.2: cannot open shared object
file: No such file or directory
sh: error while loading shared libraries: libdl.so.2: cannot open shared object
file: No such file or directory
!!! /usr/include/bits/sigaction.h
sh: error while loading shared libraries: libdl.so.2: cannot open shared object
file: No such file or directory
sh: error while loading shared libraries: libdl.so.2: cannot open shared object
file: No such file or directory
!!! /usr/include/bits/syscall.h
sh: error while loading shared libraries: libdl.so.2: cannot open shared object
file: No such file or directory
sh: error while loading shared libraries: libdl.so.2: cannot open shared object
file: No such file or directory
!!! /usr/include/bits/signum.h
sh: error while loading shared libraries: libdl.so.2: cannot open shared object
file: No such file or directory
sh: error while loading shared libraries: libdl.so.2: cannot open shared object
file: No such file or directory
!!! /usr/include/bits/sigset.h

It would appear that what should have been an atomic operation (installing a few
of the most vital shared libraries) is not, and that results in the above warnings.

To restore the system, cp /lib/libdl-2.2.4.so /lib/libdl.so.2,
ln -sf libnsl-2.2.4.so libnsl.so.1
ln -sf libresolv-2.2.4.so libresolv.so.2

and possibly other symlinks are needed.
Comment 1 Daniel Robbins (RETIRED) gentoo-dev 2002-02-14 11:21:32 UTC
What version of Portage are you using?  I emerged my glibc-2.2.5 while running X
with absolutely no problems.
Comment 2 Daniel Robbins (RETIRED) gentoo-dev 2002-02-14 11:30:14 UTC
Possibly these lines in src_install() are causing problems?  You could try
removing them and doing a test merge again.

rm ${D}/lib/ld-linux.so.2
rm ${D}/lib/libc.so.6
rm ${D}/lib/libpthread.so.0

It's also possible that if things (symlinks/libraries) are not merged in a
"correct" order, things will blow up.  Something to think about; let me know
what you find.
Comment 3 Brandon Low (RETIRED) gentoo-dev 2002-02-14 15:26:19 UTC
It probably has to do with the order of the symlinking... when installing glibc
it is vital to link libc.so.6 first, followed by libdl.so.2 the others should be
able to follow in any order... I am not yet familiar with the ebuild system so I
can't offer to correct the ebuild itself.
Comment 4 Gontran Zepeda 2002-02-14 17:26:59 UTC
Could not reproduce error.  System is uptodate as of requirements based on
rsync from ~10AM MST.  Could not reproduce error using ebuild.

ebuild sys-libs/glibc/glibc-2.2.5.ebuild install
ebuild sys-libs/glibc/glibc-2.2.5.ebuild qmerge

No defunct anything, and libdl.* is OK, no errors or failed tests
anywhere.

ldd --version
ldd (GNU libc) 2.2.5
...

Have script capture of both build processes, as well as 2.2.5 package available
with md5 sum on request.
Comment 5 Brandon Low (RETIRED) gentoo-dev 2002-02-14 18:41:54 UTC
Why are these lines in the ebuild?
        rm ${D}/lib/ld-linux.so.2
        rm ${D}/lib/libc.so.6
        rm ${D}/lib/libpthread.so.0
those are just symlinks, which should either a) have already been replaced by
the make install or b) will be regenerated by ldconfig in just a moment.
Comment 6 Daniel Robbins (RETIRED) gentoo-dev 2002-02-15 00:10:17 UTC
masked out for now; changing to a "normal" bug.
Comment 7 Brandon Low (RETIRED) gentoo-dev 2002-02-15 01:52:42 UTC
Ok, I have a working ebuild, I submitted it as glibc-2.2.5-r1.ebuild
basically it makes sure that all the symlinks for the libraries are moved away
before qmerging and then moves them all in after the binaries are installed to
ensure system continuity.
Comment 8 Brandon Low (RETIRED) gentoo-dev 2002-02-15 01:59:10 UTC
forgot, the ebuild is available at
http://www.lostlogicx.com/ebuilds/glibc-2.2.5-r1.ebuild
Comment 9 Daniel Robbins (RETIRED) gentoo-dev 2002-02-15 16:06:41 UTC
we haven't yet confirmed that this is a symlink problem.  I'm waiting for karltk
to perform a test and log the build process first.
Comment 10 Brandon Low (RETIRED) gentoo-dev 2002-02-15 17:04:38 UTC
I'm sure it is a symlink problem... of course I'm not god or anything... but 
when I tried to build with the original ebuild it did what happened to karltk, 
but with my ebuild it worked great... so...
Comment 11 Daniel Robbins (RETIRED) gentoo-dev 2002-02-15 17:06:29 UTC
ok, neat.
Comment 12 Daniel Robbins (RETIRED) gentoo-dev 2002-02-15 18:22:53 UTC
yes, it does look like a symlink problem.  I just noticed that on karltk's
system, 2 symlinks got installed before the libs got installed which would have
broke some important symlinks.  Will fix now.
Comment 13 Daniel Robbins (RETIRED) gentoo-dev 2002-02-15 18:51:38 UTC
a version of glibc-2.2.5-r1.ebuild with the same functionality at Brandon's
version has been added to CVS.  Closing this bug, and filing a new one for
Portage since Portage should handle this tricky stuff for us by ensuring that
symlinks are merged *after* the things that they point to.  We could still
potentially have problems with 2 layers of symlinks in /lib if the symlinks get
copied back in the
wrong order.