Re: [CFT] bsdinstall and zfsboot enhancements

From: Teske, Devin <Devin.Teske_at_fisglobal.com>
Date: Mon, 11 Nov 2013 20:44:15 +0000
On Nov 11, 2013, at 12:30 PM, 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=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=CRY%2BFNOe6Q01s5oKeCFeGOhE0bW%2BvEmw6GTjyy5eHFo%3D%0A&s=3e5345ea6b13f84e719068bb993b66978f1971b648b430edfde9165677c279de
>> 
>> 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=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=CRY%2BFNOe6Q01s5oKeCFeGOhE0bW%2BvEmw6GTjyy5eHFo%3D%0A&s=9ebff0354adb2634006e52cb4c0048287b7518bd7f4defe420ce5f34675ce5cd
>> (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

Is kern.console set by bhyve while NULL or unset when booting from
a physical PC (bare metal)?


> 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:
> 

Trying to think of an edge-case where they would want to force it to off.
If the kern.console setting is only expected to be set via ... help me out here...

+ bhyve ?
+ pxe ?
+ what else ?

Then maybe the secret sauce shouldn't be in /etc/ttys, but in the value that
is passed in via kern.console (that is, ... of the above ruminated technologies
which allow you to customize the value?)



> Option B
> -----------
> 
> Very similar to Option A, except only provide an automatic console using (2) and (3) if the "console" terminal is marked "on". This would increase the magic attached to "console" in /etc/ttys, but fix the problem with (A).
> 
> It's possible another approach would work as well. Does anyone have thoughts on this?

If I'm not wrong, there's a third Option C that skirts the issue by bolstering the ability
to change things for different needs.

That prior change that I had made to bsdinstall/scripts/config (iirc) was a big agressive
because it tried to automatically figure things out.

If we simply made it a choice (a scriptable one), then that would solve the problem for
the installation.

But for the LiveCD issue (Michael wants to bring up the installer's LiveCD via serial),
then perhaps we could solve it by using unionfs in the installer to make the install
environment writable (and again, change on-the-fly for different needs).

Just a thought. Tell me if it's not an option ;D I won't mind.
-- 
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.
Received on Mon Nov 11 2013 - 19:44:41 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:44 UTC