getty should be started automatically on serial port when serial console is set on kernel command line

Bug #702574 reported by Clint Byrum
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
upstart (Ubuntu)
Fix Committed
Wishlist
James Hunt

Bug Description

Binary package hint: upstart

If a user passes console=ttySXXX on the kernel commandline to get a serial console, they will see the boot happen on the serial port, but not be given a chance to login on the serial port.

We should ship an upstart job that starts a getty on the serial console in this case.

Related branches

Changed in upstart (Ubuntu):
importance: Undecided → Wishlist
Revision history for this message
James Hunt (jamesodhunt) wrote :

Due to the complexities of parsing the console= kernel param, as Clint suggested, we could just let the kernel+getty auto-detect speed.

We could therefore create a /etc/init/ttyUSB0.conf (or similar) containing:

  exec /sbin/getty -m -8 115200,57600,38400,19200,9600,4800,2400,1200 ttyUSB0

By specifying all possible/reasonable(?) baud rates as above, no complex param parsing is required for "console=": we only need to extract the device name itself.

Tested on natty booting with "console=ttyUSB0,115200n8r console=tty" after removing "quiet" and "splash".

Getty was spawned and I could login, but my client end needs some "minicom lovin'" since I was getting control chars being echoed in minicom.

Revision history for this message
James Hunt (jamesodhunt) wrote :

Comment #1 was incorrect in that I was actually using ckermit, not minicom.

Revision history for this message
Oliver Grawert (ogra) wrote :

how do we get the device name for the serial port without parsing the console= arg ?
please have a look at /etc/securetty (and there are lots more that arent in this file) to see how many variations we can have. ttyUSB0 is usually the other end of the line if you use a usb->serial converter, not the tty you start the getty on.

Revision history for this message
James Hunt (jamesodhunt) wrote :

Hi Oliver,

You are right - my comment #1 does state that we still need to extract the device name, but we can potentially dispense with the complexities of handling parity, speed, stop bits, etc.

Just to explain my setup: I have a "USB <-> serial <-> USB" serial cable, hence I have ttyUSB0 on both ends! :-)

Revision history for this message
Oliver Grawert (ogra) wrote :

ok, as long as we have dynamic device names the suggestion sounds great :)

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in upstart (Ubuntu):
status: New → Confirmed
James Hunt (jamesodhunt)
Changed in upstart (Ubuntu):
assignee: nobody → James Hunt (jamesodhunt)
status: Confirmed → In Progress
Revision history for this message
James Hunt (jamesodhunt) wrote :

I've reworked Clint+Olivers job such that it *should* now handle all possible 'console=' values.

Currently, it will start a getty for the *first* valid 'console=' value on the kernel command line once the FS is writeable (required for getty to update utmp records). We could make this more flexible (and complex) by adding tty-device-added and instance to allow multiple serial consoles, but this is (probably?) overkill.

Revision history for this message
James Hunt (jamesodhunt) wrote :

Fixed tty-serial.conf to be installed in /etc/init/.

Previous version forgot to re-instate IFS, causing getty to fail to parse arguments.

Revision history for this message
James Hunt (jamesodhunt) wrote :

Ogra/Clint - the attached job only starts a single getty. A coupe of questions...

1) Is there any value in allowing multiple devices? I've already got a modified version of the job to handle that using instances (planned for tty2-4 if for nothing else).

2) The job takes the *first* 'valid' console= argument. According to the kernel docs...

        You can specify multiple console= options on the kernel command line.
        Output will appear on all of them. The last device will be used when
        you open /dev/console.

    So, maybe we should follow that convention and change the job to use the last specified console= device?

Revision history for this message
Oliver Grawert (ogra) wrote :

the attached job works fine in all environments i have tested it, but 2 would be very necessary on devices like the nexus7 where the bootloader prefixes the kernel commandline with its own args ... (on nexus7 there is an empty "console=" with no content the bootloader puts in place, so our console=ttyFooBar would always be the last one...)

1 is not critical imho

James Hunt (jamesodhunt)
Changed in upstart (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
James Hunt (jamesodhunt) wrote :

All that remains before this can land is to ensure tty-serial doesn't get entangled with the Upstart getty jobs created by the installer.

Revision history for this message
James Hunt (jamesodhunt) wrote :

= Issue =

If the install was performed specifying "console=", then the installer would have attempted to create a suitable Upstart job for that device.

= Installer File =

The file to consider is:

    http://bazaar.launchpad.net/~ubuntu-installer/finish-install/master/view/head:/finish-install.d/90console

= Plan =

(Suggested by Colin some time ago):

1) Go through finish-install.d/90console and make sure that all the special cases and things that it handles will also be handled (not necessarily in the same way) by the new tty-serial.conf.

2) Make sure that any old installer-created jobs are removed on upgrade to the first version of Upstart that ships tty-serial.conf.

3) Remove the Upstart serial console handling code from finish-install.

4) Synchronise uploads of upstart and finish-install to minimise the chance of confusion.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.