next up previous contents
Next: Network console Up: Collecting kernel messages Previous: Syslog, console and dmesg   Contents

Serial console

The method of collecting kernel messages with the help of the serial console has two important drawbacks. First, it requires a serial port to be present in the computer running the tested kernel (''test bed computer'') that will generate the messages of interest, so it cannot be used, for example, with the majority of contemporary notebooks. Second, it requires you to use another computer for receiving the messages. On the other hand, the serial console can be used for collecting messages generated in the early stage of the kernel's life time.

To use the serial console you need to connect one of the test bed computer's serial ports (often referred to as a COM ports) to a serial port installed in the other computer (this serial port may be emulated, for example with the help of a USB-to-serial converter) with a so-called null modem cable.

You also need to configure the tested kernel to support the serial console:

Device Drivers  --->
Character devices  --->
Serial drivers  --->
<*> 8250/16550 and compatible serial support
[*]   Console on 8250/16550 and compatible serial port
and you need to tell the kernel to actually use it, for example by appending the following parameters to the kernel's command line:
console=ttyS0,115200n8 console=tty0
(the console=tty0 means that we want the kernel to use the virtual terminal 0 as a console apart from the serial one). Additionally, if you use GRUB as the boot loader, you can teach it to receive commands via the serial link from the other machine, for example by adding the following lines to its configuration file (usually /boot/grub/menu.lst):
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal --timeout=5 serial console
Still, this is not necessary if you have a ''normal'' keyboard and monitor attached to the test bed machine (refer to the documentation of GRUB for more information about the options used above).

Usually, it also is a good idea to configure the test bed system to use the serial console as one of its terminals. In Fedora you can do it according to the instructions below, but the other distributions may require you to modify the system configuration in a different way.

First, edit the file /etc/sysconfig/init and assign the value serial to the variable BOOTUP . Next, in the file /etc/sysconfig/kudzu set SAFE=yes and in /etc/securetty add ttyS0 . Now, add the line

S1:23:respawn:/sbin/mgetty -L ttyS0 115200 vt100
to /etc/inittab (this requires you to have the mgetty package installed). It is recommended to apply these changes to all systems on which you intend to use the serial terminal (you can always comment out the settings that enable it when it is no longer necessary).

Of course, the machine that will receive the messages over the serial link has to be configured too, but this usually is quite straightforward. First, run

# minicom -o -C log.txt
on it (you need to do this as root). Most probably you will get the error message
Device /dev/modem/ acces failed: (...)
which means that minicom could not find the special device file /dev/modem . To overcome this problem you can, for example, create a symbolic link from ttyS0 to it
# ln -s /dev/ttyS0 /dev/modem
and then minicom should run. It still is necessary to set up minicom itself, but this can be done with the help of its configuration menu. By default minicom is configured to use modem lines, so you have to change this setting. You also need to set the serial link's transmission parameters to reflect the settings that you have done on the test bed computer (note that some serial ports do not work with the highest baud rates and in such cases you will need to decrease the baud rate and this has to be done on both ends of the serial link, because they both must use exactly the same parameters of transmission).

For more information about using the serial console with the Linux kernel refer to the file Documentation/serial-console.txt included in the kernel sources.


next up previous contents
Next: Network console Up: Collecting kernel messages Previous: Syslog, console and dmesg   Contents
MichaƂ Piotrowski 2007-06-21