From owner-freebsd-current@FreeBSD.ORG Mon Nov 24 12:09:01 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 59DC716A4CE for ; Mon, 24 Nov 2003 12:09:01 -0800 (PST) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 121B543FAF for ; Mon, 24 Nov 2003 12:09:00 -0800 (PST) (envelope-from kientzle@acm.org) Received: from acm.org ([66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id hAOK8xkX047915; Mon, 24 Nov 2003 12:08:59 -0800 (PST) (envelope-from kientzle@acm.org) Message-ID: <3FC2655A.8080202@acm.org> Date: Mon, 24 Nov 2003 12:08:58 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Garance A Drosihn References: <3FBE8D92.6080205@acm.org> <20031123012222.GB11523@dragon.nuxi.com> <20031123042635.GB677@saboteur.dek.spc.org> <3FC16644.7070005@acm.org> <20031124114006.GA60761@dragon.nuxi.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: /bin and /sbin are now dynamically linked X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kientzle@acm.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2003 20:09:01 -0000 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