On 11/11/13 14:44, Teske, Devin wrote:
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)?
It's set by the kernel console probe sequence and so is portable. If you
see boot messages, then it worked.
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?)
kern.console is a read-only variable (it's a struct, actually) set by
the kernel. It reflects the state of the kernel console mechanism. The
reason you might want to turn it off is if you want to use a machine
that boots over serial temporarily as a console for another one (e.g. if
a serial-only machine happens to be the only device you have with a
serial port at that particular moment). It's an unusual case, but I've
done it.
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.
I'd really prefer not to have unionfs. To begin with, our unionfs mostly
doesn't work, but my major objection is that it makes the install CDs
magical. It's hard to replicate that in the analogous situation where
you have moved a disk to a new machine or are PXE booting.
-Nathan
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
