Re: HEADS UP: /bin and /sbin are now dynamically linked

Garance A Drosihn wrote:
> Another issue with adding more-and-more to /rescue ...

I am certainly not suggesting adding "more-and-more to /rescue."
The dynamic root is a new feature with as-yet-unknown failure
modes.  As we understand those failure modes, we can fine-tune
the contents of /rescue.  I'm trying to understand what
those failure modes are and what that implies about the
contents of /rescue.

I do want /rescue to be small and I want it to compile
quickly.  But I mostly want it to be useful to the people
who need it.

> I kind of like the idea of having 'vi' available, ...

I'm personally tempted to remove vi/ex from /rescue.
I originally put it in based on my experience recovering systems
where I needed to edit configure files.  But, I've not managed to
come up with a scenario where a broken config file would break /bin.
If that's the case, then vi isn't needed in /rescue, since the
purpose of /rescue is to repair a broken /bin, /sbin, /lib.  Once
those are working, you can mount /usr and have access to /usr/bin/vi.

Contrary to what David claims, I don't think /rescue does need
to support all of the recovery actions that a static /s?bin
would support.  Rather, I think it only needs to support those
recovery actions necessary to repair /bin and /sbin if they break.
That could be a very small set of tools.  It is not necessarily a
subset of /bin and /sbin, however.  Unfortunately (or fortunately,
I suppose), few people seem to have actually needed /rescue, so we as
a community don't yet have enough experience to really tailor that
toolkit.

> .... disaster scenarios
> where you won't have something you need.  For some reason, I
> manage to hit those every few months.

The only way to find out what's truly necessary in /rescue
is to pay attention to people who actually use it.  If
someone knows they'll never use it, NO_RESCUE has been shown
to measurably reduce buildworld times.

> I doubt there is any perfect answer which will satisfy
> everyone, but perhaps we can recognize that and figure out
> some flexible middle ground.

That's exactly what I'm trying to do.

Tim Kientzle