Description of problem: This is *NOT* Fast User Switching. After logging out and logging in again with still only one Xorg instance running, it launches the second time on tty7, whereas it had started on tty1 on a fresh boot on rawhide. This might well be a gdm issue but I need to file it somewhere. This also seems to happen on F14 and possibly earlier releases as well. Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.9.0-9.fc15.x86_64 gdm-2.31.90-1.fc15.x86_64 systemd-9-3.fc15.x86_64 How reproducible: 100% Steps to Reproduce: 1. Boot system into latest rawhide 2. Login to the system 3. Session is on tty1 4. Logout of session 5. Login to new session 6. Session is on tty7 Actual results: The Xorg session is started on tty1 the first time, then on tt7. Expected results: The Xorg session is always started on the same tty. Additional info:
Yes, I dimly remember flamewar on this theme around the time X on TTY1 were introduced. Pushing to gdm, but I think it could be plymouth as well.
It's also perhaps one of the reasons why switching users a few times on F13 ultimately results in a blank screen (the wrong VT) which really confuses people, but I don't want to really get into FUS here. This is just a bug in consistency.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
I've been struggling with this bug ever since tty7 was moved to tty1. This bug is in the regular F15 and F16 releases (upgraded from F13). The first user log-in goes to tty1 The second goes to tty7 the third goes to tty8 These can all be switched to directly using Ctrl-Alt-[n]. If at any time the user on tty1 logs out, tty1 is not used again. Changing to tty1 with Ctrl-Alt-1 shows the startup sequence, but the login screen is not operating. Characters can be typed and erased, but nothing is responded to otherwise. Ctrl-Alt-bs is ignored. It looks like the transition to using tty1 instead of tty7 was never successfully completed. It's quite disconcerting to be in tty2 or tty3, issue a Ctrl-Alt-1, and arrive at a non-responsive screen. Back in rh9 we could go to tty4 and start X. We would be taken to tty7, and doing ctrl-alt-f4 would take us to the job, which we could kill with Ctrl-C (if the x-window hung up). In f15-16 tty1 looks like that screen, but is unresponsive. It seems like somewhere the system is not keeping track of the availability of tty1 for the X-window display.
This was done with a clean boot First run the command "ps xo user,pid,tty,args" from root on tty2 and save the output to file "beforelogin" Second go to tty1 and login to my user. Third log out of my user Fourth go to tty2 and run the above command again and save the output to file "afterlogout" Fifth compare the results, getting rid of non root lines, "root" and my own jobs and see the results [root@fedora ~]# diff -bBw beforelogin afterlogout | grep root | sed 's/\s*root\s* / /'| grep -v tty2 | sort -k3 # pid change only < 1438 ? gdm-session-worker [pam/gdm-password] > 2204 ? gdm-session-worker [pam/gdm-password] # pid change only < 1269 ? gdm-session-worker [pam/gdm-welcome] > 2147 ? gdm-session-worker [pam/gdm-welcome] # Here's the change from tty1 to tty7 < 1164 tty1 /usr/bin/Xorg :0 -background none -verbose -auth /var/run/gdm/auth-for-gdm-iDmuMN/database -nolisten tcp vt1 > 2127 tty7 /usr/bin/Xorg :0 -br -verbose -logverbose 7 -auth /var/run/gdm/auth-for-gdm-wGwyKw/database -nolisten tcp # unrelated jobs > 1632 ? udisks-daemon: not polling any devices > 2207 ? /usr/libexec/fprintd # pid change only < 1118 ? /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1 > 2125 ? /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1 # more unrelated jobs > 1625 ? /usr/libexec/packagekitd > 1631 ? /usr/libexec/udisks-daemon --no-debug Start again with another clean boot. This time we log into the main user prior to running the ps job same as above [root@fedora ~]# diff -bBw beforewithlogin afterwithlogin | grep root | sed 's/\s*root\s* / /'| grep -v tty2 | sort -k3 After eliminting unrelated jobs and jobs that were finished after the first logout, we're left with < 1164 tty1 /usr/bin/Xorg :0 -background none -verbose -auth /var/run/gdm/auth-for-gdm-iDmuMN/database -nolisten tcp vt1 > 2127 tty7 /usr/bin/Xorg :0 -br -verbose -logverbose 7 -auth /var/run/gdm/auth-for-gdm-wGwyKw/database -nolisten tcp I opened a second user and logged out the first user. The second user went into tty8, tty7 was vacant. Then I logged in a third user. That user went into tty7. So the system for keeping track of which tty's are available for re-use apparently does not rember the use status of tty1. Just for drill, I entered ctrl-alt-f9, and I got the switch-user screen. After relogging the first user back in (three x-window users logged in) I could ctrl-alt-fn from one to another with no authentication checks stopping me, so this should get a priority up for security sake.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. 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 19 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 checked for this bug in Fedora 20 (x86-64). It is fixed there. TTY's are used in order from 1 up and are reused properly. TTY1 is reused properly. You can close this as fixed in version 20. Thanks!!!
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.