From owner-freebsd-arch@FreeBSD.ORG Mon Nov 11 20:43:24 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A3453286; Mon, 11 Nov 2013 20:43:24 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id 6009F25C2; Mon, 11 Nov 2013 20:43:24 +0000 (UTC) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTPS id C59CB11E42; Tue, 12 Nov 2013 06:43:22 +1000 (EST) Received: from Peter-Grehans-MacBook-Pro-2.local ([64.245.0.210]) by dommail.onthenet.com.au (MOS 4.2.4-GA) with ESMTP id BPY31834 (AUTH peterg@ptree32.com.au); Tue, 12 Nov 2013 06:43:20 +1000 Message-ID: <52814166.4040105@freebsd.org> Date: Mon, 11 Nov 2013 12:43:18 -0800 From: Peter Grehan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Nathan Whitehorn , Devin Teske , Michael Dexter Subject: Re: [CFT] bsdinstall and zfsboot enhancements References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> <5281340E.8080009@callfortesting.org> <52813E53.20403@freebsd.org> In-Reply-To: <52813E53.20403@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Current Current , "Teske, Devin" , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:43:24 -0000 Hi Nathan, > I think modifying init is the way to go -- it keeps the install system > from interfering with the installed one, as well as fixing this kind of > issue with moved hard drives or PXE booting or what have you. I now agree with this :) Modifying /etc/ttys at install time doesn't work for a lot of cases, LiveCD being the most obvious. > I would propose one of the following (and volunteer to write the code): > > Option A > ------------ > > 1. init checks if there is an entry in /etc/ttys for the terminal[s] > corresponding to the value[s] in kern.console > 2. If an entry for each console terminal exists in /etc/ttys, enable it > 3. If not, invent one with a terminal type of "ansi" > > The one issue here is that someone may want to force a particular entry > to off and still have it be the kernel console. This is tricky. We could > invent a new "status" field that is not "on" or "off" ("auto", maybe, or > "ifconsole"?). Which brings us to: I'd guess that this mode is really a once-off thing - for a live CD, init could ask the user if they want a getty spawned on this tty similar to asking for a shell in single-user mode. Presumably post-install the user would have edited the ttys file and init would then be able to locate the entry and not have to prompt. later, Peter.