HEADS UP: /bin and /sbin are now dynamically linked
kientzle at acm.org
Mon Nov 24 12:09:01 PST 2003
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
> .... 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.
More information about the freebsd-current