This bug may be related to "login" or "agetty" but I am not quite sure about that. But since it is so fatal I need to report it somewhere. I ran into this bug yesterday and after rebooting my system twice I got it again today. On a second machine (nearly identical configuration) I run into this bug since about 28th of december 2013. I am running F20 with all updates from "updates" and "updates-testing" repositories installed. By default X/Gdm/Gnome-Shell is running on tty1, all other ttys have a non-X (text) login. What happens: 1. When switching to tty2 (or up) the mouse cursor stays visible most times (90%?). When I move the mouse (hardware) the cursor moves too as you would expect it tty1/X. 2. when switching back to tty1/X I still get the display from tty2 but freezed. Mouse cursor still visible and moves as expected. 3. When in 1. or 2. pressing some keys brings X back. This always works for the "print screen" key, Alt+Tab, Alt+(key above Tab), Alt+F4, Alt+F10 and some others. Some other events (keys, mouse movement, interrupts, …) may also bring X11 back but I haven't found a reliable way to reproduce this. 4. Sometimes all keyboard input goes to both X and tty2 (keyboard input is duplicated). It does not matter whether tty2 or tty1/X is active. Effects: 2. is rendering X completely unusable 3. is rendering tty completely unusable 4. is a security risk. This is some kind of super-keylogging: Provided I am logged in as "normal" user on tty1/X and am logging in on tty2 as root all X applications can read my root password. When tty1/X is active, everything I type may be executed as root. package versions: util-linux-2.24-2.fc20.x86_64 gdm-3.10.0.1-1.fc20 systemd-208-9.fc20 kernel-3.12.7-300.fc20.x86_64 (this also happened with older kernels) anaconda-20.25.16-1.fc20 dracut-034-64.git20131205.fc20.1
Created attachment 851581 [details] Output of $ journalctl | grep "chstpc-2 dracut" In the attached log file the first initramfs (kernel 3.12.6-300, created on 2014-01-03) does not show the described bug. The second initramfs (kernel 3.12.7-300, created on 2014-01-16) shows this bug.
Seems more like a bug in GDM (or gnome-shell) to me. Switched to awesome (not using any DM, startx) about 1 month ago and never saw this problem again.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is 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 change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
I have seen this in F21, not in F22. Since this bug is so critical someone should look over it before closing.
Can this perhaps be dependent on the graphics card driver in use? Which driver or graphics card did you experience this on? I never saw the mouse cursor enabled when going to a text console, on F20 and previous under Gnome/GDM, and on F21 under KDE/SDDM. I also never saw this buggy situation where X and the text console would both get kbd/mouse events. Unfortunately I have always used Intel integrated graphics controllers, so I can't comment on other drivers.
I don't know whether this depends on GPU drivers. I saw this on 2 devices with i915 graphics driver on Core i5 processors (1st and 2nd generation) with iGPU. I used Gnome/GDM and disabled (uninstalled) plymouth.
Removing Security keyword and group, as this requires local console access and does not look like a real security flaw in the software involved. So far I have not found a single person that could ever reproduce this behavior.
GDM didn't muck with the tty in f21 (though it does in f22), so it's unlikely to be culpable. moving to Xorg. Realistically, with no reproducer and only one reporter, (who no longer sees the problem), it's unlikely traction can be made on this bug. For that reason, I'm going to close the bug CANTFIX.