Re: [CFT] bsdinstall and zfsboot enhancements

[Jilles Tjoelker]

On Sun, Jan 05, 2014 at 04:04:03PM -0500, Nathan Whitehorn wrote:
 On 12/01/13 07:34, Jilles Tjoelker wrote:
  On Sat, Nov 30, 2013 at 04:36:18PM -0600, Nathan Whitehorn wrote:
  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.
  lib/libpam/modules/pam_securetty/pam_securetty.c calls getttynam(3) and
  will not allow root login on a fake TTY that getttynam() does not
  know. This module is enabled by default for the login service.

  So it is probably better to patch libc rather than init.

 OK, here's a revised patch. This one is shorter and works by introducing
 an auto flag (ideas for names appreciated) that means on if the line
 is an active console and off otherwise. Note that the behavior is now:
 - ttys marked off stay off
 - ttys marked on stay on
 - ttys marked auto are enabled iff they are console devices
 - ttys not present in /etc/ttys stay off

 This behavior change is much easier to implement when doing it in libc
 for various structural reasons and allows the terminal type, etc. to be
 specified in the usual way.

Instead of auto you could use ifconsole.

This looks sensible to me.

  As a preparatory patch, you could remove se_index and session_index from
  init. They are only used to warn about a changed slot number in utmp(5)
  which is irrelevant with utmpx. This noise warning would also appear
  in most cases when changing from a fake console entry to a real line
  in /etc/ttys. Also, if you do decide to fake ttys entries in init rather
  than libc, the patch to init will be simpler.

 With the new patch, this is indeed the case: no changes to init are
 necessary at all. This does not change any behavior unless explicitly
 requested in /etc/ttys, so unless there are any objections in the next
 couple days, I will commit it.

I have some small remarks inline below.

I would like to remove se_index and session_index from init soon if it
does not conflict with other work.

 Index: include/ttyent.h
 ===
 --- include/ttyent.h  (revision 260331)
 +++ include/ttyent.h  (working copy)
 @@ -37,6 +37,7 @@
  
  #define  _TTYS_OFF   off
  #define  _TTYS_ONon
 +#define  _TTYS_AUTO  auto
  #define  _TTYS_SECUREsecure
  #define  _TTYS_INSECURE  insecure
  #define  _TTYS_WINDOWwindow
 Index: lib/libc/gen/getttyent.c
 ===
 --- lib/libc/gen/getttyent.c  (revision 260331)
 +++ lib/libc/gen/getttyent.c  (working copy)
 @@ -39,6 +39,9 @@
  #include ctype.h
  #include string.h
  
 +#include sys/types.h
 +#include sys/sysctl.h
 +
  static char zapchar;
  static FILE *tf;
  static size_t lbsize;
 @@ -64,6 +67,32 @@
   return (t);
  }
  
 +static int
 +auto_tty_status(const char *ty_name)
 +{
 + size_t len;
 + char *buf, *cons, *nextcons;
 +
 + /* Check if this is an enabled kernel console line */
 + buf = NULL;
 + if (sysctlbyname(kern.console, NULL, len, NULL, 0) == -1)
 + return (0); /* Errors mean don't enable */
 + buf = malloc(len);
 + if (sysctlbyname(kern.console, buf, len, NULL, 0) == -1)
 + return (0);

conscontrol also does this, but is it possible that the length increases
between the checks?

 +
 + if ((cons = strchr(buf, '/')) == NULL)
 + return (0);
 + *cons = '\0';
 + nextcons = buf;
 + while ((cons = strsep(nextcons, ,)) != NULL  strlen(cons) != 0) {
 + if (strcmp(cons, ty_name) == 0)
 + return (TTY_ON);
 + }
 +
 + return (0);
 +}
 +
  struct ttyent *
  getttyent(void)
  {
 @@ -126,6 +155,8 @@
   tty.ty_status = ~TTY_ON;
   else if (scmp(_TTYS_ON))
   tty.ty_status |= TTY_ON;
 + else if (scmp(_TTYS_AUTO))
 + tty.ty_status |= auto_tty_status(tty.ty_name);
   else if (scmp(_TTYS_SECURE))
   tty.ty_status |= TTY_SECURE;
   else if (scmp(_TTYS_INSECURE))
 Index: libexec/getty/ttys.5
 ===
 --- libexec/getty/ttys.5  (revision 260331)
 +++ libexec/getty/ttys.5  (working copy)
 @@ -102,8 +102,11 @@
  .Pp
  As flag values, the strings ``on'' and ``off'' specify that
  .Xr init 8
 -should (should not) execute the command given in the second field,
 -while ``secure'' (if ``on'' is also specified) allows users with a
 +should (should not) execute the command given in the second field.
 +``auto'' will cause this line to be enabled if and only if it is
 +an active kernel console device (it is equivalent to ``on'' in this
 +case).
 +The flag ``secure'' (if ``on'' is also specified) allows users with a

Please change if ``on'' is also specified to something like if the

Re: [CFT] bsdinstall and zfsboot enhancements

[Michael Dexter]

On 1/5/14 1:04 PM, Nathan Whitehorn wrote:
 On 12/01/13 07:34, Jilles Tjoelker wrote:
 On Sat, Nov 30, 2013 at 04:36:18PM -0600, Nathan Whitehorn wrote:
 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.
 lib/libpam/modules/pam_securetty/pam_securetty.c calls getttynam(3) and
 will not allow root login on a fake TTY that getttynam() does not
 know. This module is enabled by default for the login service.

 So it is probably better to patch libc rather than init.
 
 OK, here's a revised patch. This one is shorter and works by introducing
 an auto flag (ideas for names appreciated) that means on if the line
 is an active console and off otherwise. Note that the behavior is now:
 - ttys marked off stay off
 - ttys marked on stay on
 - ttys marked auto are enabled iff they are console devices
 - ttys not present in /etc/ttys stay off
 
 This behavior change is much easier to implement when doing it in libc
 for various structural reasons and allows the terminal type, etc. to be
 specified in the usual way.
 
 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.
 This seems to make sense.

 (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.
 The terminal type for the console entry should probably be changed to
 something other than unknown to reduce annoyance.

 Comments and test results would be appreciated.
 As a preparatory patch, you could remove se_index and session_index from
 init. They are only used to warn about a changed slot number in utmp(5)
 which is irrelevant with utmpx. This noise warning would also appear
 in most cases when changing from a fake console entry to a real line
 in /etc/ttys. Also, if you do decide to fake ttys entries in init rather
 than libc, the patch to init will be simpler.

 
 With the new patch, this is indeed the case: no changes to init are
 necessary at all. This does not change any behavior unless explicitly
 requested in /etc/ttys, so unless there are any objections in the next
 couple days, I will commit it.
 -Nathan

Hello all,

Not sure if everyone knows that Nathan posted a patched 11-current ISO:

http://people.freebsd.org/~nwhitehorn/auto-console.iso

I have fetched and booted to this with my iso mode in my scripts and
IT WORKS. Install from ISO and boot as normal. Only glitch which I
haven't seen for some time: The resulting guest console is shortened by
one line with this persistent string at the bottom:

/boot/kernel/kernel text=0xf45a98 data=  syms= ...

This persists after VM reboot, goes away with bhyveload and returns for
the next VM boot.

Okay, a second glitch upon second boot. The root prompt reads:

login: Jan  6 time console getty[792]: open /dev/ttyv2: No such file
or directory

This passes with ENTER and I can log in a normal, with the same string
pinned to the bottom.

Getting there!

Michael
___
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

Automatic enabling of serial console (was: [CFT] bsdinstall and zfsboot enhancements)

[Nathan Whitehorn]

On 01/06/14 18:36, Michael Dexter wrote:
 On 1/5/14 1:04 PM, Nathan Whitehorn wrote:
 On 12/01/13 07:34, Jilles Tjoelker wrote:
 On Sat, Nov 30, 2013 at 04:36:18PM -0600, Nathan Whitehorn wrote:
 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.
 lib/libpam/modules/pam_securetty/pam_securetty.c calls getttynam(3) and
 will not allow root login on a fake TTY that getttynam() does not
 know. This module is enabled by default for the login service.

 So it is probably better to patch libc rather than init.
 OK, here's a revised patch. This one is shorter and works by introducing
 an auto flag (ideas for names appreciated) that means on if the line
 is an active console and off otherwise. Note that the behavior is now:
 - ttys marked off stay off
 - ttys marked on stay on
 - ttys marked auto are enabled iff they are console devices
 - ttys not present in /etc/ttys stay off

 This behavior change is much easier to implement when doing it in libc
 for various structural reasons and allows the terminal type, etc. to be
 specified in the usual way.

 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.
 This seems to make sense.

 (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.
 The terminal type for the console entry should probably be changed to
 something other than unknown to reduce annoyance.

 Comments and test results would be appreciated.
 As a preparatory patch, you could remove se_index and session_index from
 init. They are only used to warn about a changed slot number in utmp(5)
 which is irrelevant with utmpx. This noise warning would also appear
 in most cases when changing from a fake console entry to a real line
 in /etc/ttys. Also, if you do decide to fake ttys entries in init rather
 than libc, the patch to init will be simpler.

 With the new patch, this is indeed the case: no changes to init are
 necessary at all. This does not change any behavior unless explicitly
 requested in /etc/ttys, so unless there are any objections in the next
 couple days, I will commit it.
 -Nathan
 Hello all,

 Not sure if everyone knows that Nathan posted a patched 11-current ISO:

 http://people.freebsd.org/~nwhitehorn/auto-console.iso

 I have fetched and booted to this with my iso mode in my scripts and
 IT WORKS. 

Great!

 Install from ISO and boot as normal. Only glitch which I
 haven't seen for some time: The resulting guest console is shortened by
 one line with this persistent string at the bottom:

 /boot/kernel/kernel text=0xf45a98 data=  syms= ...

Weird... hard to know what's going on there.

 This persists after VM reboot, goes away with bhyveload and returns for
 the next VM boot.

 Okay, a second glitch upon second boot. The root prompt reads:

 login: Jan  6 time console getty[792]: open /dev/ttyv2: No such file
 or directory

 This passes with ENTER and I can log in a normal, with the same string
 pinned to the bottom.


This is just that all the syscons VTYs are unconditionally enabled but
aren't present if you don't actually have a graphics card. ttyv0 could
also be marked auto (though if it exists at all, you probably want a
console there), but ttvy[0] are not console devices. I'm not sure
whether it makes sense to make init have quiet errors in this case or
just to live with an irritating message on serial-only systems that can
be turned off by an edit to /etc/tttys.
-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

Re: [CFT] bsdinstall and zfsboot enhancements

[Nathan Whitehorn]

On 12/01/13 07:34, Jilles Tjoelker wrote:
 On Sat, Nov 30, 2013 at 04:36:18PM -0600, Nathan Whitehorn wrote:
 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.
 lib/libpam/modules/pam_securetty/pam_securetty.c calls getttynam(3) and
 will not allow root login on a fake TTY that getttynam() does not
 know. This module is enabled by default for the login service.

 So it is probably better to patch libc rather than init.

OK, here's a revised patch. This one is shorter and works by introducing
an auto flag (ideas for names appreciated) that means on if the line
is an active console and off otherwise. Note that the behavior is now:
- ttys marked off stay off
- ttys marked on stay on
- ttys marked auto are enabled iff they are console devices
- ttys not present in /etc/ttys stay off

This behavior change is much easier to implement when doing it in libc
for various structural reasons and allows the terminal type, etc. to be
specified in the usual way.

 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.
 This seems to make sense.

 (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.
 The terminal type for the console entry should probably be changed to
 something other than unknown to reduce annoyance.

 Comments and test results would be appreciated.
 As a preparatory patch, you could remove se_index and session_index from
 init. They are only used to warn about a changed slot number in utmp(5)
 which is irrelevant with utmpx. This noise warning would also appear
 in most cases when changing from a fake console entry to a real line
 in /etc/ttys. Also, if you do decide to fake ttys entries in init rather
 than libc, the patch to init will be simpler.


With the new patch, this is indeed the case: no changes to init are
necessary at all. This does not change any behavior unless explicitly
requested in /etc/ttys, so unless there are any objections in the next
couple days, I will commit it.
-Nathan
Index: include/ttyent.h
===
--- include/ttyent.h(revision 260331)
+++ include/ttyent.h(working copy)
@@ -37,6 +37,7 @@
 
 #define_TTYS_OFF   off
 #define_TTYS_ONon
+#define_TTYS_AUTO  auto
 #define_TTYS_SECUREsecure
 #define_TTYS_INSECURE  insecure
 #define_TTYS_WINDOWwindow
Index: lib/libc/gen/getttyent.c
===
--- lib/libc/gen/getttyent.c(revision 260331)
+++ lib/libc/gen/getttyent.c(working copy)
@@ -39,6 +39,9 @@
 #include ctype.h
 #include string.h
 
+#include sys/types.h
+#include sys/sysctl.h
+
 static char zapchar;
 static FILE *tf;
 static size_t lbsize;
@@ -64,6 +67,32 @@
return (t);
 }
 
+static int
+auto_tty_status(const char *ty_name)
+{
+   size_t len;
+   char *buf, *cons, *nextcons;
+
+   /* Check if this is an enabled kernel console line */
+   buf = NULL;
+   if (sysctlbyname(kern.console, NULL, len, NULL, 0) == -1)
+   return (0); /* Errors mean don't enable */
+   buf = malloc(len);
+   if (sysctlbyname(kern.console, buf, len, NULL, 0) == -1)
+   return (0);
+
+   if ((cons = strchr(buf, '/')) == NULL)
+   return (0);
+   *cons = '\0';
+   nextcons = buf;
+   while ((cons = strsep(nextcons, ,)) != NULL  strlen(cons) != 0) {
+   if (strcmp(cons, ty_name) == 0)
+   return (TTY_ON);
+   }
+
+   return (0);
+}
+
 struct ttyent *
 getttyent(void)
 {
@@ -126,6 +155,8 @@
tty.ty_status = ~TTY_ON;
else if (scmp(_TTYS_ON))
tty.ty_status |= TTY_ON;
+   else if (scmp(_TTYS_AUTO))
+   tty.ty_status |= auto_tty_status(tty.ty_name);
else if (scmp(_TTYS_SECURE))
tty.ty_status |= TTY_SECURE;
else 

Re: [CFT] bsdinstall and zfsboot enhancements

[Jilles Tjoelker]

On Sat, Nov 30, 2013 at 04:36:18PM -0600, Nathan Whitehorn wrote:
 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.

lib/libpam/modules/pam_securetty/pam_securetty.c calls getttynam(3) and
will not allow root login on a fake TTY that getttynam() does not
know. This module is enabled by default for the login service.

So it is probably better to patch libc rather than init.

 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.

This seems to make sense.

 (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.

The terminal type for the console entry should probably be changed to
something other than unknown to reduce annoyance.

 Comments and test results would be appreciated.

As a preparatory patch, you could remove se_index and session_index from
init. They are only used to warn about a changed slot number in utmp(5)
which is irrelevant with utmpx. This noise warning would also appear
in most cases when changing from a fake console entry to a real line
in /etc/ttys. Also, if you do decide to fake ttys entries in init rather
than libc, the patch to init will be simpler.

-- 
Jilles Tjoelker
___
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

Re: [CFT] bsdinstall and zfsboot enhancements

[Nathan Whitehorn]

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%3Dmarkupk=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0Am=aZg%2BxwqLTX6Zcpf3Rc44iPtAQhFrpqoS4FC5B8ykxJQ%3D%0As=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.htmlk=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0Am=aZg%2BxwqLTX6Zcpf3Rc44iPtAQhFrpqoS4FC5B8ykxJQ%3D%0As=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
Index: init.c
===
--- init.c  (revision 258756)
+++ init.c  (working copy)
@@ -1102,22 +1102,84 @@
 }
 
 /*
+ * Do something for all defined TTYs
+ */
+static void
+do_allttys(void (*callback)(struct ttyent *, void *), void *cookie)
+{
+   struct ttyent *typ;
+   char *buf, *cons, *nextcons;
+   size_t len;
+
+   /* Loop through /etc/ttys */
+   while ((typ = getttyent()) != NULL) {
+   if (strcmp(typ-ty_name, console) == 0)
+   

Re: [CFT] bsdinstall and zfsboot enhancements

[Johan Hendriks]

Teske, Devin schreef:

Hi all,

Another Call For Testing...
This one is for bsdinstall.

Two patchsets are required for this CFT:

http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_debug/
http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/

The enhancements are:

+ Add a `-D FILE command-line option for overriding the
path to the bsdinstall log file (BSDINSTALL_LOG env var).

+ Document new `-D FILE' in the man page for bsdinstall.

+ If FILE in `-D FILE' begins with a +, debug output goes to
stdout (interleaved between dialog(1) invocations/output) as
well as to FILE (minus the leading + of course).

+ If BSDINSTALL_LOG cannot be written, then debugging is
disabled (except in the case of a leading + in the pathname,
wherein debug will still be printed to stdout).

+ Update source code format to approximate a future shstyle(9)

+ Fix a dangling participle (Begun ... - Began ...)

+ Rewrite the docsinstall script (was necessary to abate direct
dependency on BSDINSTALL_LOG (instead, use fault-tolerant
bsdconfig framework which displays appropriate errors for
package management).

+ Add additional debug output for dhclient/rtsol/wpa_cliscan

+ Display script errors in a textbox rather than just on stdout

+ Update many coments.

+ Add new f_show_err() API call (like f_show_msg but changes
the dialog title to Error)(see bsdconfig's `common.subr').

+ Add new f_eval_catch() API call for executing a command via
eval but not before logging the command to debug. Several
example cases documented in API header for function in
bsdconfig's `common.subr'.

+ Fix dialog auto-sizing when launched as an rvalue to a pipe
for indirected scripts (previously would default to 80x24 sizing
in this case, now it can autosize to full size even when in a pipe
chain).

+ Fix a bug in f_snprintf wherein if the $format argument began
with a - or -- it would be misinterpreted as a flag to printf. (this
is in bsdcofig's strings.subr)

+ Add accompanying f_sprintf() and f_vsprintf() to go along with
already existing f_snprintf() and f_vsnprintf() (see bsdconfig's
strings.subr).

+ Update bsdinstall's config script to adjust ttyu* entries in
/etc/ttys when it is determined that we are in-fact doing an install
over serial (e.g. bhyve).

+ Remove some unnecessary default ZFS datasets from the
automatic zfsboot script. Such as: /usr/ports/distfiles
/usr/ports/packages /usr/obj /var/db /var/empty /var/mail and
/var/run (these can all be created as-needed once the system is
installed).

+ Remove setuid=off for /usr/home (as discussed with others from
last round of CFT).

+ Fix some i18n string violations in zfsboot

+ Bolster debugging output in zfsboot

+ Fix some string quoting issues in zfsboot

+ Fix some variable scope issues in zfsboot

+ Only display the ZFS vdev type selection menu when running
interactively (duh).

+ Change Create to Install in zfsboot main menu

+ Increase pedantic error checking in zfsboot (type-check
arguments and such).

+ Add a call to graid destroy to kill automatic metadata (part of
the series of pedantic destructions we do when bootstrapping
a new/naked disk).

+ Make judicious use of new f_eval_catch() in zfsboot

+ More comments (zfsboot).

+ Fixup some variable names for consistency (zfsboot).

I did not try this installer myself, but one question, can i seperate 
the swap space from the pool?

I have seen to many strange hangs on a server where i use swap on zfs!

regards
Johan
___
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

Re: [CFT] bsdinstall and zfsboot enhancements

[Teske, Devin]

On Nov 12, 2013, at 4:02 AM, Johan Hendriks wrote:

 Teske, Devin schreef:
 Hi all,
 
 Another Call For Testing...
 This one is for bsdinstall.
 
 Two patchsets are required for this CFT:
 
 http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_debug/
 http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/
 
 The enhancements are:
 
 + Add a `-D FILE command-line option for overriding the
 path to the bsdinstall log file (BSDINSTALL_LOG env var).
 
 + Document new `-D FILE' in the man page for bsdinstall.
 
 + If FILE in `-D FILE' begins with a +, debug output goes to
 stdout (interleaved between dialog(1) invocations/output) as
 well as to FILE (minus the leading + of course).
 
 + If BSDINSTALL_LOG cannot be written, then debugging is
 disabled (except in the case of a leading + in the pathname,
 wherein debug will still be printed to stdout).
 
 + Update source code format to approximate a future shstyle(9)
 
 + Fix a dangling participle (Begun ... - Began ...)
 
 + Rewrite the docsinstall script (was necessary to abate direct
 dependency on BSDINSTALL_LOG (instead, use fault-tolerant
 bsdconfig framework which displays appropriate errors for
 package management).
 
 + Add additional debug output for dhclient/rtsol/wpa_cliscan
 
 + Display script errors in a textbox rather than just on stdout
 
 + Update many coments.
 
 + Add new f_show_err() API call (like f_show_msg but changes
 the dialog title to Error)(see bsdconfig's `common.subr').
 
 + Add new f_eval_catch() API call for executing a command via
 eval but not before logging the command to debug. Several
 example cases documented in API header for function in
 bsdconfig's `common.subr'.
 
 + Fix dialog auto-sizing when launched as an rvalue to a pipe
 for indirected scripts (previously would default to 80x24 sizing
 in this case, now it can autosize to full size even when in a pipe
 chain).
 
 + Fix a bug in f_snprintf wherein if the $format argument began
 with a - or -- it would be misinterpreted as a flag to printf. (this
 is in bsdcofig's strings.subr)
 
 + Add accompanying f_sprintf() and f_vsprintf() to go along with
 already existing f_snprintf() and f_vsnprintf() (see bsdconfig's
 strings.subr).
 
 + Update bsdinstall's config script to adjust ttyu* entries in
 /etc/ttys when it is determined that we are in-fact doing an install
 over serial (e.g. bhyve).
 
 + Remove some unnecessary default ZFS datasets from the
 automatic zfsboot script. Such as: /usr/ports/distfiles
 /usr/ports/packages /usr/obj /var/db /var/empty /var/mail and
 /var/run (these can all be created as-needed once the system is
 installed).
 
 + Remove setuid=off for /usr/home (as discussed with others from
 last round of CFT).
 
 + Fix some i18n string violations in zfsboot
 
 + Bolster debugging output in zfsboot
 
 + Fix some string quoting issues in zfsboot
 
 + Fix some variable scope issues in zfsboot
 
 + Only display the ZFS vdev type selection menu when running
 interactively (duh).
 
 + Change Create to Install in zfsboot main menu
 
 + Increase pedantic error checking in zfsboot (type-check
 arguments and such).
 
 + Add a call to graid destroy to kill automatic metadata (part of
 the series of pedantic destructions we do when bootstrapping
 a new/naked disk).
 
 + Make judicious use of new f_eval_catch() in zfsboot
 
 + More comments (zfsboot).
 
 + Fixup some variable names for consistency (zfsboot).
 
 I did not try this installer myself, but one question, can i seperate the 
 swap space from the pool?
 I have seen to many strange hangs on a server where i use swap on zfs!
 

If I understand correctly, it does this by default.
-- 
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.
___
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

Re: [CFT] bsdinstall and zfsboot enhancements

[Allan Jude]

On 2013-11-12 14:11, Teske, Devin wrote:
 On Nov 12, 2013, at 4:02 AM, Johan Hendriks wrote:

 Teske, Devin schreef:
 Hi all,

 Another Call For Testing...
 This one is for bsdinstall.

 Two patchsets are required for this CFT:

 http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_debug/
 http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/

 The enhancements are:

 + Add a `-D FILE command-line option for overriding the
 path to the bsdinstall log file (BSDINSTALL_LOG env var).

 + Document new `-D FILE' in the man page for bsdinstall.

 + If FILE in `-D FILE' begins with a +, debug output goes to
 stdout (interleaved between dialog(1) invocations/output) as
 well as to FILE (minus the leading + of course).

 + If BSDINSTALL_LOG cannot be written, then debugging is
 disabled (except in the case of a leading + in the pathname,
 wherein debug will still be printed to stdout).

 + Update source code format to approximate a future shstyle(9)

 + Fix a dangling participle (Begun ... - Began ...)

 + Rewrite the docsinstall script (was necessary to abate direct
 dependency on BSDINSTALL_LOG (instead, use fault-tolerant
 bsdconfig framework which displays appropriate errors for
 package management).

 + Add additional debug output for dhclient/rtsol/wpa_cliscan

 + Display script errors in a textbox rather than just on stdout

 + Update many coments.

 + Add new f_show_err() API call (like f_show_msg but changes
 the dialog title to Error)(see bsdconfig's `common.subr').

 + Add new f_eval_catch() API call for executing a command via
 eval but not before logging the command to debug. Several
 example cases documented in API header for function in
 bsdconfig's `common.subr'.

 + Fix dialog auto-sizing when launched as an rvalue to a pipe
 for indirected scripts (previously would default to 80x24 sizing
 in this case, now it can autosize to full size even when in a pipe
 chain).

 + Fix a bug in f_snprintf wherein if the $format argument began
 with a - or -- it would be misinterpreted as a flag to printf. (this
 is in bsdcofig's strings.subr)

 + Add accompanying f_sprintf() and f_vsprintf() to go along with
 already existing f_snprintf() and f_vsnprintf() (see bsdconfig's
 strings.subr).

 + Update bsdinstall's config script to adjust ttyu* entries in
 /etc/ttys when it is determined that we are in-fact doing an install
 over serial (e.g. bhyve).

 + Remove some unnecessary default ZFS datasets from the
 automatic zfsboot script. Such as: /usr/ports/distfiles
 /usr/ports/packages /usr/obj /var/db /var/empty /var/mail and
 /var/run (these can all be created as-needed once the system is
 installed).

 + Remove setuid=off for /usr/home (as discussed with others from
 last round of CFT).

 + Fix some i18n string violations in zfsboot

 + Bolster debugging output in zfsboot

 + Fix some string quoting issues in zfsboot

 + Fix some variable scope issues in zfsboot

 + Only display the ZFS vdev type selection menu when running
 interactively (duh).

 + Change Create to Install in zfsboot main menu

 + Increase pedantic error checking in zfsboot (type-check
 arguments and such).

 + Add a call to graid destroy to kill automatic metadata (part of
 the series of pedantic destructions we do when bootstrapping
 a new/naked disk).

 + Make judicious use of new f_eval_catch() in zfsboot

 + More comments (zfsboot).

 + Fixup some variable names for consistency (zfsboot).

 I did not try this installer myself, but one question, can i seperate the 
 swap space from the pool?
 I have seen to many strange hangs on a server where i use swap on zfs!

 If I understand correctly, it does this by default.

Yes, the zfsboot script in bsdinstall creates a raw swap partition, it
does not use swap-on-zfs

-- 
Allan Jude




signature.asc
Description: OpenPGP digital signature

RE: [CFT] bsdinstall and zfsboot enhancements

[dteske]

 -Original Message-
 From: Michael Dexter [mailto:edi...@callfortesting.org]
 Sent: Tuesday, November 12, 2013 11:25 AM
 To: Devin Teske
 Cc: Teske, Devin; Peter Grehan; Nathan Whitehorn; Current Current
 Subject: Re: [CFT] bsdinstall and zfsboot enhancements
 
 On 11/11/13 1:01 PM, Teske, Devin wrote:
   It doesn't touch the timeout code - should be whatever FreeBSD loader
 forth scripts tell it to do.
  
  Ah, must have been something Michael did. I noticed this whilst getting
  demos from him on his laptop.
 
 Please clarify. What specifically?
 

When the boot menu comes up, it counts down to from 5, 4, 3, ...
Instead of 9, 8, 7, ...

Sounds like autoboot_delay is modified... in the installed distro?
Did you script that or do it by hand? in loader.conf? in the VM?

Just curious.
-- 
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.
___
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

Re: [CFT] bsdinstall and zfsboot enhancements

[Michael Dexter]

On 11/11/13 1:01 PM, Teske, Devin wrote:
  It doesn't touch the timeout code - should be whatever FreeBSD loader 
  forth scripts tell it to do.
  
 Ah, must have been something Michael did. I noticed this whilst getting
 demos from him on his laptop.

Please clarify. What specifically?

Michael
___
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

Re: [CFT] bsdinstall and zfsboot enhancements

[Michael Dexter]

On 11/12/13 12:22 PM, dte...@freebsd.org wrote:
 When the boot menu comes up, it counts down to from 5, 4, 3, ...
 Instead of 9, 8, 7, ...
 
 Sounds like autoboot_delay is modified... in the installed distro?
 Did you script that or do it by hand? in loader.conf? in the VM?
 
 Just curious.

Good eye!

My scripts have been throwing in autoboot_delay=5 to short the time
between load an potential kernel panic. No fun when the countdown was
the longest part for the whole process. :)

Michael

___
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

Re: [CFT] bsdinstall and zfsboot enhancements

[Teske, Devin]

-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...
http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/usr.sbin%3A%3Absdinstall%3A%3Ascripts%3A%3Aconfig.patch?revision=1.10view=markup

Reasons exist to search for a better solution, see here:
http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046148.html
(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?
- -- 
Devin
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJSgTuCAAoJEKrMn5R9npq5M90H/RrIhOqhCAPj9lyG9ElM6NlC
G2EDyajzIqntzOQY6O9AZXl+CrKndMkOAthOAYBfWTXCIKV0J5tlV167Gmfm25tZ
GQpJkneOiHwMuhj7Fe0WWAKaXWwLj8ASTI6bj2bFz3Xls/5p0Q6YA0TMBraUp9K3
NVJGbscp4S+BG6wYQjoAEzwek2Kz5yc4jHSJhfraLTEWmUwHczPV7Levp37rLeiW
n/OQT1p3w5OJVgnRFy9ptQCST/MaYU9KJWP360bXnqGYg6NrrrlFdIejnIIsSkxX
u21Mu+sF76S3rg0D+L+ByZgbP957azcJ9NeDTooi3Gb+/TqgWL9j4Qyp7DkR2no=
=T2FX
-END PGP SIGNATURE-

_
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.
___
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

Re: [CFT] bsdinstall and zfsboot enhancements

[Michael Dexter]

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?

Michael
___
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

Re: [CFT] bsdinstall and zfsboot enhancements

[Nathan Whitehorn]

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...
http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/usr.sbin%3A%3Absdinstall%3A%3Ascripts%3A%3Aconfig.patch?revision=1.10view=markup

Reasons exist to search for a better solution, see here:
http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046148.html
(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:


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?

-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

Re: [CFT] bsdinstall and zfsboot enhancements

[Teske, Devin]

(disabling default gpg-signing until they fix a bug with the quoting)

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?
 

Sorry, I mistook your issue in the previous e-mail to be on-going with the
thread it was inline with.

LiveCD changes things a bit.

(thinks)

I would expect that a prompt could do:

1. modify /etc/ttys on the boot media
2. run init q

But there's a couple of assumptions...

3. Can we even write to /etc/ttys?
NB: We can write to /tmp because it's an md0 swap device

So do we have to get fancy with slipping a unionfs layer backed by another
md swap device above the root?

That would make every file on the boot media writable (writes would go to
the swap-backed md device and if you execute rm -fW file you can get back
files that have been previously unlinked -- unlinks are stored as whiteouts in
the swap backed md device). For all intents and purposes, the read-only file-
system becomes writable and we could then munge /etc/ttys to enable serial
only when a menu item is chosen.

If I'm off-base, let me know... sounds like a lot of trouble.

The alternative being that you enable serial by default but then I have to tell
field engineers to unplug barcode readers before they do an install??? (that's
a question, it may be entirely safe, but I've never tried, seems unsafe)

Question is, how would you disable it? Goes back to writable filesystem.
-- 
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.
___
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

Re: [CFT] bsdinstall and zfsboot enhancements

[Nathan Whitehorn]

On 11/11/13 14:30, Teske, Devin wrote:

(disabling default gpg-signing until they fix a bug with the quoting)

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?


Sorry, I mistook your issue in the previous e-mail to be on-going with the
thread it was inline with.

LiveCD changes things a bit.

(thinks)

I would expect that a prompt could do:

1. modify /etc/ttys on the boot media
2. run init q

But there's a couple of assumptions...

3. Can we even write to /etc/ttys?
NB: We can write to /tmp because it's an md0 swap device

So do we have to get fancy with slipping a unionfs layer backed by another
md swap device above the root?

That would make every file on the boot media writable (writes would go to
the swap-backed md device and if you execute rm -fW file you can get back
files that have been previously unlinked -- unlinks are stored as whiteouts in
the swap backed md device). For all intents and purposes, the read-only file-
system becomes writable and we could then munge /etc/ttys to enable serial
only when a menu item is chosen.

If I'm off-base, let me know... sounds like a lot of trouble.

The alternative being that you enable serial by default but then I have to tell
field engineers to unplug barcode readers before they do an install??? (that's
a question, it may be entirely safe, but I've never tried, seems unsafe)

Question is, how would you disable it? Goes back to writable filesystem.


This is why I don't think we want to modify /etc/ttys. Instead we want 
to have init do the right thing (follow the boot console) with a single 
unchanged /etc/ttys.

-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

Re: [CFT] bsdinstall and zfsboot enhancements

[Teske, Devin]

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

 On 11/11/13 14:30, Teske, Devin wrote:
 (disabling default gpg-signing until they fix a bug with the quoting)
 
 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?
 
 Sorry, I mistook your issue in the previous e-mail to be on-going with the
 thread it was inline with.
 
 LiveCD changes things a bit.
 
 (thinks)
 
 I would expect that a prompt could do:
 
  1. modify /etc/ttys on the boot media
  2. run init q
 
 But there's a couple of assumptions...
 
  3. Can we even write to /etc/ttys?
  NB: We can write to /tmp because it's an md0 swap device
 
 So do we have to get fancy with slipping a unionfs layer backed by another
 md swap device above the root?
 
 That would make every file on the boot media writable (writes would go to
 the swap-backed md device and if you execute rm -fW file you can get back
 files that have been previously unlinked -- unlinks are stored as whiteouts 
 in
 the swap backed md device). For all intents and purposes, the read-only file-
 system becomes writable and we could then munge /etc/ttys to enable serial
 only when a menu item is chosen.
 
 If I'm off-base, let me know... sounds like a lot of trouble.
 
 The alternative being that you enable serial by default but then I have to 
 tell
 field engineers to unplug barcode readers before they do an install??? 
 (that's
 a question, it may be entirely safe, but I've never tried, seems unsafe)
 
 Question is, how would you disable it? Goes back to writable filesystem.
 
 This is why I don't think we want to modify /etc/ttys. Instead we want to 
 have init do the right thing (follow the boot console) with a single 
 unchanged /etc/ttys.

Let me see if I've got it right...

Already-knowns:
+ The boot variables are influenced by loader.conf which is read-only media.
+ But Michael is loading the media from bhyve.

Question:
Does bhyve set kern.console irrespective of loader.conf values?

If so, then yeah... I'm all for supporting your stated Option-A in the other 
thread.
-- 
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.
___
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

Re: [CFT] bsdinstall and zfsboot enhancements

[Peter Grehan]

Hi Nathan,


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.


 I now agree with this :) Modifying /etc/ttys at install time doesn't 
work for a lot of cases, LiveCD being the most obvious.



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:


 I'd guess that this mode is really a once-off thing - for a live CD, 
init could ask the user if they want a getty spawned on this tty similar 
to asking for a shell in single-user mode.


 Presumably post-install the user would have edited the ttys file and 
init would then be able to locate the entry and not have to prompt.


later,

Peter.

___
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

Re: [CFT] bsdinstall and zfsboot enhancements

[Teske, Devin]

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%3Dmarkupk=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0Am=CRY%2BFNOe6Q01s5oKeCFeGOhE0bW%2BvEmw6GTjyy5eHFo%3D%0As=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.htmlk=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0Am=CRY%2BFNOe6Q01s5oKeCFeGOhE0bW%2BvEmw6GTjyy5eHFo%3D%0As=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.
___
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

Re: [CFT] bsdinstall and zfsboot enhancements

[Peter Grehan]

Hi Devin,


Question:
Does bhyve set kern.console irrespective of loader.conf values?


 The kernel sets it based on what it determines the console to be. 
Bhyve influences that by requesting a serial console. This is no 
different than booting on a headless machine with a serial console.


later,

Peter.
___
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

Re: [CFT] bsdinstall and zfsboot enhancements

[Nathan Whitehorn]

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%3Dmarkupk=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0Am=CRY%2BFNOe6Q01s5oKeCFeGOhE0bW%2BvEmw6GTjyy5eHFo%3D%0As=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.htmlk=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0Am=CRY%2BFNOe6Q01s5oKeCFeGOhE0bW%2BvEmw6GTjyy5eHFo%3D%0As=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

Re: [CFT] bsdinstall and zfsboot enhancements

[Teske, Devin]

On Nov 11, 2013, at 12:44 PM, Peter Grehan wrote:

 Hi Devin,
 
 Question:
 Does bhyve set kern.console irrespective of loader.conf values?
 
 The kernel sets it based on what it determines the console to be. Bhyve 
 influences that by requesting a serial console. This is no different than 
 booting on a headless machine with a serial console.
 

Well, for a headless meachine, I would set console=comconsole,vidconsole
in loader.conf(5), then our Forth code slurps it in via loader.4th + support.4th
routines...

When boot is executed, I know I can see kenv console, but hadn't realized
that there were/are a host of others that are slurped into the kernel for later
(very purposeful) fetching.

So when you say that bhyve requests a serial console... I assume now it's
setting variables... but via raw Forth? C code? loader.conf(5)? I've seen my
menu come up under bhyve, and I noticed that it only has a 5-second count-
down instead of the usual 9 -- but I'm curious how you're exporting the 
variables.
-- 
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.
___
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

Re: [CFT] bsdinstall and zfsboot enhancements

[Nathan Whitehorn]

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...
http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/usr.sbin%3A%3Absdinstall%3A%3Ascripts%3A%3Aconfig.patch?revision=1.10view=markup 



Reasons exist to search for a better solution, see here:
http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046148.html 


(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.

-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

Re: [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%3Dmarkupk=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0Am=aZg%2BxwqLTX6Zcpf3Rc44iPtAQhFrpqoS4FC5B8ykxJQ%3D%0As=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.htmlk=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0Am=aZg%2BxwqLTX6Zcpf3Rc44iPtAQhFrpqoS4FC5B8ykxJQ%3D%0As=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.
___
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

Re: [CFT] bsdinstall and zfsboot enhancements

[Nathan Whitehorn]

On 11/11/13 14:52, Teske, Devin wrote:

On Nov 11, 2013, at 12:44 PM, Peter Grehan wrote:


Hi Devin,


Question:
Does bhyve set kern.console irrespective of loader.conf values?

The kernel sets it based on what it determines the console to be. Bhyve 
influences that by requesting a serial console. This is no different than 
booting on a headless machine with a serial console.


Well, for a headless meachine, I would set console=comconsole,vidconsole
in loader.conf(5), then our Forth code slurps it in via loader.4th + support.4th
routines...

When boot is executed, I know I can see kenv console, but hadn't realized
that there were/are a host of others that are slurped into the kernel for later
(very purposeful) fetching.

So when you say that bhyve requests a serial console... I assume now it's
setting variables... but via raw Forth? C code? loader.conf(5)? I've seen my
menu come up under bhyve, and I noticed that it only has a 5-second count-
down instead of the usual 9 -- but I'm curious how you're exporting the 
variables.


I think you've misunderstood. kern.console isn't set by loader. It 
reflects the state of the kernel, which decides what to do autonomously 
based on a number of driver and platform-dependent things including, but 
not limited to, kenv (loader variables, for instance).

-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

Re: [CFT] bsdinstall and zfsboot enhancements

[Peter Grehan]

Hi Devin,


When boot is executed, I know I can see kenv console, but hadn't realized
that there were/are a host of others that are slurped into the kernel for later
(very purposeful) fetching.

So when you say that bhyve requests a serial console... I assume now it's
setting variables... but via raw Forth? C code? loader.conf(5)? I've seen my
menu come up under bhyve, and I noticed that it only has a 5-second count-
down instead of the usual 9 -- but I'm curious how you're exporting the 
variables.


 bhyve uses the loader facility to set env variables directly from 
loader code. This is no different than other arch ports of the loader 
that set env variables. The forced setting of boot_serial is just a 
convenience for users since that is the only supported console type.


 It doesn't touch the timeout code - should be whatever FreeBSD loader 
forth scripts tell it to do.


later,

Peter.

___
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

Re: [CFT] bsdinstall and zfsboot enhancements

[Teske, Devin]

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

 On 11/11/13 14:52, Teske, Devin wrote:
 On Nov 11, 2013, at 12:44 PM, Peter Grehan wrote:
 
 Hi Devin,
 
 Question:
 Does bhyve set kern.console irrespective of loader.conf values?
 The kernel sets it based on what it determines the console to be. Bhyve 
 influences that by requesting a serial console. This is no different than 
 booting on a headless machine with a serial console.
 
 Well, for a headless meachine, I would set console=comconsole,vidconsole
 in loader.conf(5), then our Forth code slurps it in via loader.4th + 
 support.4th
 routines...
 
 When boot is executed, I know I can see kenv console, but hadn't realized
 that there were/are a host of others that are slurped into the kernel for 
 later
 (very purposeful) fetching.
 
 So when you say that bhyve requests a serial console... I assume now it's
 setting variables... but via raw Forth? C code? loader.conf(5)? I've seen my
 menu come up under bhyve, and I noticed that it only has a 5-second count-
 down instead of the usual 9 -- but I'm curious how you're exporting the 
 variables.
 
 I think you've misunderstood. kern.console isn't set by loader. It reflects 
 the state of the kernel, which decides what to do autonomously based on a 
 number of driver and platform-dependent things including, but not limited to, 
 kenv (loader variables, for instance).

I was thinking it, but didn't express it properly... yes... kern.console is 
influenced
by loader variables.

slurped is definitely not the technical explanation I should be striving for 
;D (that
is, if I'm trying to be clear).
-- 
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.
___
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

Re: [CFT] bsdinstall and zfsboot enhancements

[Teske, Devin]

On Nov 11, 2013, at 12:59 PM, Peter Grehan wrote:

 Hi Devin,
 
 When boot is executed, I know I can see kenv console, but hadn't realized
 that there were/are a host of others that are slurped into the kernel for 
 later
 (very purposeful) fetching.
 
 So when you say that bhyve requests a serial console... I assume now it's
 setting variables... but via raw Forth? C code? loader.conf(5)? I've seen my
 menu come up under bhyve, and I noticed that it only has a 5-second count-
 down instead of the usual 9 -- but I'm curious how you're exporting the 
 variables.
 
 bhyve uses the loader facility to set env variables directly from loader 
 code. This is no different than other arch ports of the loader that set env 
 variables. The forced setting of boot_serial is just a convenience for users 
 since that is the only supported console type.
 

Thank you much for the explanation. I see it from end-to-end now.


 It doesn't touch the timeout code - should be whatever FreeBSD loader forth 
 scripts tell it to do.
 

Ah, must have been something Michael did. I noticed this whilst getting
demos from him on his laptop.
-- 
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.
___
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

Re: [CFT] bsdinstall and zfsboot enhancements

[Allan Jude]

On 2013-11-11 15:54, 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...
 http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/usr.sbin%3A%3Absdinstall%3A%3Ascripts%3A%3Aconfig.patch?revision=1.10view=markup


 Reasons exist to search for a better solution, see here:
 http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046148.html

 (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.
 -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

These seems the best approach to me. The ttyu's are off by default, so
changing that to commented out has no effect on anyone, and it allows
you to do the right magic in init.

Thank you for the offer to write this up, look forward to testing the
patches

-- 
Allan Jude




signature.asc
Description: OpenPGP digital signature

Re: [CFT] bsdinstall and zfsboot enhancements

[Teske, Devin]

On Nov 5, 2013, at 7:54 PM, Craig Rodrigues wrote:

 
 
 
 On Sat, Nov 2, 2013 at 10:59 AM, Teske, Devin devin.te...@fisglobal.com 
 wrote:
 
 + Update bsdinstall's config script to adjust ttyu* entries in
 /etc/ttys when it is determined that we are in-fact doing an install
 over serial (e.g. bhyve).
 
 I think this is useful.  In earlier versions of BHyve, the default was to use 
 console over a PCI serial device. 
 With this commit from Neel Natu: 
 http://lists.freebsd.org/pipermail/svn-src-all/2013-October/076027.html
 it is now possible to specify a different device for the console, such as 
 COM1.
 

Unfortunately, that's getting the axe.

I agree with Nathan... the installer shouldn't make this assumption.

I think init should be fixed instead.
-- 
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.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [CFT] bsdinstall and zfsboot enhancements

[Craig Rodrigues]

On Sat, Nov 2, 2013 at 10:59 AM, Teske, Devin devin.te...@fisglobal.comwrote:


 + Update bsdinstall's config script to adjust ttyu* entries in
 /etc/ttys when it is determined that we are in-fact doing an install
 over serial (e.g. bhyve).


I think this is useful.  In earlier versions of BHyve, the default was to
use console over a PCI serial device.
With this commit from Neel Natu:
http://lists.freebsd.org/pipermail/svn-src-all/2013-October/076027.html
it is now possible to specify a different device for the console, such as
COM1.

--
Craig
___
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

Re: [CFT] bsdinstall and zfsboot enhancements

[Teske, Devin]

On Nov 2, 2013, at 8:40 PM, Nathan Whitehorn wrote:

 On 11/02/13 12:59, Teske, Devin wrote:
 Hi all,
 
 Another Call For Testing...
 This one is for bsdinstall.
 Will look at the rest later...
 
 + Update bsdinstall's config script to adjust ttyu* entries in
 /etc/ttys when it is determined that we are in-fact doing an install
 over serial (e.g. bhyve).
 
 
 I think this is the wrong solution.

Thank you for your feedback. Sincerely.


 The installer is run in a lot of circumstances, and tying it to the boot 
 environment is a mistake. If we want serial consoles to default to on for 
 x86, they should default to on (they do for most other architectures). The 
 magic should never ever be in the installer.
 

Well, I would say we *don't* want serial to be on by default...
That would actually hurt me at $work where we actually use
the serial ports for barcode readers.


 Setting the terminal type to vt100 unconditionally is also questionable. 
 Using kbdcontrol also doesn't do the right thing, since it will turn on 
 serial consoles if you install to, say, a disk image from an xterm or if you 
 use newcons.

Kk.

I'm CC'ing Peter Grehan, because we only arrived at this solution
based on a quick discussion with Michael Dexter at vBSDcon with
respect to bhyve.

Peter, can you restate the problem for Nathan so that we can
maybe find a better home for this change? or perhaps more clearly
define (than I) how we arrived at the code for the bhyve work?
-- 
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.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [CFT] bsdinstall and zfsboot enhancements

[Nathan Whitehorn]

On Nov 3, 2013, at 11:33 AM, Teske, Devin wrote:



On Nov 2, 2013, at 8:40 PM, Nathan Whitehorn wrote:


On 11/02/13 12:59, Teske, Devin wrote:

Hi all,

Another Call For Testing...
This one is for bsdinstall.

Will look at the rest later...


+ Update bsdinstall's config script to adjust ttyu* entries in
/etc/ttys when it is determined that we are in-fact doing an install
over serial (e.g. bhyve).



I think this is the wrong solution.


Thank you for your feedback. Sincerely.


The installer is run in a lot of circumstances, and tying it to the  
boot environment is a mistake. If we want serial consoles to  
default to on for x86, they should default to on (they do for most  
other architectures). The magic should never ever be in the  
installer.




Well, I would say we *don't* want serial to be on by default...
That would actually hurt me at $work where we actually use
the serial ports for barcode readers.


Hmm, that's tricky.



Setting the terminal type to vt100 unconditionally is also  
questionable. Using kbdcontrol also doesn't do the right thing,  
since it will turn on serial consoles if you install to, say, a  
disk image from an xterm or if you use newcons.


Kk.

I'm CC'ing Peter Grehan, because we only arrived at this solution
based on a quick discussion with Michael Dexter at vBSDcon with
respect to bhyve.

Peter, can you restate the problem for Nathan so that we can
maybe find a better home for this change? or perhaps more clearly
define (than I) how we arrived at the code for the bhyve work?


So I guess the real problem here is that init does not know enough to  
start a login prompt on the console. This has irritated me for a while  
actually. Maybe that should be fixed? The console entry, which would  
always automatically work, in /etc/ttys is marked off, which  
apparently happened in the runup to 4.0. It might be time to revisit  
that.

-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

Re: [CFT] bsdinstall and zfsboot enhancements

[Peter Grehan]

Peter, can you restate the problem for Nathan so that we can
maybe find a better home for this change? or perhaps more clearly
define (than I) how we arrived at the code for the bhyve work?


 The issue is that /etc/ttys is static. Serial console installs assume 
that the user knows that the file should be edited manually to enable 
getty on the serial port. This seems at odds with a server o/s :(


 The suggestion I brought up with Devin was to see if the install was 
done on a serial port, and if so, then ask if the user wanted to enable 
a getty on that terminal. I think the patch might need some work: for 
instance, a sysctl could be used to see if the console is on a ttyu* 
device, and only enable for that and not for all ttys. I was going to 
try it out this weekend but was a bit slow off the mark :)



So I guess the real problem here is that init does not know enough to
start a login prompt on the console. This has irritated me for a while
actually. Maybe that should be fixed? The console entry, which would
always automatically work, in /etc/ttys is marked off, which apparently
happened in the runup to 4.0. It might be time to revisit that.


 That's also not good :( /dev/console is assumed to be a sink for log 
messages and not really an interactive tty.


later,

Peter.

___
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

Re: [CFT] bsdinstall and zfsboot enhancements

[Nathan Whitehorn]

On Nov 3, 2013, at 12:59 PM, Peter Grehan wrote:


Peter, can you restate the problem for Nathan so that we can
maybe find a better home for this change? or perhaps more clearly
define (than I) how we arrived at the code for the bhyve work?


The issue is that /etc/ttys is static. Serial console installs  
assume that the user knows that the file should be edited manually  
to enable getty on the serial port. This seems at odds with a server  
o/s :(


Yes, I agree. It's a significant usability issue...

The suggestion I brought up with Devin was to see if the install was  
done on a serial port, and if so, then ask if the user wanted to  
enable a getty on that terminal. I think the patch might need some  
work: for instance, a sysctl could be used to see if the console is  
on a ttyu* device, and only enable for that and not for all ttys. I  
was going to try it out this weekend but was a bit slow off the  
mark :)


This was something along the lines of what I was thinking.


So I guess the real problem here is that init does not know enough to
start a login prompt on the console. This has irritated me for a  
while
actually. Maybe that should be fixed? The console entry, which  
would
always automatically work, in /etc/ttys is marked off, which  
apparently

happened in the runup to 4.0. It might be time to revisit that.


That's also not good :( /dev/console is assumed to be a sink for log  
messages and not really an interactive tty.


Is there any way to extract the backing device via, for example, an  
ioctl() from /dev/console? It seems bizarre that up until the login  
prompt the OS can figure out where to route console messages up until  
the login prompt and then gets confused at that point. I'd really  
prefer to have the intelligence there, since all the information  
needed is present, rather than have the installer guess. conscontrol  
has the ability to get the console backing TTY device through the  
kern.console TTY. Maybe init could do the same trick and add whatever  
is in kern.console if not manually specified in /etc/ttys?

-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

[CFT] bsdinstall and zfsboot enhancements

[Teske, Devin]

Hi all,

Another Call For Testing...
This one is for bsdinstall.

Two patchsets are required for this CFT:

http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_debug/
http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/

The enhancements are:

+ Add a `-D FILE command-line option for overriding the
path to the bsdinstall log file (BSDINSTALL_LOG env var).

+ Document new `-D FILE' in the man page for bsdinstall.

+ If FILE in `-D FILE' begins with a +, debug output goes to
stdout (interleaved between dialog(1) invocations/output) as
well as to FILE (minus the leading + of course).

+ If BSDINSTALL_LOG cannot be written, then debugging is
disabled (except in the case of a leading + in the pathname,
wherein debug will still be printed to stdout).

+ Update source code format to approximate a future shstyle(9)

+ Fix a dangling participle (Begun ... - Began ...)

+ Rewrite the docsinstall script (was necessary to abate direct
dependency on BSDINSTALL_LOG (instead, use fault-tolerant
bsdconfig framework which displays appropriate errors for
package management).

+ Add additional debug output for dhclient/rtsol/wpa_cliscan

+ Display script errors in a textbox rather than just on stdout

+ Update many coments.

+ Add new f_show_err() API call (like f_show_msg but changes
the dialog title to Error)(see bsdconfig's `common.subr').

+ Add new f_eval_catch() API call for executing a command via
eval but not before logging the command to debug. Several
example cases documented in API header for function in
bsdconfig's `common.subr'.

+ Fix dialog auto-sizing when launched as an rvalue to a pipe
for indirected scripts (previously would default to 80x24 sizing
in this case, now it can autosize to full size even when in a pipe
chain).

+ Fix a bug in f_snprintf wherein if the $format argument began
with a - or -- it would be misinterpreted as a flag to printf. (this
is in bsdcofig's strings.subr)

+ Add accompanying f_sprintf() and f_vsprintf() to go along with
already existing f_snprintf() and f_vsnprintf() (see bsdconfig's
strings.subr).

+ Update bsdinstall's config script to adjust ttyu* entries in
/etc/ttys when it is determined that we are in-fact doing an install
over serial (e.g. bhyve).

+ Remove some unnecessary default ZFS datasets from the
automatic zfsboot script. Such as: /usr/ports/distfiles
/usr/ports/packages /usr/obj /var/db /var/empty /var/mail and
/var/run (these can all be created as-needed once the system is
installed).

+ Remove setuid=off for /usr/home (as discussed with others from
last round of CFT).

+ Fix some i18n string violations in zfsboot

+ Bolster debugging output in zfsboot

+ Fix some string quoting issues in zfsboot

+ Fix some variable scope issues in zfsboot

+ Only display the ZFS vdev type selection menu when running
interactively (duh).

+ Change Create to Install in zfsboot main menu

+ Increase pedantic error checking in zfsboot (type-check
arguments and such).

+ Add a call to graid destroy to kill automatic metadata (part of
the series of pedantic destructions we do when bootstrapping
a new/naked disk).

+ Make judicious use of new f_eval_catch() in zfsboot

+ More comments (zfsboot).

+ Fixup some variable names for consistency (zfsboot).

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


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [CFT] bsdinstall and zfsboot enhancements

[Outback Dingo]

On Sat, Nov 2, 2013 at 1:59 PM, Teske, Devin devin.te...@fisglobal.comwrote:

 Hi all,

 Another Call For Testing...
 This one is for bsdinstall.

 Two patchsets are required for this CFT:

 http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_debug/
 http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/

 The enhancements are:

 + Add a `-D FILE command-line option for overriding the
 path to the bsdinstall log file (BSDINSTALL_LOG env var).

 + Document new `-D FILE' in the man page for bsdinstall.

 + If FILE in `-D FILE' begins with a +, debug output goes to
 stdout (interleaved between dialog(1) invocations/output) as
 well as to FILE (minus the leading + of course).

 + If BSDINSTALL_LOG cannot be written, then debugging is
 disabled (except in the case of a leading + in the pathname,
 wherein debug will still be printed to stdout).

 + Update source code format to approximate a future shstyle(9)

 + Fix a dangling participle (Begun ... - Began ...)

 + Rewrite the docsinstall script (was necessary to abate direct
 dependency on BSDINSTALL_LOG (instead, use fault-tolerant
 bsdconfig framework which displays appropriate errors for
 package management).

 + Add additional debug output for dhclient/rtsol/wpa_cliscan

 + Display script errors in a textbox rather than just on stdout

 + Update many coments.

 + Add new f_show_err() API call (like f_show_msg but changes
 the dialog title to Error)(see bsdconfig's `common.subr').

 + Add new f_eval_catch() API call for executing a command via
 eval but not before logging the command to debug. Several
 example cases documented in API header for function in
 bsdconfig's `common.subr'.

 + Fix dialog auto-sizing when launched as an rvalue to a pipe
 for indirected scripts (previously would default to 80x24 sizing
 in this case, now it can autosize to full size even when in a pipe
 chain).

 + Fix a bug in f_snprintf wherein if the $format argument began
 with a - or -- it would be misinterpreted as a flag to printf. (this
 is in bsdcofig's strings.subr)

 + Add accompanying f_sprintf() and f_vsprintf() to go along with
 already existing f_snprintf() and f_vsnprintf() (see bsdconfig's
 strings.subr).

 + Update bsdinstall's config script to adjust ttyu* entries in
 /etc/ttys when it is determined that we are in-fact doing an install
 over serial (e.g. bhyve).

 + Remove some unnecessary default ZFS datasets from the
 automatic zfsboot script. Such as: /usr/ports/distfiles
 /usr/ports/packages /usr/obj /var/db /var/empty /var/mail and
 /var/run (these can all be created as-needed once the system is
 installed).

 + Remove setuid=off for /usr/home (as discussed with others from
 last round of CFT).

 + Fix some i18n string violations in zfsboot

 + Bolster debugging output in zfsboot

 + Fix some string quoting issues in zfsboot

 + Fix some variable scope issues in zfsboot

 + Only display the ZFS vdev type selection menu when running
 interactively (duh).

 + Change Create to Install in zfsboot main menu

 + Increase pedantic error checking in zfsboot (type-check
 arguments and such).

 + Add a call to graid destroy to kill automatic metadata (part of
 the series of pedantic destructions we do when bootstrapping
 a new/naked disk).

 + Make judicious use of new f_eval_catch() in zfsboot

 + More comments (zfsboot).

 + Fixup some variable names for consistency (zfsboot).


nice work, looks good, patched the bootloader also, seems to function well,
love the kernel selection variable


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

___
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

Re: [CFT] bsdinstall and zfsboot enhancements

[Nathan Whitehorn]

On 11/02/13 12:59, Teske, Devin wrote:

Hi all,

Another Call For Testing...
This one is for bsdinstall.

Will look at the rest later...


+ Update bsdinstall's config script to adjust ttyu* entries in
/etc/ttys when it is determined that we are in-fact doing an install
over serial (e.g. bhyve).



I think this is the wrong solution. The installer is run in a lot of 
circumstances, and tying it to the boot environment is a mistake. If we 
want serial consoles to default to on for x86, they should default to on 
(they do for most other architectures). The magic should never ever be 
in the installer.


Setting the terminal type to vt100 unconditionally is also questionable. 
Using kbdcontrol also doesn't do the right thing, since it will turn on 
serial consoles if you install to, say, a disk image from an xterm or if 
you use newcons.

-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