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.
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.
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.
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.
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.
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. :-)
(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').
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!
I just had an insight: event-driven systems are like programs with 'goto' statements: they're both really hard to debug.
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.
(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.
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!