On Sat, 21 Oct 2006 10:52:27 -0400, Thor Lancelot Simon <tls@rek.tjls.com>
wrote:

> On Sat, Oct 21, 2006 at 10:39:03AM -0400, Steven M. Bellovin wrote:
> > On Sat, 21 Oct 2006 10:31:48 -0400, Thor Lancelot Simon <tls@rek.tjls.com>
> > wrote:
> > 
> > > Try this:
> > > 
> > > console	"/usr/libexec/getty Pc"		vt100	off
> > > ttyE0	"/usr/libexec/getty Pc"		vt220	on	secure
> > > tty00	"/usr/libexec/getty std.9600"	unknown	on	secure
> > > 
> > Thanks.  (Further poking makes it seem very likely that there's a
> > hardware problem -- I can log in blind and see 'root' logged in, but I
> > never see any output.  That makes it sound like a cable or connector
> > issue.)
> > 
> > One last question -- should wscons be on or off?
> 
> It doesn't matter.  Why would it?
> 
> > Also -- where, if anyplace, is this documented?  I see nothing in the
> > How-Tos or the NetBSD Guide on setting up serial consoles. 
> 
> Well, it can certainly be sorted out from general Unix knowledge, plus
> the ttys manual page.  I suppose the only piece that's not obvious is
> that _either_ ttyE0 or tty00 may alias /dev/console, but that init always
> uses the "console" ttys entry to decide whether to prompt for the root
> password before entering single-user mode.  But I think the init manual
> page even documents that.

I'll assert that I have at least my share of "general Unix knowledge" --
that's why it's not obvious.

The problem is that we're dealing with three different device names (i.e.,
major/minor pairs): /dev/console, /dev/ttyE0, /dev/tty00.  There isn't a
lot of precedent for understanding the relationship between them.

I had understood ttyE0 to be a reference to the wscons driver.  If it
doesn't matter if wscons is on or off, that clearly isn't the case.  In
that case, I have no idea what E0 is.

Regardless of the E0 issue, the next question is what the relationship is
between /dev/console and /dev/tty00.  If it's some sort of driver-level
symlink analog, then both should block or open simultaneously.  If one is
somehow a front end for the other -- think Solaris/System V streams --
then one is unavailable while the other is overlaid.  Either way, I see
nothing that suggests it's a good idea to try opens on both simultaneously
-- if both succeed, there's trouble; if only one succeeds, the other
presumably will never succeed, so what's the point?

The init man page does state that /dev/console is the system console --
that's precisely why I had it enabled.  Your suggestion about fallback
access is a good one, though the only ways I can see that the failure
could occur are a kernel with explicit bad console configuration or a
change in the boot blocks, and the latter doesn't seem possible when
running in multi-user mode.  But fallback is only sensible if opening both
simultaneously is feasible.

Btw, I reconfigured with these lines, per your suggestion, and rebooted:

console "/usr/libexec/getty Pc"         vt100   off secure
ttyE0   "/usr/libexec/getty Pc"         vt220   on secure
tty00   "/usr/libexec/getty std.9600"   vt220   on secure

/var/log/authlog now has

getty[200]: /dev/ttyE0: Device not configured
> 
> I tend to think that "How-Tos" are a very bad thing: they encourage people
> to do complex tasks, with potentially serious consequences, without the
> background knowledge they would have if they actually looked at the primary
> documentation for long enough to figure it out.  Then if anything goes
> wrong, they're utterly stuck.  The NetBSD Guide seems somewhat better.
> 
That's fine -- it's not there, either.

I see your point about the risk of a How-To document; that said, they fill
an important role: providing an overview.  There's an old English saying
about not seeing the forest for the trees.  Man pages (and source code
even more) are the trees; if you don't have the proper large picture,
you're likely to miss seeing the forest.  A good How-To has copious
references to man pages and other detailed documents, plus a few warnings
about "here be dragons" for especially-dangerous things.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb