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. -NathanReceived on Mon Nov 11 2013 - 19:48:24 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:44 UTC