Serial console/remote install discussion

Jeremy Chadwick koitsu at
Fri Sep 21 09:19:22 PDT 2007

I'd like to open up a discussion regarding FreeBSD serial console and
the aspect of installation via serial console.

There seem to be quite a few surprises in regards to installing (or even
using!) FreeBSD this way.  I thought I'd mention some of them, in hopes
that by bringing them to light we can work towards making the
installation process easier, or at least more headless-friendly.

1) Administrators are required to "build their own installation disks"
(the Handbook goes over this with regards to floppy disks) if they want
FreeBSD installs to support serial console.  Based on what I've read,
the procedure is required because the stock installation disks lack a
/boot.config that contains -h.

Has anyone ever proposed including a /boot.config on all the
installation mediums that contains -P by default?  I don't know how
reliable -P is, but I've used it for years on numerous servers (all
different hardware) without any issues; others may have different

Which brings me to the next item...

2) FreeBSD's serial vs. VGA concept (keyword: versus) is disheartening.
The whole "one or the other" concept is unrealistic in this day and age,
and this was more or less admitted by the Dragonfly folks when they
re-wrote whatever code to get simultaneous dual console (VGA+serial)

Matt (Dillon) can probably talk more about this in detail; I remember
reading a thread long ago that stated "much work had to be done" to get
Dragonfly to do it, and I'm left wondering why we haven't moved that
direction with FreeBSD.  No offence intended, of course.

I consider this feature fairly important, and here's why: there is
nothing more annoying than going to the co-lo and having to reboot a
running server simply because the actual "console" itself is still
considered the serial port.  My opinion is that I should be able to use
both (VGA or serial) at any time, not "one or the other".

3) Stock kernel serial port speed maximum is still set to 9600bps.  For
many years I've tried to understand the justification behind this.
Out-of-the-box, serial console speeds >9600 cannot be achieved without
setting -S115200 in /boot.config or using options CONSPEED=115200 in a
kernel config (which only gets you that speed once the kernel is loaded,
of course).

You supposedly can also say -S0 to tell the bootloader "don't mess with
the serial port at all", for systems which have BIOS-level serial
console redirection (and retain that ability *after* POST; Supermicro
server BIOSes support the toggling of this ability, for example).
Documentation for this feature is lacking, but I did see it mentioned in
a commit log a while back.

There's nothing more unfuriating than installing FreeBSD, editing the
/etc/ttys entry for ttyd0 to use 115200, and finding out it's still
stuck at 9600bps because of this default limit.  I know of quite a few
people who never considered doing stty -af /dev/ttyd0 to look at the
actual speed.  This may indeed be caused by lack of experience, but once
the administrator figures out the reason for it and fixes it, the next
words out of his/her mouth are almost always "So, uhh, what's with the
9600 default?"

That said, can someone explain the justification behind the default?

4) Many administrators (myself included) continue to report that serial
console "works great" in one stage, but not in others.  I've seen it
many times myself; serial output during boot0 and boot2/loader but
nothing once the kernel loads, or the exact opposite: total silence
until the kernel loads.

There's multiple points where FreeBSD messes with the serial port.
You've got the BIOS messing with it (on systems which support BIOS-level
serial console), boot0sio messing with it (if installed), then
boot2/loader messing with it, then the kernel messing with it.

All of these things have to be "in tune" with one another or else
administrators end up with a serial port that works up until that point.
There was even a recent -stable message about this, I believe.  There
doesn't appear to be any transparent "hand-offs" between one stage and

So my question is: why aren't we simply initialising the port speed as
soon as possible (and only if explicitly told to by an existing boot
configuration), such as in boot0 or boot2/loader, and then leaving it
alone from then on?

If you're reading this and are curious how we do our installs and
have our systems set up (all of which are Supermicro):

* Install FreeBSD locally (VGA + keyboard + CD)
  - Choose _not_ to install the FreeBSD bootloader (choice: "None")
* Finish the install; system will reboot
* After the system is up, edit /boot.config
  - Contents should be: -S115200 -P
* Edit /etc/ttys
  - Enable ttyd0
  - Change std.9600 to std.115200
  - Change term type from dialup to xterm (we assume anyone getting
    on the serial console remotely is using PuTTY or something capable
    of xterm-like emulation)
* Reboot box
* Go into BIOS
  - Enable serial port redirection to COM-A (e.g. COM1, IRQ 4, 0x3F8)
  - Serial port speed: 115200
  - Keep redirection after POST should be DISABLED
  - Save settings
* All done.  Take box to co-lo and when powering it up, make sure
  there's no keyboard attached

What this gets us is the ability to go into the BIOS remotely via
serial console, as well as manage and maintain a FreeBSD server
via serial console.  However, the installation itself still requires
it to be done via VGA+keyboard.

I'd much rather be able to install the OS remotely (telling remote
hands to put some CD in the drive and leave the rest to me), especially
because a few of our servers need to migrate from RELENG_4 to RELENG_6
(possibly RELENG_7), and I'd rather nuke them/reinstall without having
to go to the co-lo.

I'll succumb to the argument of PXE booting for initial OS installs (I
completely agree with it!), but the above items regarding serial console
still stand.  That is, unless you enjoy PXE booting blind.  :-)  Most
of the walkthrough I've seen for getting a PXE-based setup configured
are for old versions of FreeBSD (4.x or 5.x).  The guide alfred@ put
together is very useful, but seems to be intended for headless clients
and doesn't touch base on serial console configuration pieces.

| Jeremy Chadwick                                    jdc at |
| Parodius Networking                  |
| UNIX Systems Administrator                      Mountain View, CA, USA |
| Making life hard for others since 1977.                  PGP: 4BD6C0CB |

More information about the freebsd-hackers mailing list