@Jamie: One of the earlier X logs you posted had an error that ended like that--without giving any backtrace.
I see you are running apache. Does Dino's have your fix? Sounds like our fraternal twin bug may have been fixed since Bilal confirmed it is gone. Great catch, Dino. It also sounds like vt7 is as fragile a place to start X as vt1 or vt2, unfortunately. I have a suggestion for helping us determine how different solutions to both of our currently known problems (X crashes when kernel module is not ready, and early X crashes cause X to start on tty1-6) might delay the login screen, but I'm not sure Jamie's computer is in a position to run them. I hope the apache fix does the trick. My suggestion would be to add init jobs that would run the logger command when current gdm start conditions are met, when tty starting conditions are met, when udev ends, when nvidia is modprobed, and other events others think might be significant. I don't know how long we need to delay gdm's start, or delay gdm's restart of X, which might be another approach. @Seth: I'm still trying to understand your thoughts in your solution (B). If I understand, you thought init was telling gdm that it was boot time and start on vt7. init runs mountall which mounts a tempfs (like on /tmp) on /var/run. That wipes out the last boot stamp file and gdm looks for it when it runs without direction from plymouth. So init doesn't explictly tell gdm to run on vt7, or even that it is boot time, but that is the point of a file in the /var/run file system. (The file doesn't really get rm'd, it only existed in RAM during the last boot, but the tmpfs at /var/run keeps it from being kept). But it doesn't have to work that way, of course. Your approach sounds good to me. init jobs could explicitly create a booting-done file and gdm could look for that booting-done file in /var/run. I don't know whether is should specify a vt or whether that should be local to plymouth, gdm, and X. Is that the kind of thing you are talking about? I agree with you (A) sounds good, but is probably impossible to do, particularly between now and 10/10. Because of the 10/10 Maverick release, small, contained, fixes are probably best. And I assume the release team won't want to slow down boot more than necessary and avoid blinking the display unnecessarily. Another, minimal approach, might be to find where in gdm X is ready and create the stamp file there rather than on initial start so retries go to the same place. To address the looping problem, maybe after a failure gdm could sleep for a few seconds before trying X again. Just that change might address both problems and the first part of it is very like what is in place now. In effect gdm would be polling X and it would be polling the kernel. I like both the upstart job and the gdm modification ideas. The perfect fix where upstart is being used to minimize start time would be for nvidia (and intel and ati) to emit a signal to init so it could delay gdm until the necessary kernel driver is ready. But either every driver would need to do that, or the gdm jobs would have to change with the driver, or there would have to be several gdm scripts, each testing to see if it is the one responsible job to start gdm for the graphics driver configuration in use. Maybe the multiple jobs could be done, but I wouldn't like to see that tried this late in the release cycle. Just joining in brainstorming. What do you think about temporary init jobs to measure time between events? -- 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-X, which is subscribed to xserver-xorg-video-ati in ubuntu. _______________________________________________ Mailing list: https://launchpad.net/~ubuntu-x-swat Post to : ubuntu-x-swat@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-x-swat More help : https://help.launchpad.net/ListHelp
