[CFT] bsdinstall and zfsboot enhancements

[Teske, Devin]

On Nov 11, 2013, at 12:54 PM, Nathan Whitehorn wrote:

> On 11/11/13 14:30, Nathan Whitehorn wrote:
>> On 11/11/13 14:18, Teske, Devin wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA512
>>> 
>>> 
>>> On Nov 11, 2013, at 11:46 AM, Michael Dexter wrote:
>>> 
>>> 
>>> Hello all,
>>> 
>>> I have been experimenting with various BSD and GNU/Linux boot media
>>> under bhyve and noticed that we may want to accommodate the "LiveCD"
>>> mode of the installer, which in turn requires the correct console.
>>> 
>>> Currently, one is prompted for VT100 for installation but this does not
>>> appear to work/stick for LiveCD mode.
>>> 
>>> Can anyone verify this?
>>> 
>>> 
>>> While I developed this patch...
>>> https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/usr.sbin%253A%253Absdinstall%253A%253Ascripts%253A%253Aconfig.patch?revision%3D1.10%26view%3Dmarkup&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=aZg%2BxwqLTX6Zcpf3Rc44iPtAQhFrpqoS4FC5B8ykxJQ%3D%0A&s=6d54d337ea5472f5713ddbe7788d3248c45feefd4b291eab0a976c39e9d40428 
>>> 
>>> Reasons exist to search for a better solution, see here:
>>> https://urldefense.proofpoint.com/v1/url?u=http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046148.html&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=aZg%2BxwqLTX6Zcpf3Rc44iPtAQhFrpqoS4FC5B8ykxJQ%3D%0A&s=5f8128901747346f937ffc4478eadb4bc39059504258dfb9b36f0fb9e7a61b79 
>>> (and messages that follow it)
>>> 
>>> Is modifying init(8) still the way to go? What modification do we want to make?
>>> I'll do the work if we can come to consensus.
>>> 
>>> Or should we touch up the patch in some way to address the original concerns?
>>> 
>> 
>> 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. If we can provide a guarantee that any system that displays text has a working console (unless explicitly configured not to), useability is improved.
>> 
>> 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:
> 
> One easy way to accomplish this is just to only implement (1) and (3), then comment out the ttyu0 entry in /etc/ttys on x86 instead of marking it "off". Then the behavior is just that a tty marked "off" stays off, one marked "on" stays on, and one not present spawns login with a terminal type corresponding to "console" (by default "unknown") if it happens to be the console. I will implement this over the next few days and then send patches unless anyone has an objection.

I love it. (smiles)

Excellent idea and that's the winner I think.

+1
-- 
Devin

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.