![]()
Running Linux servers on x86 class hardware in the data center environment is complicated by the need for a CRT/KBD/Mouse for each server (or at least one CRT/KBD/Mouse set and a large KDM switch). If you have come from the Sun/IBM/HP world, you are used to the notion of full control over a serial port. This document describes how to get most of the same serial port functionality from a Linux installation on x86 hardware. Unfortunately, this configuration is OS and hardware dependant, and while I will describe the details for a Rackable system running RedHat Advanced Server 3.0, I will also try to give enough general information to allow you to configure a generic OS running on generaic x86 hardware.
There are five basic things that must be done to obtain x86/linux console functionality via a serial port. You must be able to redirect the BIOS output, you must direct the boot loader output (and disable graphics mode), you must configure the kernel to use the serial port for console I/O, you need to enable logins on the desired port, and finally a number of system utilities need to be made aware of the newly configured serial ports. Because most of our other serial devices use 9600 baud, 1 stop, 8 bits; this is how we will configure the console ports.
BIOS console redirection is a vendor specific configuration. Some vendors use it to mean the redirection of the VGA output and keyboard to a remote PC using a proprietary serial protocol; while others actually mean redirection of the BIOS I/O to a serial port. If you are dealing with the situation of VGA/KBD redirection using a proprietary protocol, you can only use this feature in conjunction with the Linux serial console if the BIOS can be instructed to disable redirection after loading the boot loader. In general the following two methods of BIOS redirection are used, which one you have will determine several key aspects of this setup.
The BIOS takes the interrupt 0x10 "video" requests used to write to the screen and sends the characters that would have appeared on the screen to the serial port. Characters recieved from the serial port are used to supply characters to BIOS interrupt 0x16 "read key" requests. Any 16-bit application which uses the BIOS functions for outputing text to the screen and reading from the keyboard is redirected to the serial port. This includes the BIOS itself, the boot loader, and 16-bit operating systems (such as MS-DOS). Additionally BIOS redirection usually fills in the serial slot data with NULL entries, making it impossible for the boot loader to read the COM1/COM2 configuration parameters. These NULL values will cause some boot loaders to crash (LILO) as they try to configure the device port 0x000. If your BIOS uses this technique then you should:
BIOS configuration and power on self-test use the serial port. These BIOSs do not redirect the 0x10 "video" requests or 0x16 "read key" requests to the serial port. You may also encounter a BIOS that redirects keyboard and video output to the serial port and that can be configured to redirect BIOS input and output only. (HINT: Look for a BIOS configuration option similar to Cease redirection after boot.) If your BIOS uses this technique or you choose to set Cease redirection after boot then you should:
Of course you may have a BIOS that does not support console redirection. in which case power-on and self-test messages cannot be seen, nor can you configure the BIOS parameters at pre-boot time from the serial port. You can still modify some BIOS parameters via /dev/nvram at your own risk.
You may notice that some of the BIOS messeges are only partially displayed, due to the increased latency of the serial port. Additionally you may notice that the portions of the SETUP menus that display values in real-time (like the clock and count-down delays) have trouble updating. To allow more time for entering SETUP and adaptor ROM configuration menus, you should increase these timeouts to account for the increased latency.
Boot-loader redirection is easily accomplished in both LILO and GRUB. You must make sure to disable bitmaps and splashimages, as these will put the loader into a frame buffer mode that is not compatible with the pure text mode required over a serial link. Additionally it is desirable to disable VGA mode.
Console redirection at the kernel level requires that support has been compiled into the kernel image. In the case of RedHat Advanced Server 3.0, the kernel has console support. It is enabled by passing the console parameter to the kernel from the boot loader at startup.
Enabling serial port logins is accomplished by having init start (and monitor) an agetty process for each serial port configured. You may also want to enable root logins by adding the ports to /etc/securetty.
There are quite a few system utilities that need to be reconfigured before using the newly created serial login. They range from PAM to kudzu.
The procedure will address the system configuration in the reverse order as has been presented. The rational for this is that we can test pieces of the system as they are modified.
First verify which com ports your hardware physically has. This is done via dmesg | grep tty. Usually something similar to the follwing will be produced:
ttyS0 at 0x03f8 (irq = 4) is a 16550A ttyS1 at 0x02f8 (irq = 3) is a 16550A
Add 1 or both of the following lines to /etc/inittab depending on which com ports you have. (note that ttyS0 corrosponds to COM1, and ttyS1 corrosponds to COM2)
# setup agetty on serial ports
s0:2345:respawn:/sbin/agetty -L -f /etc/issue 9600 ttyS0 vt100
s1:2345:respawn:/sbin/agetty -L -f /etc/issue 9600 ttyS1 vt100
Ultimately you will NOT have a KBD/CRT plugged into the server so you may as well disable the getty services on those devices. Comment out the following lines in /etc/inittab:
# Run gettys in standard runlevels
#1:2345:respawn:/sbin/mingetty tty1
#2:2345:respawn:/sbin/mingetty tty2
#3:2345:respawn:/sbin/mingetty tty3
#4:2345:respawn:/sbin/mingetty tty4
#5:2345:respawn:/sbin/mingetty tty5
#6:2345:respawn:/sbin/mingetty tty6
Disable xdm by commenting out the following line in /etc/inittab:
# Run xdm in runlevel 5
#x:5:respawn:/etc/X11/prefdm -nodaemon
Finally set the default runlevel to 3 by insuring initdefault is called a run level 3. This will keep the system from going to run level 5 and starting up the Xserver. Use the following line in /etc/inittab:
id:3:initdefault:
Allow root logins on the serial device by adding the following lines to /etc/securetty:
ttyS0
ttyS1
Once you have done this, it is nessecary to inform init of the changes by executing:
telinit q (or init q)
At this point you can plug a serial device (terminal) into one of the ports that you have configured, and you'll get a login prompt. You should be able to login as root and do your thing. The current state of the system is such that you have a serial terminal that is active after the system boots up.
In the process of probing for new hardware, kudzu can cause confusion and interfere with the console operation. So you need to configure kudzu to not probe the serial lines by making the following modifications to /etc/sysconfig/kudzu:
SAFE=YES
Additionally you could completely disable kudzu (which has a benefit of ensuring that your hardware configuration stays put, regardless of who plugs what in)
chkconfig kudzu off
Insure that the serial console is NOT configured as /dev/modem:
rm /dev/modem
Configure PAM support for the serial console by adding the following entry in /etc/security/console.perms
<sconsole>=ttyS[0-1]
And modify the following <console> device
entries to <sconsole>:
<sconsole> 0660 <floppy> 0660 root.floppy
<sconsole> 0600 <sound> 0600 root
<sconsole> 0600 <cdrom> 0660 root.disk
<sconsole> 0600 <pilot> 0660 root.uucp
<sconsole> 0600 <jaz> 0660 root.disk
<sconsole> 0600 <zip> 0660 root.disk
<sconsole> 0600 <ls120> 0660 root.disk
<sconsole> 0600 <scanner> 0600 root
<sconsole> 0600 <camera> 0600 root
<sconsole> 0600 <memstick> 0600 root
<sconsole> 0600 <flash> 0600 root
<sconsole> 0600 <mainboard> 0600 root
<sconsole> 0600 <rio500> 0600 root
Console usage will be interlaced with syslog output. This is confusing and irritating at times. (such as during an editor session.) Syslog and some debug output can be restricted and filtered from the serial console. Additionally you can eleiminate non-local syslog messages and system broadcast messages from getting to the console.
Restrict console messages from the system log (syslogd) by removing lines in /etc/syslog.conf that send output to /dev/console.
Ensure that syslogd is NOT accepting remote syslog messages by removing the r flag from the SYSLOGD_OPTIONS in /etc/sysconfig/syslog
Restrict broadcast messages to the console by adding the following files to /etc/profile.d. Note that you need to change /dev/ttyS0 to match the actual serial port that you are using.
#
# /etc/profile.d/mesg.sh -- prevent people hassling the serial console user
[ -x /usr/bin/mesg -a -x /usr/bin/tty -a `/usr/bin/tty` = /dev/ttyS1 ] && /usr/bin/mesg n
#
# /etc/profile.d/mesg.csh -- prevent people hassling the serial console user
if (-X mesg && -X tty && `tty` == /dev/ttyS1) then
mesg n
endif
chown root:root /etc/profile.d/mesg.*sh
chmod u=rwx,g=rx,o=rx /etc/profile.d/mesg.*sh
Modify /etc/sysconfig/init to use terminal independent commands to write init status messages by modifying the BOOTUP line in /etc/sysconfig/init to:
BOOTUP=serial
You should think about disabling the hot-key interactive startup by setting the PROMPT line to:
PROMPT=no
Additionally turn off the graphical boot by modifying the GRAPHICAL line to:
GRAPHICAL=NO
One additional feature that can be enabled is Magic SysRq, this essentially behaves like the BREAK functionality of Sun's OBP. If you send a BREAK from the serial console (or ALT-PrtScreen from a connected KBD), you will have 5 seconds to enter a debugger command. (H for help). The debugger will work even when the kernel has crashed in some cases. THIS FEATURE IS VERY DANGEROUS IN THAT YOU CAN FORCE A POWER-DOWN OR IMMEDIATE RESET WITH A SINGLE KEY. This feature is enabled at run-time by the following command.
echo 1 > /proc/sys/kernel/sysrq
To setup kernel console redirection in the boot-loader, you need to add an additional parameter to the kernel invocation. This is really as simple as adding a boot line parameter in /etc/lilo.conf or /etc/grub.conf that is passed to the kernel during load time.
image=/boot/vmlinuz-2.4.22-1.2115.nptlsmp
label=linux
initrd=/boot/initrd-2.4.22-1.2115.nptlsmp.img
read-only
append="rhgb root=LABEL=/ console=ttyS1,9600"
title Fedora Core (2.4.22-1.2115.nptlsmp)
root (hd0,0)
kernel /vmlinuz-2.4.22 ro root=LABEL=/ rhgb console=ttyS1,9600
initrd /initrd-2.4.22-1.2115.nptlsmp.img
At this point you must determine how your BIOS handles console redirection before you can determine wether or not to enable boot loader console redirection.
To enable console redirection in LILO add one of the following lines into the global section of /etc/lilo.conf depending on which serial port you are configuring as the console:
serial=0,9600n8 # for COM1
serial=1,9600n8 # for COM2
To enable console redirection in GRUB add one of the following serial lines as well as the terminal definition into /etc/grub.conf. The serial statement defines the port parameters, the terminal statement actually sets the redirection. (In this case both /dev/tty0, the console, and /dev/ttyS1, the serial port, are redirected.)
serial --unit=0 --speed=9600 # define port for COM1
serial --unit=1 --speed=9600 # define port for COM2
terminal --timeout=10 serial console # sets output
In addition to enabling (or not) serial console redirection in the boot loader, you will need to disable graphic and VGA mode output. You can also disable the frame-buffer mode at the kernel startup by adding the video=vga16:off. A brief discussion about VGA modes is in order here. LILO and GRUB support many types of VGA modes; common values are 771, 791, and 794. These values represent bit resolutions of 800x600, 1024x768, and 1280x1024 respectively. These values would be used in the vga stanza of /etc/lilo.conf and the stanza of /etc/grub.conf.
# Customized boot message
#message=/boot/bootmess.txt
#bitmap=/boot/linuxbits.xpm
# ensure vga 80X25 text mode
vga=normal
image=/boot/vmlinuz-2.4.22-1.2115.nptlsmp
label=linux
initrd=/boot/initrd-2.4.22-1.2115.nptlsmp.img
read-only
append="rhgb root=LABEL=/ video=vga16:off"
# boot image
#splashimage=(hd0,0)/grub/splash.xpm.gz
title Fedora Core (2.4.22-1.2115.nptlsmp)
root (hd0,0)
kernel /vmlinuz-2.4.22 ro root=LABEL=/ rhgb video=vga16:off
initrd /initrd-2.4.22-1.2115.nptlsmp.img
You should also enable restricted password access for the boot loader. Note well, the boot loader configuration file will have the password in clear text, so you should set the file permissions to 0600 (i.e. read-only by owner). You can also set the immutable attribute on the file using the /usr/bin/chattr +i filename command. This will prevent any changes, accidental or otherwise, to the configuration file. If you wish to modify the file, you must unset the immutable attribute, via /usr/bin/chattr -i filename, before you can modify the file.
restricted
password=TypeThis
prompt
#boot=/dev/sda
password TypeThis
#splashimage=(hd0,0)/grub/splash.xpm.gz
At this point should have a CRT/KBD and a terminal plugged into the system. A reboot should yield the following:
In general we are trying to setup the BIOS to boot regardless of what may be happening around it. This means boot without a KBD, boot without needing to press <F1> on errors. Boot from only specific devices (so that when that special person inserts a blank floppy - the BIOS doesn't get distracted and halt)
Using the AMIv02.33 BIOS, the following non-default configuration values are applied:
Remote Access [Serial]
Serial port number [COM2]
Serial Port Mode [9600 8,n,1]
Flow Control [None]
Terminal Type [VT100]
Send Carriage Return [Disabled]
Redirection After BIOS POST [Boot Loader]
After Power Failure [Previous State]
Quick Boot [Disabled]
Quiet Boot [Disabled]
AddOn ROM Display Mode [Force BIOS]
Bootup Num-Lock [Off]
PS/2 Mouse Support [Disabled]
System Keyboard [Present] DONT'T CHANGE THIS
Wait For 'F1' If Error [Disabled]
Hit 'DEL' Message Display [Enabled]
Primary Display Device [Auto]
1st Boot Device [3ware Storage Cont]
2nd Boot Device [Disabled]
Increase PXE ROM setup delay to 5 seconds.
After having done all of this, you should now be able to remove the local CRT/KBD/Mouse from the server and happily manage all aspects of the boot process from a serial connection via ttyS0 or ttyS1. What follows are some notes on how to use the Phantom controller cards to power cycle and reset the hardware. Additionally I will discuss some useful LILO and GRUB command lines.
All of the Rackable Systems come equiped with a special serial port that intercepts special control characters and performs functions such as processor resets and power supply control functions. This card occupies ttyS1 (or COM2); thus, all of these systems use ttyS1 for the serial console.
The command mode of the Phantom card may be accessed at any by entering a ^6 (0x1e) character from the serial console. You will will be presented with the following prompt:
Phantom [? for Help]:
Server is on/off
In order to boot into single-user, you must pass the single parameter to the kernel on startup. Currently our LILO and GRUB configurations do NOT include single-user boot definitions. It is reletively easy to interrupt the boot loader and append the single parameter to the boot command line and thus force a single-user boot.
boot: linux single or
boot: linux emergency
kernel /vmlinuz-2.4.22-1.2115.nptlsmp ro root=LABEL=/ rhgb console=ttyS1,9600 single