Re: [CFT] bsdinstall and zfsboot enhancements

On 11/11/13 14:57, Teske, Devin wrote:
> 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

This took much longer than I'd anticipated, but the patch to init is
attached. I chose not to make the changes to init rather than
getttyent() and friends in libc, which I am open to revisiting. The
behavior changes are as follows:

If the "console" device in /etc/ttys in marked "on", instead of opening
/dev/console, init will loop through the active kernel console devices,
and for each will:
1. If the kernel console device is in /etc/ttys and marked "on", it
already has a terminal and will be ignored.
2. If marked "off", that is an explicit statement that a console is not
wanted and so it will be ignored.
3. If not present in /etc/ttys, init will run getty with whatever
parameters "console" has.

(3) is the main behavioral change. No changes in behavior will occur if
/etc/ttys is not modified. If we turn on "console" by default, it will
usually have no effect instead of trying to run multiple gettys, which
is new. If we then also comment out the ttyu0 line, instead of marking
it "off", the result will be the conditional presence of a login prompt
on the first serial port depending on whether it is an active console
device for the kernel. I believe this is the behavior we are going for.

Comments and test results would be appreciated.
-Nathan