Bug 676885
| Summary: | bad handling of multiple console= options on kernel command line | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jeff Layton <jlayton> |
| Component: | systemd | Assignee: | Lennart Poettering <lpoetter> |
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | lpoetter, metherid, mschmidt, notting, plautrba, steved |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-02-14 18:58:36 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Note that prior behavior has been to only set up the primary console as a getty. 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... Jeff, what's the contents of /sys/class/tty/console/active when systemd picks the wrong tty? 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. OK, fixed this now in systemd git. Upload to Rawhide fill follow soon. Please retest then and reopen if necessary. |
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.