On Mon, Sep 27, 1999 at 12:56:14PM -0700, Bill Studenmund wrote:
> But ttyE0 is the video console! tty0[01] are the serial ports!

Erm.

Neat.

So it's because I had a monitor/keyboard plugged in and unplugged the
monitor after booting?

This machine routinely has no serial terminal and no monitor
connected, as it is locked up and security-system protected along with
a couple of machines owned by the CS department of Swarthmore College.
I only ever connect to it via ssh.

> Did you have both /dev/console and /dev/ttyE0 enabled? That would explain
> all the problems you describe. /dev/console points to whatever is the real
> console, and so it'll move when you flip from serial to video console. But
> ttyE0 and tty0[01] all stay fixed, and disapear if the relevant hardware's
> not present.

Nope. Here's an excerpt from my /etc/ttys now:

console "/usr/libexec/getty std.38400"  vt100   off secure
ttyE0   "/usr/libexec/getty std.9600"   vt100   off secure
tty00   "/usr/libexec/getty std.38400"  vt100   on secure
tty01   "/usr/libexec/getty std.9600"   unknown off secure

Only difference there that made getty sky-rocket was that ttyE0 was
set to "on" instead of "off". console has never been set to "on" that
I've had occasion to notice.

> Having both ttyE0 and /dev/console on will cause problems as one of the
> two will open the device, and then the other won't be able to as it'll be
> busy.

Makes sense, but I don't think that's what was happening here. (I
think my theory still applies, just not to the serial interface video
hardware was initialized but couldn't continue sending a signal as
there wasn't anything plugged in).

> Having both /dev/console and the real console device as on in /etc/ttys is
> not good, because it exhibits the behavior you've seen. :-)

Well, that makes sense theoretically, but it doesn't explain my
problem, as that's not the way things were here.

       ~ g r @ eclipsed.net