Re: [CFT] bsdinstall and zfsboot enhancements

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