Re: Serious "Bug" in most major Linux distros.
On Thu, May 23, 2002 at 04:32:39PM -0700, Karl E. Jorgensen wrote:
> On Thu, May 23, 2002 at 02:38:15PM -0700, Petro wrote:
<major snipage>
> > Yes. Or just figuring out if there is even a wreck, how it
> happened
> > etc.
> > > with the intent of restoring the "wreckage" rather than scrapping
> it.
> > > Reread the quoted text from Karl.
> > I know what he is saying, and he's right in a limited way. If your
> > entire ability to administer a system envolves unpacking .debs and
> > answering the configure questions they ask, a static shell is
> > pointless.
> > I'm not in that position.
>
> I have to disagree with your implication ("entire ability"....). I
> suspect that you have some high levels of frustration showing through
> here.
Yes, there is some level of frustration.
> My previous post was assuming:
> a) you have hosed some essential library - ld-linux, libc, whatever.
> b) you want to repair it (later on it transpired that you were happy
> just
> to rescue the data before scrapping the lot, which will mean a
> different approach).
>
> With that in mind, you may well want to re-extract the damaged file(s)
> out of a .deb (e.g. one you have conveniently left floating around in
> /var/cache/apt/archives).
If one has a small set of utilities that do not depend on external
libraries, a SA with a bit of creative thinking and nimble fingers
can accomplish a lot.
The others (those without creative thinking and nimble fingers) are
screwed blue anyway.
The desire is for a small set of standard tools statically compiled
so *IF NOTHING ELSE* I can determine just how badly a system is
horked. There are about 37.38 billion ways a system can wind up in
an unstable or stochastic state, from mv * .. in /lib (I a much more
complex and lengthy equivelent of that in a shell script on a OS X
box 2 weeks ago) to memory or filehandle exhaustion, to a corrupt
file etc.
Some of these *do* require a reinstall. Some of these just require a
reboot. Others require different handling.
In an installation with more than 1 computer, and the right tools
statically linked, most would not require the ability to extract
.debs, but if all that requires is ar and gzip, then that's not too
much to ask.
I'm starting a list of tools that should be available in a static
format. I don't know what I'm going to so about it yet, but I have
discovered a wierdness in bash debian source package.
There is a define in debian/rules in that package that is:
# build a statically linked bash?
with_static = yes
However, the default rules file doesn't use it anywhere, and
adding:
ifeq ($(with_static),yes)
conf_args += --enable-static-link
endif
to what appears to be the appropriate section gives this diff:
115,117c115,117
< LIBS = $(BUILTINS_LIB) $(LIBRARIES)
< LDFLAGS = -static $(STATIC_LD) $(LOCAL_LDFLAGS) $(PROFILE_FLAGS) $(CFLAGS)
< STATIC_LD = -static
---
> LIBS = $(BUILTINS_LIB) $(LIBRARIES) -ldl
> LDFLAGS = $(STATIC_LD) $(LOCAL_LDFLAGS) $(PROFILE_FLAGS)
> $(CFLAGS)
> STATIC_LD =
Which, oddly enough doesn't seem to build a static bash executable.
Hmmm...
--
My last cigarette was roughly 32 days, 14 hours, 7 minutes ago.
YHBW
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: