Remote Serial Console HOWTO Mark F. Komarinski            mkomarinski@valinux.com          Revision History Revision 0.1 2001-03-20 Revised by: mfk First revision Most UNIX-based systems have the concept of a serial console. Linux is no exception to this, and this document covers how to set up your hardware to use a serial console. ----------------------------------------------------------------------------- Table of Contents 1. Introduction 1.1. Copyright Information 1.2. Disclaimer 1.3. Credits 1.4. Feedback 2. Why use Serial Consoles? 3. Configuring Linux for Serial Consoles 3.1. Configuring LILO and the Linux Kernel 3.2. Configuring getty for use with serial ports 4. Serial Port Applications 4.1. Minicom 5. Cabling serial ports together 1. Introduction 1.1. Copyright Information This document is copyrighted (c) 2001 Mark F. Komarinski and is distributed under the terms of the Linux Documentation Project (LDP) license, stated below. Unless otherwise stated, Linux HOWTO documents are copyrighted by their respective authors. Linux HOWTO documents may be reproduced and distributed in whole or in part, in any medium physical or electronic, as long as this copyright notice is retained on all copies. Commercial redistribution is allowed and encouraged; however, the author would like to be notified of any such distributions. All translations, derivative works, or aggregate works incorporating any Linux HOWTO documents must be covered under this copyright notice. That is, you may not produce a derivative work from a HOWTO and impose additional restrictions on its distribution. Exceptions to these rules may be granted under certain conditions; please contact the Linux HOWTO coordinator at the address given below. In short, we wish to promote dissemination of this information through as many channels as possible. However, we do wish to retain copyright on the HOWTO documents, and would like to be notified of any plans to redistribute the HOWTOs. If you have any questions, please contact ----------------------------------------------------------------------------- 1.2. Disclaimer No liability for the contents of this documents can be accepted. Use the concepts, examples and other content at your own risk. As this is a new edition of this document, there may be errors and inaccuracies, that may of course be damaging to your system. Proceed with caution, and although this is highly unlikely, the author(s) do not take any responsibility for that. All copyrights are held by their by their respective owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark. Naming of particular products or brands should not be seen as endorsements. You are strongly recommended to take a backup of your system before major installation and backups at regular intervals. ----------------------------------------------------------------------------- 1.3. Credits This HOWTO is based on /usr/src/linux/Documentation/serial-consold.txt, written by Miquel van Smoorenburg (). Many thanks to Miquel for the information in his document. ----------------------------------------------------------------------------- 1.4. Feedback Feedback is most certainly welcome for this document. Without your submissions and input, this document wouldn't exist. Please send your additions, comments and criticisms to the following email address : < mkomarinski AT valinux.com>. ----------------------------------------------------------------------------- 2. Why use Serial Consoles? Serial consoles do not appear to have much going for them. They are slow, require special null-modem cables, and do not provide a graphical interface. But what is going for them is considerable. Serial cables are standard equipment and can run over RJ-45 cables, can run up to 200 ft (about 100m) at 9600bps. Serial concentrators can run the consoles of over 32 ports into a central box, so all the consoles in a cluster can be accessed from a single location. You will not require a crash cart, KVM switch, or keyboard, montior, or mouse. Because of the serial concentrator, you can access the console of a machine in a colocation cage from your desktop. The real limiting factor so far has been that even though you can access the Linux console via a serial port, most x86 hardware was not set to send its POST and BIOS information to the serial port. More and more "server" motherboards are starting to include full serial support in the BIOS, so you can access the BIOS and make boot changes via the serial port. ----------------------------------------------------------------------------- 3. Configuring Linux for Serial Consoles There is two parts to getting a serial console set up under Linux. First, you must tell Linux to redirect its console output to the serial port. Second, you must set up mgetty to start a login process on the serial port once the kernel has completed booting. Some distributions use mingetty for the video console, but mingetty has no serial port support. You will instead want to use mgetty. A third (optional) configuration is to set the hardware BIOS to redirect its POST and BIOS information to the serial port. Check your motherboard documentation for more information about this. ----------------------------------------------------------------------------- 3.1. Configuring LILO and the Linux Kernel If you're using LILO as your bootloader, you can quickly test using serial console from Linux by entering: LILO: Linux console=ttyS0,9600n8 Assuming the LILO tag for your Linux kernel is called "Linux". Change this for the name of your kernel. The generic format for the console option is console=device,options. You can give multiple console statements, and kernel messages will go to all listed devices, but the last one listed will be used as /dev/console. +-------+-------------------------------------------------------------------+ |device |The device entry to use as the console without /dev/. You can use | | |tty0 to get normal behavior, ttyx to put the console on another | | |virtual console, or ttySx to put the console on a serial port. | +-------+-------------------------------------------------------------------+ |options|This is mostly used for passing options to the serial port. The | | |format for this is BPN, where B is speed in bps (so use 9600, | | |19200, 38400, etc.). The P is parity and is one of three letters: n| | |for no parity, e for even parity, and o for odd parity. The N is | | |the number of data bits, and is usually either 7 or 8. The default | | |is 9600n8. Most users will want to use the default, or increase the| | |speed to 19200 bps. | +-------+-------------------------------------------------------------------+ You should see the Linux kernel start through the decompression process then you will see no more on-screen information until the kernel has completed and mgetty starts up a login prompt on the screen. If you are monitoring the serial port, you'll see the Linux bootup information coming over the serial port. However, you probably will not see a login prompt on the serial port (yet). We'll cover that in Section 3.2. Once you are sure this is working, you can now edit LILO to pass this information to the kernel each time it boots. You can also configure LILO to send its prompt to the serial port. Fire up your favorite editor of choice and load up the /etc/lilo.conf file. You will want to add two lines, one to the general configuration and one to the specific kernels you want to use. serial=0,9600n8 append="console=tty0 console=ttyS0,9600n8" The append statement contains the statement we listed above, and tells Linux to send its output to the serial port. The serial command goes to LILO, and tells it to open port 0 (ttyS0, or COM1). The options for serial are the same as to the console statement. Note: Make sure the serial port settings for serial and console are the same. If they are different, you will need to change your serial port application between LILO and the kernel, which becomes very inconvenient. Re-run /sbin/lilo and reboot. You should now see everything except the login prompt on the serial port. Information should still be going to the monitor, just in case you have problems with the serial port. ----------------------------------------------------------------------------- 3.2. Configuring getty for use with serial ports Some distributions may ship with mingetty that does not support serial ports. The first thing you have to do is make sure the version of getty you are using supports serial ports. Both agetty and mgetty do this. So run off now using your favorite packaging system to make sure this is the case. Don't worry, this document will still be here when you get back. Back so soon? Great! Let's get that serial port configured. You will want to make sure that all your serial port settings are consistent. No sense in making getty run at 9600bps, while LILO and the kernel are talking 19200. To get login prompts to appear on the serial port, edit the /etc/inittab file and add a line similar to the following: s0:2345:respawn:/sbin/getty ttyS0 DT9600 The format for entries in inittab are covered in most basic Linux and UNIX books, but to repeat, each field is separated by a colon (:) and represent:   * s0 - Arbitrary entry for inittab. As long as this entry doesn't appear anywhere else in inittab, you're okay. We named this entry s0 because it's for ttyS0.   * 2345 - run levels where this entry gets called. If we switch to runlevel 1, this getty process will be shut down.   * respawn - re-run the program if it dies. We want this to happen so that a new login prompt will appear when you log out of the console.   * /sbin/getty ttyS0 DT9600 - the command to run. In this case, we're telling getty to connect to /dev/ttyS0 using the settings for DT9600 which exist in /etc/gettydefs. This entry represents a dumb terminal running at 9600bps. There are other entries that run at different speeds. The entries in /etc/inittab will be loaded into init when root sends a HUP signal. # kill -HUP 1 Note: Remember that init always has a PID of 1. Now that getty is set up, you will be able to go from powerup to login prompt all over the serial port ----------------------------------------------------------------------------- 4. Serial Port Applications This section covers applications and some configuration information that you can use to look at your serial console, now that your Linux boxes are talking to the serial port. ----------------------------------------------------------------------------- 4.1. Minicom Minicom is one of the easier serial port applications to use. It is curses based, so it's a full screen application with a status bar, menus, and an easy-to-use interface. It is installed on most distributions, and initially has to be run as the root user. In some cases, minicom will be installed suid root, so anyone will be able to access the configurations. Check the documentation for your particular distribution to see how it's configured. Security of minicom is set by the /etc/minicom.users file. Usernames can that are listed along with a configuration can use the listed configurations. This allows only authorized users to connect to the serial ports. Minicom creates individual configurations to separate files. Configure the serial port as needed, then save the configuration. Files are kept in /etc with a prefix of minirc. ----------------------------------------------------------------------------- 5. Cabling serial ports together Since you will be connecting two DTEs together, you will need to have a null modem run between the two devices. A null modem crosses transmit and receive, and ties a few status lines together so the application can open the port. This null modem can be a dongle that connects to the cable, or can be built into the cable. A dongle will get expensive if you have a large number of cables, so it is usually easier to get cables with the null modem built in. Most PC hardware these days use DB-9 connectors, giving 9 pins for transmitting data and status, which is fine for us. Pre-built DB-9 cables can be had for a few dollars for a few feet of cable. More flexible is building a DB-9 to RJ-45 connector and building the null modem into that. The RJ-45 connector then accepts regular 10BaseT cables that can be custom-built, or with varying legths. This gives a lot of flexibiliy in arranging cables, since each cable can be the correct length to run between machines. Little extra cable is left lying around. DB-9 to RJ-45 connectors can be purchased unassembled since there are no real standards for making this conversion. So long as Tx and Rx cross and CTS RTS cross, you have a null modem connection. The cabling I have here comes from my own design, and works just fine. Note that there have to be two different DB-9 to RJ-45 connectors because of the way pins are switched. I labeled them as "1" and "2". They can be placed on either end of the cable. Table 1. DB9 to RJ-25 connector +-----------+-----------+ |Connector 1|Connector 2| +-----+-----+-----+-----+ |DB-9 |RJ-45|DB-9 |RJ-45| +-----+-----+-----+-----+ |1 |5 |1 |5 | +-----+-----+-----+-----+ |2 |6 |2 |4 | +-----+-----+-----+-----+ |3 |4 |3 |6 | +-----+-----+-----+-----+ |4 |7 |4 |7 | +-----+-----+-----+-----+ |5 |3 |5 |3 | +-----+-----+-----+-----+ |6 |2 |6 |2 | +-----+-----+-----+-----+ |7 |1 |7 |8 | +-----+-----+-----+-----+ |8 |8 |8 |1 | +-----+-----+-----+-----+ |9 |n/c |9 |n/c | +-----+-----+-----+-----+