Bug 676885 - bad handling of multiple console= options on kernel command line
Summary: bad handling of multiple console= options on kernel command line
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-11 17:20 UTC by Jeff Layton
Modified: 2014-06-18 07:40 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-02-14 18:58:36 UTC
Type: ---


Attachments (Terms of Use)

Description Jeff Layton 2011-02-11 17:20:35 UTC
The file Documentation/serial-console.txt in the kernel sources says:


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, for example:

        console=ttyS1,9600 console=tty0

defines that opening /dev/console will get you the current foreground
virtual console, and kernel messages will appear on both the VGA
console and the 2nd serial port (ttyS1 or COM2) at 9600 baud.

...but systemd doesn't seem to handle this syntax correctly. When I do similar syntax to this, e.g.:

    console=ttyS0,115200 console=tty0

...I get no getty on the serial line.

Comment 1 Bill Nottingham 2011-02-11 17:25:09 UTC
Note that prior behavior has been to only set up the primary console as a getty.

Comment 2 Jeff Layton 2011-02-11 20:26:43 UTC
I don't think that was the case, was it? It seems like in the past, I've used a similar command line to the one above and still got a getty on ttyS0. Unfortunately, those machines have been rebuilt since then so I can't confirm it.

Either way though, it seems like systemd is still doing the wrong thing. With the above command line, I get characters that I type double-echoed back on the main VC. When I remove "console=tty0", it behaves correctly. It seems like systemd is treating any console= option as a serial console, even if it has already had a getty started on it.

The ideal behavior (IMO) would be to have systemd scan the command line and start gettys on any serial console listed. I'm not 100% clear on how best to distinguish serial consoles from others however...

Comment 3 Lennart Poettering 2011-02-14 17:47:13 UTC
Jeff, what's the contents of /sys/class/tty/console/active when systemd picks the wrong tty?

Comment 4 Lennart Poettering 2011-02-14 18:04:28 UTC
systemd git will now make sure never to spawn extra getty's on VCs if console=ttyN is used. gettys on VCs should be configured only via configuration in the file system. This should semi-fix the bug.

The other half of the bug I see here is that systemd currently spawns a getty on the first console= tty listed on the cmdline, but you seem to suggest it should be the last? What does /sys/class/tty/console/active contain for you?

We discussed a couple of times whether we should spawn gettys on all configured console= ttys, but decided against it since just having kmsg output go on a tty is substantially less than actually providing a pointer to it via /dev/console. We rather do too little than too much, since this is a tiny bit security sensitive. Or to turn this around: if somebody configures such complex setups it probably makes sense to leave the getty configuration to him too and just do the minimal work automatically that is necessary to allow him to log in.

Comment 5 Lennart Poettering 2011-02-14 18:58:36 UTC
OK, fixed this now in systemd git. Upload to Rawhide fill follow soon. Please retest then and reopen if necessary.


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