On Mon, 2 Sep 2002, Richard Rauch wrote:

> >   The real question is, what do you gain by not crunching them?  If you
> > are afraid something will happen to /rescue, copy it.  You should be able
> > to make at least five copies in less space than the uncrunched version
>
> How is failover to be accomplished?  Is it automatic?  (I am not familiar
> with the boot process to single-user---surely some stuff must run even
> before we get to single-user, yes?  If your primary /rescue is hosed, will
> the kernel know to failover to the /rescue2, etc?  Or is single-user (up
> to the shell) running on the bare kernel and you can just edit your paths
> for /bin and /sbin?  Please forgive my ignorance on this point...(^&)

  You can have the kernel ask you for the init to use (which will then ask
you for the shell to use).  Actually, in order for my backup ls.elf_so
scheme to be effective here, you would need to be asked for the
interpreter to use as well (in both cases).  I imagine /rescue will
rarely be used at boot time anyway.

> I'd actually feel better by putting the rescue stuff on a seperate
> (bootable) partition and never normally mounting it.  This lends itself
> directly to multiple copies (even on multiple disks---or at least one on a
> distinct disk---for the truly paranoid).  It only depends upon fairly
> crude disk structure being maintained/obeyed, and upon having a working
> bootloader.

  You can easily do this if you want.  However, the most frequent need for
/rescue is installing a bad libc where all you really need to do to fix
things is to correct the symlinks.

> Well, I'm speaking for my own use, here, and hoping that it scales
> somewhat to the general case.  I use NetBSD at home and on a laptop I take
> into my office.  I use NetBSD because it behaves logically, and I like the
> goals it sets of clean code, etc.  But I am not a serious sysadmin; I've
> never been paid two bits, one thin dime, a red cent or even a plugged
> nickel, for maintaining my NetBSD systems and network.  I'm an end-user.
> (^&

  This is why I think that documentation of standard methodology is
important.  Most end users will do what the docs tell them to do.
Currently, at least the security adviosories do not seem to mention
testing new libraries before installing them.

> The problem isn't one of being able to "undo" to a safe level, but rather
> one of having something robust enough to have a good chance of working
> provided that the disk is still physically intact.

  This may be a major source of confusion.  /rescue *might* help you in
two cases: update problems and stupid admin tricks (rm /lib/ld.elf_so,
etc.).  If you just happened to get disk corruption in /lib and you want
to take a chance with same disk recovery, it might help you there too.
It can just as easily help you realize why running off a bad disk is not a
good idea.

  /rescue is cheap insurance.  It doesn't cover much, but it's cheap and
it may just come in handy some day.  If it does help you, you got lucky.
You could have just as easily damaged the system in a way it couldn't
help.  (And, yes, it is much more likely to help -current users).


> Re. your lament that people are discussing ways to improve /rescue: IMHO,

  Sorry, I should not have said that.  Your use of a new subject after the
old one died down was very helpful.  It is very difficult to clarify
anything when two hundred messages are posted in two days, which is what
I intended to refer to.

  My main point is that the single point of failure that should be worried
about is ld.elf_so, not /rescue, and that there are other things that can
*easily* be done to help prevent and recover from problems with it.


Matthew Orgass
darkstar@pgh.net