From owner-freebsd-current@FreeBSD.ORG Mon Nov 24 03:40:11 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 928A816A4CE for ; Mon, 24 Nov 2003 03:40:11 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9201843F93 for ; Mon, 24 Nov 2003 03:40:10 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.9) with ESMTP id hAOBe7vX060841; Mon, 24 Nov 2003 03:40:07 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.10/8.12.10/Submit) id hAOBe6Au060840; Mon, 24 Nov 2003 03:40:06 -0800 (PST) (envelope-from obrien) Date: Mon, 24 Nov 2003 03:40:06 -0800 From: "David O'Brien" To: Tim Kientzle Message-ID: <20031124114006.GA60761@dragon.nuxi.com> References: <3FBE8D92.6080205@acm.org> <20031123012222.GB11523@dragon.nuxi.com> <20031123042635.GB677@saboteur.dek.spc.org> <3FC16644.7070005@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FC16644.7070005@acm.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-BETA Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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: freebsd-current@freebsd.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 11:40:11 -0000 On Sun, Nov 23, 2003 at 06:00:36PM -0800, Tim Kientzle wrote: > Scenarios that require /rescue are ones in which /bin and /sbin > are unusable, which is almost always going to imply a trashed file > in /bin, /sbin, or /lib. Thus, most /rescue scenarios are going to > involve locating a good copy of a trashed file to replace a damaged > local copy. NO. /rescue was allowed in the system to handle the case of a trashed file in /lib[exec]. To allow a sysadmin to recover a system from the same type of mishaps they could before we went to a dynamic /. Not to continue to add to /rescue until the sysadmin could recover from every conceivable way of trashing a system. /rescue was not to become the all-in-compassing Swiss Army recover tool. We provide the Live-FS CD (disc 2) for that. > I can only think of a few places where that "good copy" > can come from: > * CDROM: requires a CD-ROM drive, and a suitable CD. > * floppy: requires a floppy drive > * NFS: requires a local network and an NFS server > * An HTTP or FTP server: requires a network connection and 'fetch.' > > I don't think we can safely assume that everyone has access to > one of the first three options here. We have made the assumption for the first three options since day one. Why should we change the assumptions just because we now have a dynamic /?