From owner-freebsd-current@FreeBSD.ORG Fri Mar 5 13:41:26 2004 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 F04ED16A4CF; Fri, 5 Mar 2004 13:41:25 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD9C443D46; Fri, 5 Mar 2004 13:41:25 -0800 (PST) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i25LfP9Q038443; Fri, 5 Mar 2004 13:41:25 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i25LfPEk038442; Fri, 5 Mar 2004 13:41:25 -0800 (PST) (envelope-from rizzo) Date: Fri, 5 Mar 2004 13:41:25 -0800 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20040305134125.A37156@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Mailman-Approved-At: Sat, 06 Mar 2004 04:49:13 -0800 Subject: initdiskless/rc.diskless1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2004 21:41:26 -0000 Hi, as usual at this time of the year (starting heavy diskless usage in the labs) i am revising the diskless startup files. As those interested know, directories in the client's root can be filled from a cpio archive, or missing that, by copying one of the server's directory. This has been changed in rev 1.17 to always use both (the directory first, the cpio archive after). I would like to rever this back to the old method, with the following motivation: + i introduced the cpio archive hack because in some cases (e.g. paths with large delays), the separate NFS transactions for each file was extremely time consuming. + (less important) having files coming from two places makes it harder to figure out where a given piece of the configuration comes from. Any objection ? Also, I have one (rather trivial) patch that plan to commit, which lets you specify extra paths in /conf/ to fetch the configuration using the T134 bootp tag (available as kern.bootp_cookie). The tag could e.g. contain a name for client classes, boxes with different hardware, etc., making the configuration a lot more flexible. E.g. T134="lab3 nvidia config6" objections to this one too ? cheers luigi