Subject: Re: querying the console type?
To: None <email@example.com>
From: Steven M. Bellovin <firstname.lastname@example.org>
Date: 10/21/2006 12:44:15
On Sat, 21 Oct 2006 10:52:27 -0400, Thor Lancelot Simon <email@example.com>
> 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 <firstname.lastname@example.org>
> > 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: /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