Bug 678720 - systemd echoes keystrokes to the screen
Summary: systemd echoes keystrokes to the screen
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
Whiteboard: RejectedBlocker
Depends On:
Blocks: F15Alpha, F15AlphaBlocker
TreeView+ depends on / blocked
Reported: 2011-02-19 00:35 UTC by Toshio Ernie Kuratomi
Modified: 2011-03-12 04:42 UTC (History)
11 users (show)

Fixed In Version: systemd-20-1.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-03-02 12:46:38 UTC

Attachments (Terms of Use)

Description Toshio Ernie Kuratomi 2011-02-19 00:35:27 UTC
Description of problem:

systemd can echo keystrokes to the console in some cases.  This causes extraneous output there and also things like your password to be shown.

If you set systemd to boot multiuser, nongraphical and grub is set to use rhgb quiet and you then hit 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Set systemd to boot multiuser, nongraphical
2. Set grub to boot rhgb quiet
3. Reboot system
4. While booting, hit [ESC] so that systemd/plymouth display the messages being output while booting
5. Once you get a getty, type your username and hit return
6. Unless you're in a secure location, do not type your password :-)
Actual results:
Username is echoed to the console before printing the Password prompt

blood.lan login: badger
Password: Fake_password_echoed_to_console:-(

Last login: Wed Feb 16

Expected results:
Password no echoing of keystrokes:

blood.lan login: badger

Last login: Wed Feb 16

Additional info:
I was testing that the new systemd package fixes this:

I suspect that something related to that fix is causing this bug.

Comment 1 Lennart Poettering 2011-02-19 13:30:29 UTC

*** This bug has been marked as a duplicate of bug 655538 ***

Comment 2 Toshio Ernie Kuratomi 2011-02-23 22:43:26 UTC
Reopening and leaving assigned to systemd due to latest comment on bug 655538

Update from that bug:

I'm still seeing the reported problem.  I'm also seeing other terminal problems that may be related to raw vs cooked mode.  Arrow keys don't work in the shell.  vim is unusable because keystrokes are echoed to the top line in the screen instead of affecting the buffer.  Control-L does not redraw the screen.  Etc.  This does not seem to be related to hitting the ESC key during bootup as I originally thought -- the symptoms occur even when the ESC key is not hit.  However, it does seem to be a race as every once in a while (maybe one in 10 boots) the system comes up with the terminal behaving as expected.

Let me know when there's a package I should install and retest.

Comment 3 Jóhann B. Guðmundsson 2011-02-25 17:29:04 UTC
Booting into 3 with or without rhgb quiet does not reproduce this issue for me...

So unconfirmed..

Comment 4 Bruno Wolff III 2011-02-25 17:31:39 UTC
From blocker meeting:
678720 is worrying but needs more data: we need to know the root cause and need to test if it affects other installs. blocker status undetermined until more data available

Comment 5 Adam Williamson 2011-02-25 20:51:12 UTC
Okay, I tested this together with Toshio.

So, here's the ins and outs. This happens when you manage to get boot messages displayed. There's a few ways to achieve this.

You can boot and hit 'esc' during boot, but *only* if you have the 'fixed' systemd - systemd-18-1 . This systemd is not in the Alpha at present. You can get this systemd, though, if you install Alpha and enable the updates-testing repo, and that's the *default* configuration for a net install (which I think may be a bug too).

You can also hit this with any version of systemd by booting with 'rhgb quiet' parameters removed. That will cause you to get system messages spewed to console, and hit this bug if you try to log in at the console.

So, to review - you don't hit this at all if you don't interact with boot at all. You hit it just by pressing 'esc' during boot if you have the updated systemd. You hit it by dropping 'rhgb quiet' from boot parameters with any systemd.

We can avoid the 'esc' case without changing the Alpha spin by un-pushing the 'fixed' systemd until we have a fix for this issue. We can't avoid the 'drop rhgb quiet' case without a properly-fixed systemd.

So, with that impact statement in mind, we need votes on blocker-iness. I'm a weak -1 blocker, if we document this carefully.

Comment 6 Dennis Gilmore 2011-02-25 20:58:02 UTC
im -1 blocker, its going to effect a small amount of users, I do think we need to document it and that it should be fixed by beta

Comment 7 Adam Williamson 2011-02-25 21:13:05 UTC
i also think we should un-push systemd-18 to reduce the chances of people hitting it on updates or install with updates-testing enabled. toshio says he can actually hit this without any interaction with systemd-18.

Comment 8 Adam Williamson 2011-02-25 22:27:55 UTC
dgilmore: if no-one else votes on blocker-iness, you can call this notablocker prior to spinning on the basis of our votes, I think.

Comment 9 James Laska 2011-02-28 13:18:59 UTC
-1 to Alpha blocker.  +1 for documenting on Common_F15_Bug and addressing this post-Alpha.

Comment 10 Sandro Mathys 2011-02-28 15:36:34 UTC
I can't reproduce this with systemd-18-1 (i.e. RC2 installation + complete update to latest from updates-testing), neither by pressing "esc" nor by removing "rhgb quiet".

I see there's a duplicate bug where this happens with luks encryption - when you guys reproduced this, were your disks encrypted? I haven't tried that.

Comment 11 Jóhann B. Guðmundsson 2011-02-28 16:12:56 UTC
-1 to alpha blocker +1 for documenting on Common_F15_Bug for alpha.

Comment 12 James Laska 2011-02-28 16:13:48 UTC
Adding RejectedBlocker to remove this from the proposed blocker list.

Comment 13 Adam Williamson 2011-02-28 16:16:20 UTC
Sandro: nope, no encryption.

I think we were both testing inside qemu/kvm (virt-manager, for me), though.

Fedora Bugzappers volunteer triage team

Comment 14 Fedora Update System 2011-03-01 01:37:24 UTC
Package systemd-19-1.fc15:
* should fix your issue,
* was pushed to the Fedora 15 updates-testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-19-1.fc15'
as soon as you are able to, then reboot.
Please go to the following url:
then log in and leave karma (feedback).

Comment 15 Fedora Update System 2011-03-01 06:49:00 UTC
systemd-19-1.fc15 has been pushed to the Fedora 15 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update systemd'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-19-1.fc15

Comment 16 Toshio Ernie Kuratomi 2011-03-01 20:37:24 UTC
Problem is still present.  systemd-19 manually installed from koji.  (Rawhide VM).  Tested booting without "rhgb quiet" on the kernel commandline.

rpm -q systemd plymouth

Comment 17 Lennart Poettering 2011-03-02 12:46:38 UTC
Let's continue this discussion in 681167

*** This bug has been marked as a duplicate of bug 681167 ***

Comment 18 Adam Williamson 2011-03-07 20:38:52 UTC
drop commonbugs keyword.

Comment 19 Fedora Update System 2011-03-08 19:36:38 UTC
systemd-20-1.fc15 has been submitted as an update for Fedora 15.

Comment 20 Fedora Update System 2011-03-12 04:42:25 UTC
systemd-20-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

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