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): systemd-18-1.fc16.i686 How reproducible: Everytime 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 ie: """ blood.lan login: badger badger Password: Fake_password_echoed_to_console:-( Last login: Wed Feb 16 """ Expected results: Password no echoing of keystrokes: """ blood.lan login: badger Password: Last login: Wed Feb 16 """ Additional info: I was testing that the new systemd package fixes this: https://bugzilla.redhat.com/show_bug.cgi?id=661559 I suspect that something related to that fix is causing this bug.
*** This bug has been marked as a duplicate of bug 655538 ***
Reopening and leaving assigned to systemd due to latest comment on bug 655538 Update from that bug: plymouth-0.8.4-0.20110419.1.fc16.i686 systemd-18-1.fc16.i686 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.
Booting into 3 with or without rhgb quiet does not reproduce this issue for me... So unconfirmed..
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
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.
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
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.
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.
-1 to Alpha blocker. +1 for documenting on Common_F15_Bug and addressing this post-Alpha.
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.
-1 to alpha blocker +1 for documenting on Common_F15_Bug for alpha.
Adding RejectedBlocker to remove this from the proposed blocker list.
Sandro: nope, no encryption. I think we were both testing inside qemu/kvm (virt-manager, for me), though. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
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: https://admin.fedoraproject.org/updates/systemd-19-1.fc15 then log in and leave karma (feedback).
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
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 systemd-19-1.fc15.i686 plymouth-0.8.4-0.20110419.1.fc16.i686
Let's continue this discussion in 681167 *** This bug has been marked as a duplicate of bug 681167 ***
drop commonbugs keyword.
systemd-20-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/systemd-20-1.fc15
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.