Red Hat Bugzilla – Bug 504574
gdm respawns in tty7 after a "init1 init5"
Last modified: 2015-01-14 18:23:07 EST
Description of problem: gdm respawns in tty7 instead of tty1 after setting init mode to 1, then to 5 back Version-Release number of selected component (if applicable): gdm-2.24.1-4.fc10.i386 I don't really know wether it's init- or gdm-related How reproducible: always Steps to Reproduce: 1.boot. once in GDM, type CTRL+ALT+F2 2.log in as root, type "init 1", then "init 5" to switch back to graphical mode 3.type CTRL+ALT+F1 : nothing !!! then type CTRL+ALT+F7 : gdm is there Actual results: gdm respawned in tty7 Expected results: gdm respaws in tty1, as it runs there at boot time... it shouldn't move ! Additional info: annoying bug since tty1 becomes unusable.
Thank you for the bug report. Additional info: This problem is reproducible on F11 and F12 rawhide as well. F11: gdm-2.26.1-13.fc11.x86_64 F12: gdm-2.27.90-2.fc12.x86_64 --- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 361546 [details] /var/log/messages Here is the system log for gdm-2.27.90-2.fc12.x86_64 from 'init 3' to 'init 5'.
I guess gdm fails to start on tty1 because 'init 3' starts mingetty there
*** Bug 469042 has been marked as a duplicate of this bug. ***
After last updates, still problem persists?
Just tested on F12 Rawhide. During the boot GDM was started on tty7 and remained there after 'init 3 && init 5'. Great! But tty1 seems to be unused until 'init 3'. It shows only text cursor after boot. Why don't we just run mingetty there in 5th runlevel too?
Problem still persists in F11 : * Fedora boots and gdm runs on tty1. After a init 3 -> init 5 gdm respawns in tty7, but tty1 becomes usable, a shell is launched. I think it would be simpler to let gdm always run in tty1 not to confuse the user and to avoid any other problem this might cause. another solution would be to always run gdm in tty7 but this move was intentional, if I remember well : it was for the flicker-free boot (from POST to GDM without any interruption) Tell us about the advance on this problem... and if you need any other info (log, config file, version number) Thanks in advance.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 528867 has been marked as a duplicate of this bug. ***
I've been meaning to take a minute to comment on Bug 528867 being marked as a duplicate. I'm okay with it because this bug and 528867 are definitely related, but a little bummed that my comments and debugging efforts are not as visible as they once were. Que Sera Sera. Previously I was not aware that tty's were shifting as a result of switching init modes. This bug was noticed by me during the simple act of logging out from the desktop and logging back in. It happens in both F11 and F12, but not F10. This switching is quite annoying since the tty's and X do not remain in the same location. I was blaming gdm more than the init scripts since it does not handle ensuring that Xorg starts on the same tty at all times. While Xorg has the capability to pass the VT number as an argument during start up, as far as I can tell gdm does not have that ability as either a configuration option or argument. Looking into this problem further I think it can be resolved without a great deal of coding by adjusting the upstart jobs and startup sequence within /etc/event.d. If I understand upstart correctly, it is starting jobs by going through the /etc/event.d directory alphabetically. I have no idea if this is true because the documentation is somewhat limited. However, since prefdm is before tty[1-6] in the alphabet it gets started first and Xorg gets tty1 on initial boot. I'm thinking if we start it after the tty's it would go back to tty7 and stay there, just like the majority of Linux distributions out there. gdm always starts Xorg in the first available tty. With tty[1-6] occupied it will be forced to put it in tty7.
William : thanks for taking the time to comment here. However I don't agree with your solution : if gdm is started in tty7, would the flicker-free boot still work ? I mean Plymouth seems to display its messages in tty1, so switching to tty7 to display gdm might make the screen flicker, Am I right ?
I made some mods to a few of the upstart jobs and ran a test today. These changes allowed me to get gdm to stay put on tty7 when I logged out and logged back in. I also tested switching runlevels, tty[1-6] remained available and gdm was always on tty7 in runlevel 5. When I get a chance I'll compile a list of the changes I made just in case anyone is interested. With regards to screen flicker there was a moment between plymouth boot status and gdm that tty1 was displayed. It was very quick. I felt the trade-off between getting gdm to stay put on tty7 versus tty1 being displayed during startup was worth it. tty1 is also always available, whereas with the current setup, it becomes unusable. Not sure if this is the ultimate solution, but it does work. I'm thinking another solution would require changes to gdm so that it could be assigned a specific tty when started. I'm just beginning to understand how all the jobs come together with upstart. Seems like there will need to be more thought put into the sequencing of jobs. Maybe the naming conventions in /etc/event.d will end up being similar to the numbering used on files in the /etc/rc.d/rcX.d directories.
A little ping : is there some work in progress to resolve this issue ? I have also seen that F13 will come with new upstart : did anyone make a test with rawhide ?
I did some testing on F13 Beta. The good news is that changing init modes works. The bad news is that a login followed by a logout is still a bug. It looks like gdm or X crashes when you logout and when it restarts itself it moves the X session to tty7 since that is the next available tty. tty1 continues to get abandoned during a logout. That is where things stand going into the latest release of Fedora.
Thanks for the update. Can you add Enable=true to the [debug] section of /etc/gdm/custom.conf reproduce and then attach /var/log/messages and /var/log/gdm ?
Created attachment 410263 [details] messages Log File This is the log from Rawhide (F13). I copied everything from the point of restart. After the restart I logged in with a regular user, then logged out and logged back in. Clock in Gnome was showing 19:06 at time of logout.
Created attachment 410264 [details] log after initial login
Created attachment 410265 [details] log after logout
Created attachment 410266 [details] greeter log after initial login
Created attachment 410268 [details] greeter log after logout
Created attachment 410270 [details] slave log after initial login
Created attachment 410271 [details] slave log after logout
It's interesting how things will change with the systemd (http://fedoraproject.org/wiki/Features/systemd). It's a new startup manager planned for F14. Maybe it's worth reassigning the bug there?
I have F14 Alpha running and the same problem exists with gdm moving from tty1 to tty7 after logging out. If the problem is resolved by adjusting the startup sequence then systemd would be the place for this bug. However, if finding out why gdm restarts after logging out is desirable then it should remain here. systemd definitely adds a new landscape to Fedora. After the install my system was starting up in runlevel 3 instead of 5. Then after updating it started booting in rescue mode (that was new). Changing the entry in inittab did nothing to correct the problem. The link /etc/systemd/system/default.target was pointing to the wrong location. If you run into the same problem, it needs to point to /lib/systemd/system/runlevel5.target which in turn points to /lib/systemd/system/graphical.target.
Created attachment 446401 [details] hack to always force active VT After boot gdm-simple-slave is run with the "--force-active-vt" parameter. After logout gdm-simple-slave is re-run, but without this parameter - so it runs on vt7 instead of vt1. The attached patch makes gdm-binary always pass "--force-active-vt" to gdm-simple-slave. I am not proposing this as a fix. I'm pretty sure it would break something else. It's merely to point out why gdm moves to another VT after user logout.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. 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 WONTFIX if it remains open with a Fedora 'version' of '12'. 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 prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 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. Thank you for reporting this bug and we are sorry it could not be fixed.