Bug 475033 - Setting up a non-virtual headless server with serial console is difficult
Setting up a non-virtual headless server with serial console is difficult
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-06 15:39 EST by Penelope Fudd
Modified: 2014-03-16 23:16 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-08 13:50:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Penelope Fudd 2008-12-06 15:39:29 EST
Description of problem:
I installed Fedora 10 on a desktop computer, then moved the hard drive to 1U rack mounted computer with no monitor, keyboard or mouse.  Getting serial port console to work was undocumented and difficult.

Step 1: edit /boot/grub/grub.conf:

  Change 'timeout=0' to 'timeout=10'
  Add 'serial --speed=9600'
  Add 'terminal --timeout=10 serial console'
  Append 'console=ttyS0,9600 console=tty0' to 'kernel' line of an entry

Step 2: edit /etc/event.d/serial:

  The 'fedora.serial-console-available' event never gets sent, so comment out everything, and add this:
  # ttyS0 - getty
  #
  # This service maintains a getty on ttyS0 from the point the system is
  # started until it is shut down again.
  start on stopped rc2
  start on stopped rc3
  start on stopped rc4
  stop on runlevel 0
  stop on runlevel 1
  stop on runlevel 6
  respawn
  exec /sbin/agetty ttyS0 9600 vt100-nav

Version-Release number of selected component (if applicable):
initscripts-8.86-1.i386

How reproducible:
Sample size of 1: 100%.

Steps to Reproduce:
1. Install fedoara 10
2. Try to make serial-console work
3.
  
Actual results:
Difficult

Expected results:
Easy

Additional info:
Getting the ethernet cards working is no picnic either; /etc/sysconfig/network-scripts is no longer the only place where ethernet cards are configured.  Maybe insert a comment into ifcfg-eth0 that says where they *are* configured?  I've got eth0-rename instead of eth0, and I can't change it with vi or with NetworkManager.  Fooey.
Comment 1 Penelope Fudd 2008-12-07 01:02:16 EST
The eth0-rename problem was fixed by deleting and renaming ethernet entries in /etc/udev/rules.d/70-persistent-net.rules, as the desktop ethernet cards were in there and causing a problem.

An additional problem was found and fixed in /etc/sysconfig/iptables, as the network interfaces had to be renamed back to eth0 and eth1.
Comment 2 Bill Nottingham 2008-12-08 10:40:41 EST
If you want serial console to automatically work, make it the primary console (list it last in your console= line). This is in line with the previous behavior for automatically setting up a serial console getty on boot.
Comment 3 Penelope Fudd 2008-12-08 13:36:25 EST
Thanks!

I find myself flying without documentation most of the time; do you have a pointer to where I could have found this on my own?  I'm hoping that there's more gold in that thar' mine.
Comment 4 Bill Nottingham 2008-12-08 13:50:30 EST
Not really - it's the way it was before too, so I'm not sure it was ever really documented. 

What's just changed is the mechanism - it used to be that in that case kudzu would write a line in /etc/inittab; now we emit an event from udev that causes the getty to be started by upstart. If the console entries *aren't* in that order, then you need to manually create an upstart event to start the getty, much like you'd have to manually edit /etc/inittab before.

Closing this, as it's working as it's coded.
Comment 5 Penelope Fudd 2008-12-08 14:22:15 EST
How do you manually create an upstart event?  Where do you put it?  And why should the code care if the console entry is first or not?  It's still a console.  This isn't clearly documented; posting a bug in bugzilla is the only way to find out this stuff.  This bug report may be the best documentation there is.

(I love that expression "it's working as it's coded": even when code has a bug it's working as it's coded.  Compiler errors are the only violation of this assert() statement.  :-)
Comment 6 Bill Nottingham 2008-12-08 16:40:25 EST
(In reply to comment #5)
> How do you manually create an upstart event? Where do you put it?

Create a file in /etc/events.d (for now). Cribbing from /etc/event.d/tty1 is your best bet. 

> And why should the code care if the console entry is first or not?

The only way to determine if you've booted a serial console is to open /dev/console and ask it if it's a serial port (TIOCGSERIAL ioctl). If it's
the last console entry, it says yes. If it's not, it doesn't. Until there's a better interface from the kernel, there's not much we can do.

> This isn't clearly documented;

'man 5 events' has information on upstart event format. There's a large
blurb at the top of the included /etc/inittab as well. It may not be the
most clear, but I'm not sure that it's *that* much worse than the prior documentation (just 'man 5 inittab').
Comment 7 Penelope Fudd 2008-12-08 17:36:28 EST
Can we not just examine /proc/cmdline to see if console=ttyS0 is there?

What I meant to say is: the serial console isn't clearly documented.  I found /etc/event.d/serial, but there's no way to find out where that event is supposed to be generated.  If you Google "fedora.serial-console-available" (with quotes), you get a single page of frustrated people working around that /etc/event.d/serial script, typically by overwriting it.

Maybe some comments in /etc/event.d/serial would be helpful?  Mention that 'console=ttyS0' needs to be last on the kernel command line, and that /usr/bin/flurbelizer emits fedora.serial-console-available if /dev/console acts like a serial console, and that the binary is started by udev.  We could mention what needs to be added to /boot/grub/grub.conf to make it all happen.

I really don't know where else to put or find documentation like this.

Thanks!
Comment 8 Penelope Fudd 2008-12-08 17:48:40 EST
I just had an insight: event-driven systems are like programs with 'goto' statements: they're both really hard to debug.
Comment 9 Penelope Fudd 2008-12-08 19:14:28 EST
It looks like serial-console.txt in the kernel documentation is the place to document this.  The file contains good information, but is beginning to be quite dated (last change June 11 2000); it may be time to rewrite it and send the changes upstream.
Comment 10 Bill Nottingham 2008-12-09 10:46:50 EST
(In reply to comment #7)
> Can we not just examine /proc/cmdline to see if console=ttyS0 is there?

Not reliably, because there are platforms where the default console is serial, or serial-like. 

> 
> What I meant to say is: the serial console isn't clearly documented.  I found
> /etc/event.d/serial, but there's no way to find out where that event is
> supposed to be generated.  If you Google "fedora.serial-console-available"
> (with quotes), you get a single page of frustrated people working around that
> /etc/event.d/serial script, typically by overwriting it.
> 
> Maybe some comments in /etc/event.d/serial would be helpful?

http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=756ab997fc3c149c0894d756df25b590482aa082

The prolem with putting it in serial-console.txt is that, at some level, this is distribution-specific configuration that isn't appropriate for the 'general' upstream kernel documentation.
Comment 11 Penelope Fudd 2008-12-09 13:02:44 EST
Thank you for the patch!

I was confused by "It waits for the runlevel to finish, checks to
make sure the proper port is in /etc/securetty, and starts the getty."  /sbin/securetty *adds* the terminal to /etc/securetty if not present; from reading this I thought it refused to start the getty if the terminal was not in /etc/securetty.

As for serial-console.txt, if it was appropriate to mention /etc/inittab configuration, then it's appropriate to mention /etc/event.d configuration.

Thanks again!

Note You need to log in before you can comment on or make changes to this bug.