[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: terminal --silent option

From: Henrik Nordstrom
Subject: Re: terminal --silent option
Date: Thu, 18 Apr 2002 00:46:40 +0200

Christoph Plattner wrote:
> Have you thought about the side effects ?


> Think, you have a mouse on COM1, which also is your secondary console...

Bad example. I do not have a screen, so connecting a mouse is useless.

> What is with other things connected to the RS232 as multi meter with
> serial output, sending cyclic data ...

In my case, all devices that may be connected on the serial port can be
assumed to be silent until spoken to, or at least until the user
performs some physical action with the serial connect device which
cannot be done "naturally". And if the unlucky event occurs despite all
this happens to speak during the small window where the boot console can
be activated then it is acceptable if the user has to reboot by turning
the unit off and on again.

> My "UNIX way of like thinking" says:
> * A system has one or 2 alternative console. Dependent on the system,
> one
>   console type is the default (PC & Workstation = Graphics/Keyboard,
>   Servers & embedded systems = serial i/f).

For embedded devices the usual choice is no console at all when the
device is running, and no boot console unless asked for by a magic
keypress. The few serial ports you have is usually needed for the
application of the embedded device.

> * If a machine uses a serial console (potentially), this port MUST be
>   reserved and not used by any other devices !

Or there must be a reasonable failproof handshake to enable the serial

> * Machines should have boot monitors, which are able to handle VT100
>   (or similar) console type via serial or graphics.
>   GRUB is a (wonderful) BIOS addon, which allows a boot monitor
> functionality
>   on PCs also, the only thing I miss is the permanent environment
> storage ...

I fully agree. GRUB is excellent. My choice is between a dumb simple
boot program or GRUB, and obviously the choice is GRUB. Will probably
add a couple of commands for dealing with permanent storage such as TFTP
to a block range or a simple editor allowing you to modify text files
(i.e. menu.lst) or block ranges.

Odd note: my menu is stored in a blockrange, not in a file on a

> Now a possible solution: The serial port for the alternate console is NOT
> connected, so it is not a problem sending out "sensless" text. If a
> person has special instruction to handle a special case on the serial console,
> then the person will connect a terminal (or other things), and perhaps need a
> password. This is (only) my opinion.

In my case I cannot affort to lock a serial port for a console nobody
should normally use, but I need a way to be able to access the excellent
GRUB boot monitor without having to disasseemble the box in case of
problems during a software upgrade (the VGA connector is only accessible
internally on the MB with a special cable). I also need to ensure that
when the box is in production it does not disturb any device connected
to the serial when rebooting.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]