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 portand 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 consoleStill, 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 vt100to
/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.txton 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/modemand 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.