on Mon, Nov 26, 2001 at 02:13:10AM +0100, A.R. (Tom) Peters (tpeters@xs4all.nl) wrote:
> On Sun, 25 Nov 2001, Karsten M. Self wrote:
>
> > on Sun, Nov 25, 2001 at 02:22:13AM +0100, A.R. (Tom) Peters (tpeters@xs4all.nl) wrote:
> > > I tried to install the G77 compiler, and got the latest stuff from
> > > testing. It required a newer version of libc6 (2.2.4-5), which got
> > > installed first. Then all subsequent packages failed. I cannot open a
> > > shell anymore:
> > >
> > > /bin/sh: relocation error: /bin/sh: undefined symbol: history_max_entries
> > >
> > > Existing shells still work, but this situation paralyzes just about
> > > anything, including apt. What can I do?
> >
> > Sounds like you might have tweaked some libs.
>
> No I did not. I just tried to install a package, and then apt-get
> decided that libc should be upgraded.
That's what I'd said. I was implying libs had been tweaked on your
system. Intentionality wasn't implied.
> > Do you have sash installed? This is the Stand Alone Shell -- it has
> > no dynamic library deps and builds-in a bunch of basic utilities
> > (names are prefixed with a '-', e.g.: -ls). Very helpful when
> > you've fried your system, particularly libraries, or for running
> > from a known trusted floppy on a compromised box. The linker
> > utilities (ld, ldd) aren't included, but you might use these.
> > You're looking for libraries which have changed, are corrupted, or
> > have been deleted. I think.
>
> Thanx for the tip. I did not have it, but could copy it from a BBC.
> Unfortunately sash appears to be a really interactive shell, and a bad
> replacement for `sh`. `ash` is somewhat better in that respect.
You're not looking for a shell to replace bash, you're looking for a
shell that will _run on your system, as is_ so you can recover it.
Somewhere there's either an unlinked copy of your old libc, or the old
libc6 package, or the new libc6 package. Your task is to get one or
another of these into a state that the rest of your system runs.
As libc is *the* system library, its existence in a proper state is
rather crucial to any system process working properly.
> In the end, I replaced my current version of bash by an older one from
> CD. Weirdly, that worked. But the bash I had (maybe bash-2.05-8 but
> presumably earlier) is NOT compatible with libc6-2.2.4-5 .
The old bash may have been linked to an older libc (like libc5). If
you hadn't gotten around to deleting this yet ;-), it probably still
exists, quivering in fear, on your system.
$ ldd /bin/bash
...to see what it's linked to.
> A classical example on how not to try repair a running engine: I did:
>
> rm libc.so.6
> ln -s libc-2.2.1.so libc6.so.6
I did that. Once. You're learning the same lesson.
> Of course, this should have been:
>
> rm libc.so.6 ; ln -s libc-2.2.1.so libc6.so.6
Wrong.
The proper command is:
$ ln -sf libc-2.2.1.so libc6.so.6
'ln' is an atomic operation -- the process completes in a single step.
Your two-pass processes both involve first removing, remember, that
all-important libc6 system library, on which virtually every binary
depends. sash is an exception -- it's the stand-alone shell, if you'll
recall from my description. It doesn't rely on any system libraries to
run. OpenBSD similarly compiles /bin/csh statically (with no dynamic
linking) so that the shell will survive deletion or damage of system
libraries.
> ah, the subtleties of whitespace.
Subtleties yes. Whitespace no. Dynamic linking, yes.
What happens in the link above is:
- 'ln' is invoked. It is (check with ldd) dynamically linked against
libc6. It loads libc6, and executes.
- 'ln', loaded in memory, unlinks the old libc6 link, and overlays
(the '-f' option is a "force" to overwrite an existing link) the
new link. 'ln' isn't effected by this operation because it's
currently in memory.
- 'ln' exits. If you invoke it again, it will be linked with the new
libc6 library.
This is, in fact, how your system libraries are updated when things go
properly. It's also why your system libraries are symlinks rather than
files. You can't replace a file with a tool that requires the existence
of the file. Symlinks aren't bothered by this detail.
So, the lesson is, in GNU/Linux, you can replace the engine while you're
flying. The way you do it is you don't drive things from the engine but
from a shaft pointing at the engine. You drop in the replacement
engine, then in one fluid move, replace the old shaft pointing at the
old engine with a new shaft pointing at the new one.
You *can* try this at home, kids. However, don't try this in an
airplane.
> In fact, this doesn't work either: `ln` breaks immediately.
Yep.
> I had to use > `sash` to do these kind of commands.
Which was what I was trying to tell you earlier.
> (Now I think of it, `rm libc.so.6 && ln -s libc-2.2.1.so libc6.so.6`
> might have worked).
Nope. Two processes.
> Years ago it used to be that /sbin/ contained all important utilities
> Statically linked, in case something seriously went wrong with
> libraries. This custom has disappeared, and I feel the loss severely
> today.
You'll get over it.
Keep sash around. It's handy, and fills that comfort zone you're
missing above. And stop deleting libc. It's a bad practice.
Peace.
--
Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/
What part of "Gestalt" don't you understand? Home of the brave
http://gestalt-system.sourceforge.net/ Land of the free
Free Dmitry! Boycott Adobe! Repeal the DMCA! http://www.freesklyarov.org
Geek for Hire http://kmself.home.netcom.com/resume.html
Attachment:
pgpX6t_kGltSI.pgp
Description: PGP signature