Back on Saturday, November 11, 2000, I wrote
CMC> I just had hours of ``fun'' after typing the fateful
CMC> command ``apt-get upgrade'' and having my glibc packages
CMC> upgraded from 2.1.3-13 to 2.1.97-1.
This weekend, we had another go, and managed to figure out what
the problem was (it wasn't the libc6 packages at all) and get
things working.
As you may recall, the main symptom was that some binaries --
notably /bin/login -- caused Illegal instruction errors (meaning
that it is impossible to log in to the machine after an upgrade).
More specifically, the error was
Trace/BPT trap
With gdb, the error was slightly more verbose:
Program received signal SIGTRAP, Trace/Breakpoint trap.
0x7fffd188 in ??? ()
(gdb) bt
#0 0x7fffd188 in ??? ()
Weirdly, though, if the debugging versions of the libraries were
used (by setting the environment variable LD_LIBRARY_PATH to
/usr/lib/debug), the program would execute normally, indicating
that the problem was related to the main libraries.
Because there were no debugging symbols in the main libraries, we
decided to build a set of libraries that contained those
symbols.[*]
When I downloaded the source (with ``apt-get source libc6''), I
ended up with libc6 2.2-1, and after compiling and installing, the
2.2-1 libraries gave the same error with /bin/login. To figure
out exactly where the problem was, we ended up building unstripped
versions of several additional packages (login, libpam) before
finally discovering that the problem occurred when loading
libdl.so.2. When I checked the file, I found that /lib/libdl.so.2
was a symbolic link to the wrong file -- /lib/libdl.so rather than
/lib/libdl-2.2.so:
-rw-r--r-- 1 root root 56974 Nov 20 12:18 /lib/libdl-2.2.so
-rw-r--r-- 1 root root 10640 Mar 12 2000 /lib/libdl.so
lrwxrwxrwx 1 root root 8 Nov 20 21:29 /lib/libdl.so.2 ->
libdl.so
When I replaced the link with one to libdl-2.2.so, the errors
stopped. As long as a /lib/libdl.so file was present, however,
running ldconfig would recreate the link to the old, incorrect
file!
That leaves me with the mystery of where the /lib/libdl.so file
came from, and why it was still present on my system. When I did
a contents search, the only ``libdl.so'' found was a symbolic link
in /usr/lib, and is part of libc6-dev. Is it possible that the
file in /lib came from some other package that existed in March of
2000? Any other ideas? (And, no, I've never built C libraries
outside of the Debian packages.)
At any rate, everything seems to be fine now. Thanks for the
helpful followups to my original report -- knowing that other
people hadn't had the problem helped localize things a bit -- and
apologies for rasing a false alarm.
CMC
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Behind the counter a boy with a shaven head stared vacantly into space,
a dozen spikes of microsoft protruding from the socket behind his ear.
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
C.M. Connelly [EMAIL PROTECTED] SHC, DS
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
[*] One extremely annoying discovery was that the libc6 packages
*must be built as root*. Leaving aside the question of *why*
the packages can't be built with fakeroot (or as an ordinary
user, even) -- the Red Hat RPMs do not require you to be root --
it would have been really nice if the package had checked
for root *first*, rather than running for 4.5 hours and only
then realizing it couldn't finish.
