LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

updated

This commit is contained in:
gferg 2000-12-14 14:43:57 +00:00
parent 2004f03492
commit a1ae042d7b
1 changed files with 239 additions and 126 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

365
LDP/howto/linuxdoc/Text-Terminal-HOWTO.sgml
View File

@ -3,9 +3,13 @@
<title> Text-Terminal-HOWTO
<author> David S. Lawyer <url url="mailto:dave@lafn.org">
<date> v1.16, October 2000
<date> v1.17, December 2000
<!--
Change log:
v1.17 December 2000 Don't run getty from the command line,
XDM-and-X-Terminal mini-HOWTO, substitutes for "local mode",
character mapping with "mapchan"
v1.16 October 2000 Thin clients+; NC Howtos; Correction of bad typo
"text terminals are fully obsolete". Meant to say "not fully
obsolete". typo Unbounded => Boundless "' )
@ -114,10 +118,10 @@ be a trademark). Such trademarks belong to their respective owners.
<sect2> Credits
<p> Much of the section "Physical Connection" is from Serial-HOWTO v.
1.11 by Greg Hankins (with his permission). His "How Do I Set Up A
Terminal Connected To My PC?" was incorporated into v1.00 at various
places. v1.09 has about 25 changes (and error corrections) suggested
by Alessandro Rubini who reviewed this HOWTO.
1.11 (1997) by Greg Hankins (with his permission). His "How Do I Set
Up A Terminal Connected To My PC?" was incorporated into v1.00 at
various places. v1.09 has about 25 changes (and error corrections)
suggested by Alessandro Rubini who reviewed this HOWTO.
<sect1> Future Plans: You Can Help
<p> Please let me know of any errors in facts, opinions, logic,
@ -147,22 +151,27 @@ sites see: <url url="http://linuxdoc.org/mirrors.html">.
Various formats are available. If you only want to quickly check the
date of the latest version look at <url
url="http://linuxdoc.org/HOWTO/Text-Terminal-HOWTO.html">. The
version your are currently reading is: v1.16, October 2000 . New in this version
is: Thin-clients+; NC Howtos; Correction of bad typo "text
terminals are fully obsolete". Meant to say "not fully obsolete".
typo Unbounded => Boundless;
version your are currently reading is: v1.17, December 2000 . New in this version
is: Don't run getty from the command line,
XDM-and-X-Terminal mini-HOWTO, substitutes for "local mode",
character mapping with "mapchan"
<sect1> Related HOWTO's <label id="related_howtos">
<sect1> Related HOWTOs, etc. <label id="related_howtos">
<p> Go to the websites shown above to get these.
<itemize>
<item> Serial-HOWTO has info on Multiport Serial Cards used for both
terminals and banks of modems. It has general technical info on the
serial port including troubleshooting it.
<item> <url url="www.gnu.org/manual/glibc/html_chapter/libc_12.html"
name="Low-Level Terminal Interface"> part of "GNU C Library Reference
manual" (in libc (or glibc) docs package). It covers the detailed
meaning of "stty" commands, etc.
<item> MacTerminal mini-HOWTO
<item> Modem-HOWTO
<item> Serial-Programming-HOWTO
<item> NC mini-HOWTO
<item> NCD-X-Terminal mini-HOWTO
<item> XDM-and-X-Terminal mini-HOWTO
<item> NCD-HOWTO
<item> Thinclient-HOWTO
<item> Xterminal-HOWTO (unmaintained). It's at <url url=
@ -434,6 +443,7 @@ There are some HOWTOs for certain brands of NCs:
<item> NC-HOWTO (IBM NetStation)
<item> NCD mini-HOWTO (NCD-ThinSTAR)
<item> NCD-X-Terminal mini-HOWTO
<item> XDM-and-X-Terminal mini-HOWTO
</itemize>
<sect2> Hardware hookups
@ -500,7 +510,7 @@ is 8. Then at the computer console type "init q" to apply the changes
you made to the inittab file. You should now see a login prompt at
the terminal. If you don't, tap the terminal's return key. If this
doesn't work read more of this document and/or see <ref
id="trouble-shoot" name="Trouble-Shooting">.
id="trouble_shoot" name="Trouble-Shooting">.
<sect>Why Use a Terminal ?
@ -1168,6 +1178,8 @@ Europe: <url
url="http://www.funet.fi/pub/culture/russian/comp/cyril-term/"><newline>
N. America: <url
url="http://metalab.unc.edu/pub/Linux/utils/terminal/">
For mapping the keyboard (and screen) for use of various fonts see
<ref id="mapchan_" name="Character Mapping: mapchan">
<sect1> Keyboards & Special Keys
@ -2734,7 +2746,11 @@ ASCII code for that key (depends also on Shift and Control key). On
some terminals you may make any key send any code you wish. That is,
you may completely remap the keyboard by setting up the terminal that
way. This may be useful for some foreign languages and Dvorak
keyboard layouts, etc. which permit one to type faster.
keyboard layouts, etc. which permit one to type faster. Even for
terminals that don't have the feature, there is software to remap the
keyboard (and screen also). It's something like a device driver
which uses a pseudo terminal. See <ref id="mapchan_" name="Character
Mapping: mapchan">
<sect2> Corner Key (for Wyse only)
<p> Wyse terminals have a key near the lower left corner which may be
@ -2955,8 +2971,10 @@ One does this by editing at the console (or from any working terminal).
<sect1> Getty (in /etc/inittab) <label id="getty_">
<p> In order to have a login process run on a serial port when the
computer starts up (or switches run levels) a getty command must be
put into the /etc/inittab file. Getty GETs a TTY (a terminal) going.
Each terminal needs its own getty command. There is also at least one
put into the /etc/inittab file. Running getty from the command line
may cause problems (see <ref id="stopped_" name="Programs get
Stopped"> to see why ). Getty GETs a TTY (a terminal) going. Each
terminal needs its own getty command. There is also at least one
getty command for the console in every /etc/inittab file. Find this
and put the getty commands for the real terminals next to it. This
file may contain sample getty lines for text terminals that are
@ -2976,13 +2994,27 @@ Two gettys best for modems (avoid for terminals) are:
<item> mgetty: the best one for modems; works for terminals too but inferior
<item> uugetty: for modems only; part of the getty_ps package
</enum>
A simple getty to use only where the monitor is the console. Most
Linux users with a text interface have this setup and don't use a real
text-terminal.
Simple gettys to use if you don't use a text-terminal. Most
Linux users use one of these at their monitor:
<enum>
<item> mingetty: for monitor-consoles only
<item> mingetty
<item> fbgetty
</enum>
Your Linux distribution should come with either ps_getty or agetty for
text-terminals. Unfortunately, they often just call it "getty" so you
may need to determine which one you have since the arguments you put
after it in /etc/inittab differ. Debian uses agetty (in the
util-linux package). RedHat uses ps_getty. As a last resort you
might check the source code (usually in /sbin). ps_getty has
/etc/gettydefs embedded in the source code. To search for it, go to
/sbin and type:<newline>
<tt>strings getty | grep getty </tt><newline>
If getty is actually agetty the above will result in nothing.
However if you have agetty typing:<newline>
<tt>getty -h</tt><newline>
should show the options [-hiLmw].
If you don't have the getty you want check other distributions and the
<tt/alien/ program to convert between RPM and Debian packages. The source
code may be downloaded from <url url=
@ -2994,6 +3026,33 @@ the minimum number of 3 conductors: transmit, receive, and common
signal ground) you should let getty know this by using a "local" flag.
The format of this depends on which getty you use.
<sect2> Programs get Stopped <label id="stopped_">
<p> You should normally run getty from inside <tt>/etc/inittab</tt>
and not from the command line or else some programs running on the
terminal may be unexpectedly suspended (stopped). Here's why (skip to
the next section if the why is not important to you). If you start
getty for say ttyS1 from the command line of another terminal, say tty1,
then it will have tty1 as its "controlling terminal" even though the
actual terminal it runs on is ttyS1. Thus it has the wrong
controlling terminal. But if it's started inside the inittab file
then it will have ttyS1 as the controlling terminal (correct).
Even though the controlling terminal is wrong, the login at ttyS1 works
fine (since you gave ttyS1 as an argument to getty). The standard
input and output are set to ttyS1 even though the controlling terminal
remains tty11. Other programs run at ttyS1 may inherit this standard
input/output (which is connected to ttyS1) and everything is OK. But
some programs may make the mistake of trying to read from their
controlling terminal (tty1) which is wrong. Now tty1 may think that
these programs are being run in the background by tty1 so an attempt
to read from tty1 (it should have been ttyS1) results in stopping the
process that attempted to read. (A background process is not allowed
to read from its controlling terminal.). You may see a message
something like: "<tt>[1]+ Stopped</tt>" on the screen. At this point
you are stuck since you can't interact with a process which is trying
to communicate with you via the wrong terminal. Of course to escape
from this you can go to another terminal and kill the process, etc.
<sect2> Agetty (may be named getty) <label id="agetty_">
<p> An example line in /etc/inittab: <newline>
<tscreen><verb>
@ -3146,6 +3205,7 @@ which runs <tt/stty/ since on seldom need it.
<sect1>What is Setserial ? <label id="set_serial">
Change Log:
May 2000: <sect2> IRQs near end ttyS0 -> ttyS1 + clarity
Nov. 2000: auto_irq may work on the 2nd try
-->
<p> This part is in 3 HOWTOs: Modem, Serial, and Text-Terminal. There
are some minor differences, depending on which HOWTO it appears in.
@ -3154,11 +3214,12 @@ are some minor differences, depending on which HOWTO it appears in.
<p> Don't ever use <tt/setserial/ with Laptops (PCMCIA).
<tt/setserial/ is a program which allows you to tell the device driver
software the I/O address of the serial port, which interrupt (IRQ) is
set in the port's hardware, what type of UART you have, etc. But the
plug-and-play features of the driver can do the same thing (provided
you serial port is both plug-and-play and is supported by the serial
driver software). So in this case you probably don't need to use
setserial for this purpose (and may not need to use it at all).
set in the port's hardware, what type of UART you have, etc. Since
theres a good chance that the serial ports will be automatically
detected and set, many people never need to use <tt/setserial/. In
any case setserial will not work without either serial support built
into the kernel or loaded as a module. The module may get loaded
automatically if you (or a script) tries to use setserial.
Setserial can also show how the driver is currently set. In addition,
it can be made to probe the hardware and try to determine the UART
@ -3228,10 +3289,13 @@ port address, any IRQ, and whatever uart type you would like to have.
Then the next time you type "setserial ..." it will display these
bogus values without complaint. Of course the serial port driver will
not work correctly (if at all) if you attempt to use such a port.
Thus when giving parameters to "setserial" anything goes. It gives
you no warning if what you tell it is incorrect and will allow you to
create conflicts in IRQs and I/O port addresses that will have
disastrous results later on.
Thus when giving parameters to "setserial" anything goes. Well
almost. If you assign one port a base address that is already assigned
(such as 3e8) it will not accept it. But if you use 3e9 it will
accept it. Unfortunately 3e9 is already assigned since it is within
the range starting at base address 3e8. Thus the moral of the story
is to make sure of your data before assigning resources with
setserial.
While assignments made by setserial are lost when the PC is powered
off, a configuration file may restore them (or a previous
@ -3264,16 +3328,18 @@ serial ports don't identify themselves correctly so if you see
"<tt/unknown/" you still might have a serial port there.
Besides auto-probing for a uart type, setserial can auto-probe for
IRQ's but this doesn't always work right either. In versions of
setserial >= 2.15, the results of your last probe test may be saved
and put into the configuration file <tt>/etc/serial.conf</tt> which
will be used next time you start Linux. At boot-time when the serial
module loads (or the like), a probe for UARTs is made automatically
and reported on the screen. But the IRQs shown may be wrong. The
second report of the same is the result of a script which usually does
no probing and thus provides no reliable information as to how the
hardware is actually set. It only shows configuration date someone
wrote into the script or data that got saved in /etc/serial.conf.
IRQ's but this doesn't always work right either. In one case it first
gave the wrong irq but when the command was repeated it found the
correct irq. In versions of setserial >= 2.15, the results of your
last probe test may be saved and put into the configuration file
<tt>/etc/serial.conf</tt> which will be used next time you start
Linux. At boot-time when the serial module loads (or the like), a
probe for UARTs is made automatically and reported on the screen. But
the IRQs shown may be wrong. The second report of the same is the
result of a script which usually does no probing and thus provides no
reliable information as to how the hardware is actually set. It only
shows configuration date someone wrote into the script or data that
got saved in /etc/serial.conf.
It may be that two serial ports both have the same IO address set in
the hardware. Of course this is not permitted but it sometimes
@ -3288,16 +3354,26 @@ equivalent" is built into the kernel) then only <tt/ttyS{0-3}/ are
auto-detected and the driver is set to use only IRQs 4 and 3
(regardless of what IRQs are actually set in the hardware). You see
this as a boot-time message just like as if <tt/setserial/ had been
run. If you use 3 or more ports, this may result in IRQ conflicts.
run.
To fix such conflicts by telling setserial the true IRQs (or for other
reasons) there may be a file somewhere that runs <tt/setserial/ again.
This happens early at boot-time before any process uses the serial
port. In fact, your distribution may have set things up so that the
setserial program runs automatically from a start-up script at
boot-time. More info about how to handle this situation for your
particular distribution might be found in file named "setserial..."
or the like located in directory /usr/doc/ or /usr/share/doc/.
To correct possible errors in IRQs (or for other reasons) there may be
a file somewhere that runs <tt/setserial/ again. Unfortunately, if
this file has some IRQs wrong, the kernel will still have incorrect
info about the IRQs. This file should run early at boot-time before
any process uses the serial port. In fact, your distribution may have
set things up so that the setserial program runs automatically from a
start-up script at boot-time. More info about how to handle this
situation for your particular distribution might be found in file
named "setserial..." or the like located in directory /usr/doc/ or
/usr/share/doc/.
Before modifying a configuration file, you can test out a "proposed"
<tt/setserial/ command by just typing it on the command line. In some
cases the results of this use of <tt/setserial/ will automatically get
saved in /etc/serial.conf when you shutdown. So if it worked OK (and
solved your problem) then there's no need to modify any configuration
file. See <ref id="new_config" name="New configuration method using
/etc/serial.conf">.
<sect2> Configuration Scripts/Files <label id="ss_conf_script">
<p> Your objective is to modify (or create) a script file in the /etc
@ -3312,11 +3388,11 @@ configuration file.
So prior to version 2.15 all you do is edit a script. After 2.15 you
may need to either do one of three things: 1. edit a script. 2. edit
<tt>/etc/serial.conf</tt> or 3. run "setserial" on the command line
which will result in <tt>/etc/serial.conf</tt> automatically being
which may result in <tt>/etc/serial.conf</tt> automatically being
edited. Which one of these you need to do depends on both your
particular distribution, and how you have set it up.
<sect2> Edit a script (after version 2.15: perhaps not)
<sect2> Edit a script (required prior to version 2.15)
<label id="old_sets_script">
<p> Prior to setserial 2.15 (1999) there was no /etc/serial.conf file
to configure setserial. Thus you need to find the file that runs
@ -3334,6 +3410,8 @@ Another file once used was <tt>/etc/rc.d/rc.local</tt> but it's
not a good idea to use this since it may not be run early enough.
It's been reported that other processes may try to open the serial
port before rc.local runs resulting in serial communication failure.
Today it's most likely in /etc/init.d/ but it isn't normally intended
to be edited.
If such a file is supplied, it should contain a number of
commented-out examples. By uncommenting some of these and/or
@ -3342,24 +3420,7 @@ sure that you are using a valid path for <tt/setserial/, and a valid
device name. You could do a test by executing this file manually
(just type its name as the super-user) to see if it works right.
Testing like this is a lot faster than doing repeated reboots to get
it right. Of course you can also test a single <tt/setserial/ command
by just typing it on the command line.
If you want setserial to automatically determine the uart and the IRQ
for ttyS3 you would add something like:
<tscreen><verb>
/sbin/setserial /dev/ttyS3 auto_irq skip_test autoconfig
</verb></tscreen>
Do this for every serial port you want to auto configure. Be sure to
give a device name that really does exist on your machine. In some
cases this will not work right due to the hardware so if you know what
the uart and irq actually are, may want to assign them explicitly with
"setserial". For example:
<tscreen><verb>
/sbin/setserial /dev/ttyS3 irq 5 uart 16550A skip_test
</verb></tscreen>
it right.
For versions >= 2.15 (provided your distribution implemented the
change, Redhat didn't) it may be more tricky to do since the file that
@ -3367,6 +3428,22 @@ runs setserial on startup, /etc/init.d/setserial or the like was not
intended to be edited by the user. See <ref id="new_config"
name="New configuration method using /etc/serial.conf">.
If you want setserial to automatically determine the uart and the IRQ
for ttyS3 you would add something like:
<tscreen><verb>
/sbin/setserial /dev/ttyS3 auto_irq skip_test autoconfig
</verb></tscreen>
Do this for every serial port you want to auto configure. Be sure to
give a device name that really does exist on your machine. In some
cases this will not work right due to the hardware. If you know what
the uart and irq actually are, you may want to assign them explicitly
with "setserial". For example:
<tscreen><verb>
/sbin/setserial /dev/ttyS3 irq 5 uart 16550A skip_test
</verb></tscreen>
<sect2> New configuration method using /etc/serial.conf
<label id="new_config">
@ -3515,20 +3592,19 @@ termios) which stores the stty configuration in computer memory. Many
of the flag names in this C-structure are almost the same (and do the
same thing) as the arguments to the stty command.
<sect2> Using stty for a "foreign" terminal
<p> Using <tt/stty/ to inspect or configure the terminal that you are
currently using is easy. Doing it for a different (foreign) terminal
or serial port may be tricky. For example, let's say you are at the
PC monitor (tty1) and want to use <tt/stty/ to deal with the serial
port ttyS2. Prior to about 2000 you needed to use the redirection
operator "<". After 2000 (provided your version of setserial is >=
1.17 and stty >= 2.0) there is an alternate method using the -F
option. This will work when the old redirection method fails. Even
with the latest versions be warned that if there is a terminal on
ttyS2 and a shell is running on that terminal, then what you see will
likely be deceptive and trying to set it will not work. See <ref
id="2_term_interfaces" name="Two Interfaces at a Terminal"> to
understand it.
<sect2> Using stty at a "foreign" terminal
<p> Using <tt/stty/ to configure the terminal that you are currently
using is easy. Doing it for a different (foreign) terminal or serial
port may be tricky. For example, let's say you are at the PC monitor
(tty1) and want to use <tt/stty/ to deal with the serial port ttyS2.
Prior to about 2000 you needed to use the redirection operator "<".
After 2000 (provided your version of setserial is >= 1.17 and stty >=
2.0) there is a better method using the -F option. This will work
when the old redirection method fails. Even with the latest versions
be warned that if there is a terminal on ttyS2 and a shell is running
on that terminal, then what you see will likely be deceptive and
trying to set it will not work. See <ref id="2_term_interfaces"
name="Two interfaces at a terminal"> to understand it.
The new method is ``stty -F /dev/ttyS2 ...'' (or --file instead of F).
If ... is -a it displays all the stty settings. The old redirection
@ -3575,15 +3651,15 @@ But it doesn't change any settings for ttyS2.
<sect2> Two interfaces at a terminal <label id="2_term_interfaces">
<p> When using a shell (such as bash) with command-line-editing
enabled there are two different terminal interfaces (what you see when
you type stty -a). When you type at the command line you have a
temporary "raw" interface (or raw mode) where each character is read
by the command-line-editor as you type it. Once you hit the
&lt;return&gt; key, the command-line-editor is exited and the terminal
interface is changed to the nominal "cooked" interface (cooked mode)
for the terminal. This cooked mode lasts until the next prompt is
sent to the terminal. Note that one never types anything to this
cooked mode but what was typed in raw mode becomes cooked mode as soon
as one hits the &lt;return&gt; key.
you type stty -a). When you type in modern shells at the command line
you have a temporary "raw" interface (or raw mode) where each
character is read by the command-line-editor as you type it. Once you
hit the &lt;return&gt; key, the command-line-editor is exited and the
terminal interface is changed to the nominal "cooked" interface
(cooked mode) for the terminal. This cooked mode lasts until the next
prompt is sent to the terminal. Note that one never gets to type
anything to this cooked mode but what was typed in raw mode becomes
cooked mode as soon as one hits the &lt;return&gt; key.
When a prompt is sent to the terminal the terminal goes from "cooked"
to "raw" mode (just like it does when you start an editor since you
@ -3600,8 +3676,8 @@ Now when one types stty to look at the terminal interface, one may
either get a view of the cooked mode or the raw mode. You need to
figure out which one you're looking at. It you use stty from another
terminal to deal with a terminal that is displaying a command line,
then the view is that of the raw mode. Any changes made will only be
made to the raw mode and will be lost when someone presses
then you will see the raw mode settings. Any changes made will only
be made to the raw mode and will be lost when someone presses
&lt;return&gt; at the terminal you tried to "set". But if you type a
stty command at your terminal (without using &lt for redirection) and
then hit &lt;return&gt; it's a different story. The &lt;return&gt;
@ -3616,10 +3692,12 @@ work! Of course you can try to type "stty sane ..." at the terminal
that is corrupted but you can't see what you typed. All the above not
only applies to dumb terminals but to virtual terminals used on a PC
Monitor as well as to the terminal windows in X. In other words, it
applies to almost everyone who uses Linux. Luckily, a file that runs
stty at boot-time will likely deal with a terminal (or serial port
with no terminal) that has no shell running on it so there's no
problem.
applies to almost everyone who uses Linux.
Luckily, when you start up Linux, any file that runs stty at boot-time
will likely deal with a terminal (or serial port with no terminal)
that has no shell running on it so there's no problem for this special
case.
<sect2> Where to put the stty command ? <label id="stty_where">
<p> Should you need to have <tt/stty/ set up the serial interface each
@ -3769,6 +3847,16 @@ else echo "From /etc/profile: Unknown terminal type $TERM"
fi
</code>
<sect1> Character Mapping: mapchan <label id="mapchan_">
<p> There is a program named "mapchan" which will map characters
(bytes) typed at a terminal keyboard (input) into different
characters per a user-supplied mapping table. It can also map
characters which are sent to the screen (output). This is nice for
remapping the keyboard for foreign language alphabets. Most
distributions don't seem to supply it (let me know if any do). Source
code by Yura Kalinichenko (Ukraine) is at <url
url="http://www.kron.vinnica.ua/free">
<sect>Terminfo and Termcap (detailed) <label id="termcap2">
<sect1> Intro to Terminfo
@ -4023,7 +4111,7 @@ terminal are OK. If the host computer is shut down (no power) what
you type at the terminal keyboard may appear on the screen since the
transmit and receive pins at the computer may be connected together
resulting in echoing of characters by an "off" computer. If you can't
log in when the host computer is running, see <ref id="trouble-shoot"
log in when the host computer is running, see <ref id="trouble_shoot"
name="Trouble-Shooting">.
<sect1> Terminal (Serial) Device Driver
@ -4378,19 +4466,19 @@ shell function. Then run it when you want to make the changes. One
way to make the changes semi-permanent is to put the commands in a
file that runs each time you login or start up the computer.
<sect1> Make a Terminal the Console <label id="term_as_console">
<sect1> Serial Console <label id="term_as_console">
<p> This is also called a "serial console". Many messages from the
system are normally only sent to the console (the PC monitor). Some
of the messages sent to the console at boot-time may also be seen on
any terminal after the boot succeeds by typing the command: dmesg. If
the boot failed this will not be of any use since the terminal can't
work without an operating system. It's possible to modify the Linux
kernel so as to make a terminal serve as the console and receive all
the messages from Linux intended for the console. Unfortunately, the
messages from the BIOS (which display on the monitor when a PC is
first started) will not display on this terminal (but still display on
the monitor).
<p> This will turn a text-terminal (or emulator PC) into a "serial
console". Many messages from the system are normally only sent to the
console (the PC monitor). Some of the messages sent to the console at
boot-time may also be seen on any terminal after the boot succeeds by
typing the command: dmesg. If the boot failed this will not be of any
use since the terminal can't work without an operating system. It's
possible to modify the Linux kernel so as to make a terminal serve as
the console and receive all the messages from Linux intended for the
console. Unfortunately, the messages from the BIOS (which display on
the monitor when a PC is first started) will not display on this
terminal (but still display on the monitor).
Some people do this when they run a PC without a monitor or keyboard.
Normally, a PC will not start up without a keyboard and video card but
@ -4398,17 +4486,23 @@ some BIOSs permit it. If you are lucky enough to have such a BIOS
that supports "console re-direct" you will likely then need to setup
the BIOS using the CMOS menus when you start your PC.
The method of creating a "serial console" depends on your kernel
version. In any case serial support needs to be compiled into the
kernel and not supplied as a module.
<sect2> For Kernels 2.2 or higher
<p> The instructions for creating a serial-console are included with
source code documentation in the file: serial-console.txt. Normally,
the device /dev/console is linked to tty0 (the PC console). For a
serial-console you create a new /dev/console which is a true device
(and not linked to something else). You must also put a statement
regarding the serial-console into /etc/lilo.conf and then run lilo.
This is because the equivalent of "setserial" needs to be run to set
up your serial-console before the kernel is loaded. See the above
mentioned documentation and the man page for lilo.conf for more
details.
serial-console you create a new /dev/console by
<tscreen><verb>
mknod -m 622 console c 5 1
</verb></tscreen>
You must also put statements regarding the serial-console into
/etc/lilo.conf and then run lilo. This is because the equivalent of
"setserial" needs to be run early before the kernel is loaded so that
the serial-console can display the booting. See the above mentioned
documentation and the man page for lilo.conf for more details.
Here is an example <tt>/etc/lilo.conf</tt> file contents (for ttyS0):
<tscreen><verb>
@ -4555,7 +4649,7 @@ be different depending on whether a shell is running on it, whether
it's at the "login" prompt, etc. Thus the stty configuration after
switching runlevels may vary.
<sect> Trouble-Shooting (software) <label id="trouble-shoot">
<sect> Trouble-Shooting <label id="trouble_shoot">
<p> If you suspect that the problem is a hardware problem, see the <ref
id="repair_" name="Repair and Diagnose"> section. If the problem
@ -4567,6 +4661,8 @@ Here is a list of possible problems:
Suspect the terminal is defective.
<item> <ref id="flow_ctrl_ng" name="Missing Text"> Either skips
over some text or displays some text OK and hangs.
<item> <ref id="stopped_" name="Programs get Stopped"> with
message "Stopped"
<item> <ref id="fast_respawn" name="Getty Respawning Too Rapidly">
(console error message)
<item> <ref id="after_login" name="Fails Just After Login">
@ -4599,7 +4695,7 @@ If the terminal isn't responding correctly (if at all) to what you
type to it, you may have a <ref id="corrupt_interface" name="Corrupted
Terminal Interface">.
<sect1> Terminal Newly Installed <label id="trouble-shoot_new">
<sect1> Terminal Newly Installed <label id="trouble_shoot_new">
<p> If you've just connected up a terminal to a computer per
instructions and it doesn't work this section is for you. If a
terminal that formerly worked OK doesn't work now then see <ref
@ -4629,20 +4725,28 @@ causes. You should deviate a little from this method based on hunches
and clues.
<sect1> Is the Terminal OK ? <label id="term_OK">
<p> A good terminal will usually start up with some words on the
screen. If these words convey no error message, its probably
OK. If there is no sign of power (no lights on, etc.) re-plug in the
<p> Many terminals will start up with some words on the
screen. If these words convey no error message, it's probably
OK. If there is no sign of power (a dark screen, etc.) re-plug in the
computer power cord at both ends. Make sure there is power at the
wall jack (or at the extension cord end). Try another power cord if
you have one. Make sure the terminal is turned on and that its fuse
is not blown. A blank (or dim) screen may sometimes be fixed by just
turning up the brightness and contrast using knobs or a keyboard key
in set-up mode. If it still won't work See <ref id="repair_"
name="Repair & Diagnose"> for tips on repairing it.
in set-up mode.
A terminal that's been stored for a long time may
take a while to "warm up" as the electrolytic capacitors heal
themselves under voltage. If it still won't work See <ref
id="repair_" name="Repair & Diagnose"> for tips on repairing it.
If the terminal starts up OK, but you suspect that something may be
wrong with it, go into "local mode" where is works like a typewriter
and try typing on it. See <ref id="local_mode" name="Local Mode">.
Before you have trouble, you should find out if your terminal displays
error messages if the hardware is bad. One way to test a terminal
for this is to turn it on with the keyboard unplugged and see if it
displays an error message.
<sect1> Missing Text <label id="flow_ctrl_ng">
<p> If some text displays on the terminal OK and then it stops
@ -4666,7 +4770,7 @@ Printing-HOWTO under "Serial devices" on how to fix this.
<sect2> Serial Module Not Loaded
<p> Use the "lsmod" command to see if the serial module is loaded.
<sect2> No Modem Control Voltage
<sect2> No Modem Control Signal
<p> If getty can't open and/or use a port because of the lack of a
positive modem control voltage on one of the pins, then getty might
be killed. Then, per the instructions in inittab, getty respawns and
@ -4759,7 +4863,10 @@ approach are (you may pursue more than one at a time).
<p> At the console (or another working terminal), use "top" or "ps
-al" to see if getty is running on the port. Don't confuse it with
getty programs running on other ports or on the virtual consoles. You
will not get a login prompt unless getty runs.
will not get a login prompt unless getty runs. If getty isn't
running, carefully check the format for calling getty in /etc/inittab.
Make sure that it includes the current runlevel (shown by typing the
command "runlevel") and that it is valid for your flavor of getty.
One test is to try to copy a short file to the terminal (It might be a
good idea to try this near the start of the installation process
@ -4838,8 +4945,14 @@ behaves like a typewriter (only it doesn't type on paper but on the
screen). Going back into on-line mode reconnects to the computer
allowing you to resume activities at the same point where you left off
when you went into "local". This is useful both for testing the
terminal and for educational purposes. Some terminals use "block
mode" as the "local mode".
terminal and for educational purposes. For some terminals there is
no "local mode" but "block mode" may substitute for it. If there is
no "block mode", "half duplex" mode might work something like this
except that what you type gets sent to the computer also. In this
case the computer may echo the characters sent to it resulting in two
characters displayed on the screen for every character you type. To
prevent this you could shut down the computer, disconnect the RS-232
cable, etc.
When in local mode you may type escape sequences (starting with the
ESC key) and observe what they do. If the terminal doesn't work