@Seth: I don't believe initctl passes a VT parameter. gdm is either starting X with a VT parameter, or not. It determines whether plymouth is running and if it is, and if it has its screen before the user, gdm tries to determine what VT that is and specifies that to X in a VT parameter. If that is ever VT1, etc. we will know that went wrong. If plymouth isn't running or doesn't think it is showing the splash screen to the user, but the /var/run/gdm file is missing, gdm figures this is the first X to start and hardcodes a start to VT7. If none of that is true, it starts X without a VT parameter, assuming that since it isn't the first launch of X all of the tty jobs will have started by then and there won't be a conflict. There's our current problem.
Does that make sense? Please see the Ubuntu/debian patched gdm files daemon/gdm-simple-slave.c and daemon/gdm-server.c. After getting the source you need to apply the patches in debian/patches by doing a "debian/rules patch" (I always forget). If gdm isn't restarting it might be able to remember that the /var/run/gdm file was missing when it looked and keep the hardcoded VT7. I don't know whether gdm is restarting after X halts with a non-ready kernel module. That possible fix wouldn't fix gdm and X spinning until the the kernel is ready, however. The devs understand that the /var/run/gdm/firstserver-stamp approach is a hack. See the comments in the daemon/gdm-server.c gdm_server_start() function. That's where the vt7 hardcode is that's supposed to stop this from happening if plymouth hasn't already led gdm to vt7. -- X starts on wrong tty: pressing enter after 5 minutes crashes X https://bugs.launchpad.net/bugs/625239 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
