[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
ifeq ($(with_static),yes)
     conf_args += --enable-static-link

    to what appears to be the appropriate section gives this diff:
< STATIC_LD = -static

    Which, oddly enough doesn't seem to build a static bash executable. 


My last cigarette was roughly 32 days, 14 hours, 7 minutes ago.

To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: