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

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