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
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
