From owner-freebsd-current@FreeBSD.ORG Sun Nov 3 21:32:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 75783C02; Sun, 3 Nov 2013 21:32:06 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from smtpauth4.wiscmail.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4129E23E8; Sun, 3 Nov 2013 21:32:05 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed; delsp=yes Received: from avs-daemon.smtpauth4.wiscmail.wisc.edu by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MVP00C00IFNZR00@smtpauth4.wiscmail.wisc.edu>; Sun, 03 Nov 2013 15:32:04 -0600 (CST) X-Spam-PmxInfo: Server=avs-4, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.3.212415, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from [10.0.2.100] (adsl-76-208-69-44.dsl.mdsnwi.sbcglobal.net [76.208.69.44]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MVP00DE1IHD4B20@smtpauth4.wiscmail.wisc.edu>; Sun, 03 Nov 2013 15:32:04 -0600 (CST) Message-id: <8594E939-F5DB-4BA3-9AC6-77C59A5E194D@freebsd.org> From: Nathan Whitehorn To: Peter Grehan In-reply-to: <52769CFE.5080707@freebsd.org> Subject: Re: [CFT] bsdinstall and zfsboot enhancements Date: Sun, 03 Nov 2013 15:32:01 -0600 References: <5275C597.6070702@freebsd.org> <97944047-D575-4E2E-B687-9871DFE058E3@fisglobal.com> <52769CFE.5080707@freebsd.org> X-Mailer: Apple Mail (2.936) Cc: Michael Dexter , Devin Teske , "Teske, Devin" , " Current" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Sun, 03 Nov 2013 21:32:06 -0000 On Nov 3, 2013, at 12:59 PM, Peter Grehan wrote: >>> Peter, can you restate the problem for Nathan so that we can >>> maybe find a better home for this change? or perhaps more clearly >>> define (than I) how we arrived at the code for the bhyve work? > > The issue is that /etc/ttys is static. Serial console installs > assume that the user knows that the file should be edited manually > to enable getty on the serial port. This seems at odds with a server > o/s :( Yes, I agree. It's a significant usability issue... > The suggestion I brought up with Devin was to see if the install was > done on a serial port, and if so, then ask if the user wanted to > enable a getty on that terminal. I think the patch might need some > work: for instance, a sysctl could be used to see if the console is > on a ttyu* device, and only enable for that and not for all ttys. I > was going to try it out this weekend but was a bit slow off the > mark :) This was something along the lines of what I was thinking. >> So I guess the real problem here is that init does not know enough to >> start a login prompt on the console. This has irritated me for a >> while >> actually. Maybe that should be fixed? The "console" entry, which >> would >> always automatically work, in /etc/ttys is marked off, which >> apparently >> happened in the runup to 4.0. It might be time to revisit that. > > That's also not good :( /dev/console is assumed to be a sink for log > messages and not really an interactive tty. Is there any way to extract the backing device via, for example, an ioctl() from /dev/console? It seems bizarre that up until the login prompt the OS can figure out where to route console messages up until the login prompt and then gets confused at that point. I'd really prefer to have the intelligence there, since all the information needed is present, rather than have the installer guess. conscontrol has the ability to get the console backing TTY device through the kern.console TTY. Maybe init could do the same trick and add whatever is in kern.console if not manually specified in /etc/ttys? -Nathan