gdm does not start X unless remove "tty-device-added KERNEL=tty7" from upstart gdm.conf

Scott kindly agreed to debug this next week, he has some idea what's actually going wrong here.

I can understand why this is "correct" for the user, and in fact it's probably correct anyway. I've removed it as a partial fix, and solved the underlying dri/fb race as well - but this may still be a partial fix - some people may end up with a failing to start X.

We'll fix that with the immiment move to devtmpfs (and a mountall upload will patch it in the meantime)

This bug was fixed in the package gdm - 2.29.1-0ubuntu4

---------------
gdm (2.29.1-0ubuntu4) lucid; urgency=low

  * debian/patches/05_initial_server_on_vt7.patch:
    - Fix a bug in the patch: the return value of open() can be zero on
      success, because zero is a valid file descriptor! This probably
      never broke in the real world, because we always have standard
      input set to something, but it's worth fixing bugs when you find
      them ;-)
  * debian/patches/27_save_root_window.patch:
    - Patch taken from the plymouth-integration branch of Upstream GIT
      to save the root window pixmap in a property for other things to
      pick up.
  * debian/patches/28_plymouth_transition.patch:
    - Patch taken from the plymouth-integration branch of Upstream GIT,
      makes gdm check whether plymouth is running on startup; if it is,
      actively arranges for a smooth transition. Also handles getting
      plymouth out of the way in case the X server doesn't start.
  * debian/gdm.upstart:
    - Remove "starting-dm" event; the above patch means we handle
      stopping the splash screen gracefully by ourselves so don't need
      it.
    - Only look at /etc/X11/default-display-manager and /proc/cmdline
      when started automatically; always allow "start gdm" to work.
    - Use the PRIMARY_DEVICE_FOR_DISPLAY tag on the framebuffer or
      drm card devices to start the X server, still falling back on
      end of udev probing (we may have neither). Drop the tty
      part, we need both more and less than this. LP: #491162.
 -- Scott James Remnant <email address hidden> Fri, 11 Dec 2009 06:00:05 +0000

Is it possible to have this fix for Karmic?

I'm using Kubuntu Lucid. Similarly affected. Have to start from CLI with 'startx'. Noted too /etc/init/kdm.conf also have line 'and tty-device-added KERNEL=tty7'. To date, problem not fixed.

Could this bug be related to a problem of having to log in twice on Kubuntu Lucid during start up?

Here is the bug that this one may be related to: https://bugs.launchpad.net/ubuntu/+source/consolekit/+bug/495100

No, Johan, don't think it is related to bug 495100. It's just that sometimes auto login works, most times it didn't. But I recall a warning that explicitly states that autologin does not work when I downloaded alpha1. So I did not file bug for it. But I always reset my locale so that Thunderbird3 can set my date format to dd/mm/yyyy otherwise it uses mm/dd/yyyy. I am not sure if this has anything to do with the issue at hand. But Karmic/Hardy Kubuntu is not affected by it.

Also commenting out "# and tty-device-added KERNEL=tty7" does not help either.

Thanks for looking into this. It is of course, not a show stopper and I may do a clean install for alpha3 if problem persists. By the way, my version is upgraded (continually) from alpha3 Karmic. Thought I better add a comment in case it may be important for the developers to be aware of. I do have 'production' partitions for final version Karmic and Hardy kde 3.5.10 (s-linked from same firefox, thunderbird, etc config files) so if it is not critical, I have no problem with it. I'm trying to help whatever way possible.

Thanks again. Appreciate what you guys are doing.

Latest update of kde 4.4 rc1 on 12th Jan resolved problem.