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

Re: Possible ITP: Rescue Package

On Mon, 26 Jul 1999, Marcus Brinkmann wrote:

> On Mon, Jul 26, 1999 at 02:46:28PM -0400, Dale Scheetz wrote:
> > A system similar to update alternatives could be used to
> > "replace" the dynamic tools with their static counterparts,
> You mean diversions. See dpkg-divert :)

Well, actually I was hoping not to use either ;-)

> > but I don't
> > think this is a good idea, because in a normal system you don't want
> > little tools running around with big memory footprints.
> This is the only way for "init", because you can only change it at the
> bootprompt which defeats the idea (think of newbies, or remote
> administration).

I hadn't thought about init, but I guess I _do_ need to include it,
possibly as the only true replacement. There is only one copy of init
running isn't there? So it's a one time penalty? To get the benefit of
recovery, you have to install it, and yes, I guess the only way to make it
work right would be diversion, but I'd really prefer something better.

There are really two circumstances here:

1. Your system gets hosed but the kernel is still up and running, say,
from a broken libc6 upgrade. Init is already loaded, so it will keep
running just fine even though it is dynamicly linked, right? So you only
need the other utilities for this.

2. Under a hard crash, where a driver corrupts the libc6 file itself, and
dies, locking up the kernel; you have to reboot, and init will not work.
(you probably also need to be at the machine to do this, as remote isn't
likely to work at this point in the game)
You implied that there was a way to point the kernel at an alternate init.
Is this something that could be done in a lilo entry, so that a "rescue"
image and init could be isolated in this fashion?

> > Suggestions are welcome, but I just suggest that this list not get above
> > between 6 and 10 utilities, as I must pull in the sources for them all,
> > and manage their building together under the static linkage arrangement,
> > and then bundle the executables into one Debian package.
> If you want to support remote administration, you need an extra package for
> networking stuff like inetd, telnetd and such. Of course, those must be
> installed with dpkg-divert, too.

Remote administration sounds like another footprint penalty. Can the
static versions of the programs be bound to a "non-standard" rescue port,
so they only execute for that special port, while the dynamic versions run
from the "standard" locations? They could simply be given different names
and run as slightly different services. This may impact these packages,
but I should be able to add any service needed, shouldn't I?

If I can do something like this, then the size penalty is only paid when
you are actively trying to recover, and not when the system is working
properly. Does this sound possible?

Waiting is,

_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (850) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- See www.linuxpress.com for more details  _-_-_-_-_-_-_-

Reply to: