Bug 691374

Forgot to add:
$ rpm -qa | grep systemd
systemd-units-20-1.fc15.x86_64
systemd-20-1.fc15.x86_64

There was a very similar bug before: bug 681167

What happens if you drop the "console=tty" parameter?

Yes.
Dropping the console=tty seems to solve the problem.

- Gilboa

I can reproduce this. Indeed "console=tty console=ttyS0" is necessary for the bug to happen. When "console=ttyS0" is used alone, it works fine. In case anyone wonders - passing "console=..." twice is perfectly legitimate. It tells the kernel to output its messages on both the virtual terminal and the serial console. And the last device (ttyS0 in this case) is to be used for /dev/console.

The terminal settings of /dev/ttyS0 must be locked, because "stty -F /dev/ttyS0 sane" complains: "unable to perform all requested operations"

Passing "rd_NO_PLYMOUTH" and masking plymouth-start.service using "ln -s /dev/null /etc/systemd/system/plymouth-start.service" works as a workaround.

This indicates plymouth is to blame for the broken terminal settings. Reassigning.

*** Bug 683729 has been marked as a duplicate of this bug. ***

I see this bug in a NON-VM setting.

My issue actually only occurs when I only have "console=ttyS4,115200n81".  If I use "console=tty0 console=ttyS4,115200n81" then it works.

I have a very similar problem, but concerning /dev/tty1 after upgrading to
fedora 15:
After boot (ex runlevel 3) the user password is not hidden.  And indeed
the command "stty -F /dev/tty1 sane" gives "unable to perform all requested operations".

The problem is not systematic, but shows up with (say) 50% probability
after each reboot.

Following the suggestions of Michal Schmidt above (rd_NO_PLYMOUTH and
disallowing plymouth-start.service as described) *solves* the problem.

We have a lab with approx 20 very old compaq PCs that were upgraded
subsequently with "yum upgrade" from previous fedora versions.

I'm having this same problem with RHEL 6.1 on all my servers: virtual (VMware ESXi 4.1) and physical (Dell Poweredge R510s, R610s).  I suggest updating the subject of the bug to reflect that.

$ sudo stty --file=/dev/ttyS0 -clocal
stty: /dev/ttyS0: unable to perform all requested operations

Once echo is disabled for typing my password, each of my characters turn into newlines until agetty is restarted.

cassdevb01 login: root
Password: <newline>
Login incorrect

login:  <newline>
Password:  <newline>
Login incorrect

login:  <newline>


I believe Bug 711411 is related.

I can confirm that Michal Schmidt work around seem to work just fine.
Any chance of fixing it before F16 GA?

- Gilboa

No, F16 is practically done and this is not a blocker.

*** Bug 770995 has been marked as a duplicate of this bug. ***

*** Bug 755003 has been marked as a duplicate of this bug. ***

(In reply to comment #4)

> Passing "rd_NO_PLYMOUTH" and masking plymouth-start.service using "ln -s
> /dev/null /etc/systemd/system/plymouth-start.service" works as a workaround.
> 
> This indicates plymouth is to blame for the broken terminal settings.

This work-around does allow me to successfully login via the serial console, but it has undesirable side effects, specifically the messages that would appear during boot are now completely gone with plymouth disabled.

I need console messages to appear on both tty1 and ttyS1 and I need working logins on both for hundreds of embedded systems.  Presently, I don't see how this can be achieved, with or without work-arounds.

I have zero need for any of plymouth's "features", but could live with it if it didn't present such issues.  I'd attempt my builds without installing plymouth, but dracut has a dependency on it and my builds do require dracut.

Any advice on how to meet my needs would be greatly appreciated.

(In reply to comment #14)
> I need console messages to appear on both tty1 and ttyS1 and I need working
> logins on both for hundreds of embedded systems.  Presently, I don't see how
> this can be achieved, with or without work-arounds.

+1, same needs for me on kvm virtual machines and servers with serial remote console.

> I have zero need for any of plymouth's "features", but could live with it if it
> didn't present such issues.  I'd attempt my builds without installing plymouth,
> but dracut has a dependency on it and my builds do require dracut.

One thing, which I think plymouth goes is, that it has better logging into /var/log/boot.log, which works well with plymouth.
But for me it's only secondary feature, primarily I need serial boot console and login.

(In reply to comment #15)

> One thing, which I think plymouth goes is, that it has better logging into
> /var/log/boot.log, which works well with plymouth.
> But for me it's only secondary feature, primarily I need serial boot console
> and login.

Yes boot.log is useful ... if the system gets that far.  I'm hesitant to deploy systems that cannot show their boot progress because if any get stuck prior to login/ssh startup, I'll have zero clues from which to debug.  Serial console access is my last resort when bad luck visits and it's hard to choose between boot messages and login.

In the past few Fedora releases (for this problem has been around since at least F13), my work-around was to have a local, non-root account with a single character password from which I could then su.  Horribly insecure, but it's the most workable solution I've yet found.  With that setup, you must get the user name correct on the first try and press the key corresponding to your password.  You won't need to press Enter on the password.  Term IO is funky thereafter, but sufficient in a pinch.  If you botch the id or password, you need a new agetty instance, so press Enter a few times until the login reappears at the *top* of the screen. (This matches what's described by Jason in comment 9.)

(In reply to comment #14)
> the messages that would appear during boot are now completely gone with
> plymouth disabled.

What messages are you talking about exactly?
I get the kernel's boot messages and systemd messages on both the serial console and the VGA console here with plymouth disabled.
Are you passing the "quiet" option?

(In reply to comment #17)

> What messages are you talking about exactly?

The usual messages from each service (e.g., SSH) as they're started up.  I suspect it would be everything handled by the systemd-stdout-syslog-bridge process, but that's just a guess.  Let's just call them the init messages as opposed to the kernel messages.

> Are you passing the "quiet" option?

Yes, because it's forced on all images produced by livecd-tools.  I can tell livecd-tools to append more options, but a few like "quiet" are there by default.  The last time I investigated that behavior, there was nothing that could be done about it short of hacking up python-imgcreate.  If I boot one of these images and manually remove "quiet" ala grub's editor, I do get the expect messages on both consoles although /var/log/boot.log is nearly empty having only "NET[850]: /sbin/dhclient-script : updated /etc/resolv.conf".

Is this going to get attention ?

FWIW I have a 32bit FC15 and a 64bit FC15 (both upgrades from about FC12).

It only happens on the 64bit instance.

I have removed plymouth and dracut as I have no need for them.

This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Note for others coming over here after a google search like me :)

It seems that this bug is fixed in F-18 (don't know about F-16 / F-17), as long as the console=ttyS0,... is the last console= on the kernel cmdline, iow the serial console is the default console, then systemd will automatically start a serial getty on it.

(In reply to comment #21)

> It seems that this bug is fixed in F-18 (don't know about F-16 / F-17), as
> long as the console=ttyS0,... is the last console= on the kernel cmdline,
> iow the serial console is the default console, then systemd will
> automatically start a serial getty on it.

That matches my observation as well.  In my F18 tests, I have "console=ttyS1,115200 console=tty0" on the kernel cmdline and both of these consoles work very well now for both kernel messages and logins.  I no longer need any of the silly kludges -- it just works as it should.

The last time I tried with F16, it was still broken though and I don't know at all how well F17 works in this regard.