It turns out that xdm is so fast when initializing (thanks to it being lightweight + the Plymouth/DRM/kernel mode-setting stack) that it seems to expose a bug in that stack when tty7 (xdm) is initialized before tty1-tty6 (getty). This is why this bug is only seen by people using xdm as opposed to gdm.
Then, create /etc/init/xdm.conf with the following content:
start on (started tty1 and started tty2 and started tty3 and started tty4 and started tty5 and started tty6)
expect fork
exec /usr/bin/xdm
This waits for all 6 getty instances to be launched before launching xdm, and solves the problem completely for me. I posted about my maddening experience to track down this bug here: http://blog.zorinaq.com/?e=59
I have a fix.
It turns out that xdm is so fast when initializing (thanks to it being lightweight + the Plymouth/DRM/kernel mode-setting stack) that it seems to expose a bug in that stack when tty7 (xdm) is initialized before tty1-tty6 (getty). This is why this bug is only seen by people using xdm as opposed to gdm.
First, remove the misplaced xdm startup script:
$ sudo update-rc.d -f xdm remove
Then, create /etc/init/xdm.conf with the following content:
start on (started tty1 and started tty2 and started tty3 and started tty4 and started tty5 and started tty6)
expect fork
exec /usr/bin/xdm
This waits for all 6 getty instances to be launched before launching xdm, and solves the problem completely for me. I posted about my maddening experience to track down this bug here: http:// blog.zorinaq. com/?e= 59