== The many consoles of Linux

People who are considering setting up serial consoles for their Linux
machines often wind up a little bit confused about what's necessary
and what sort of features are possible. A lot of this is natural,
because the PC is fundamentally convinced that the console is the more
or less mandatory video display.

This results in a situation where there are many different consoles in
a Linux system. I'll inventory them, in the order that they get
encountered during booting a system.

# where the BIOS output appears. Expensive servers (and expensive
  addins) can change this from 'only the video display'
# what the bootloader talks to; how to configure this varies with the
  bootloader. 
# where Linux kernel messages go. This is set by the kernel's
  '_console=..._' arguments; you can specify multiple places. The
  kernel listen for so-called 'magic SysRq' keys on all of these.
# what is _/dev/console_. This has to be a single real device, and
  is either the last _console=..._ device listed or the video console.
# where you can log in after the kernel has finished booting, which is
  determined by what _/etc/inittab_ says to start _getty_ on.

_/dev/console_ is what _init_ talks to during system startup (and
system shutdown). This means that it's where startup messages appear
(barring things like Red Hat's simplified graphical boot process) and
what you need to interact with during single-user mode or if an
automated _fsck_ fails and needs a person to help it out.

In many situations, the ideal answer for 'what device is the console'
is 'both the video display and a serial line', and most of these many
consoles allow this. _/dev/console_ is the unfortunate exception; you
have to pick just one, because the Linux kernel requires it to map to
only a single real device.

(I sympathize with the Linux kernel about _/dev/console_,
honestly. The issues involved with merging simultaneous input from
multiple real terminal devices are kind of tricky, especially if you
want to avoid hooking into very low-level input routines down in the
depths of drivers.)