Comment 49 for bug 441653

I have had a similar behavior here. I am using the nvidia driver.

I don't really like any of the suggested workarounds here. They are all hacks that don't really fix the bug itself.

This is the relevant code:

            if (ioctl(xf86Info.consoleFd, VT_ACTIVATE, xf86Info.vtno) < 0)
                FatalError("xf86OpenConsole: VT_ACTIVATE failed: %s\n",
                           strerror(errno));

            if (ioctl(xf86Info.consoleFd, VT_WAITACTIVE, xf86Info.vtno) < 0)
                FatalError("xf86OpenConsole: VT_WAITACTIVE failed: %s\n",
                           strerror(errno));

What I think what happens is what Linus has also figured out a while ago (in a similar situation):

"I have chased it down, and what happens is that the new X server is trying
to switch to its newly allocated virtual console, but the old X server that
was started by rhgb is exiting at the same time, and apparently depending
on pure luck (or lack of it), the old X server will switch back to the
original VT (VT#0) JUST AFTER the new X server has tried to switch to its
new VT!

The end result is that when the new X server waits for that switch to take
effect, it will never happen (since we did actually switch to it, but then
the old X server switched back!), and it will wait forever - or rather, it
will wait until a timeout signal comes in, and at that point it will exit
with the above error!"

rhgb is the Red Hat Graphical Boot.

If that is the same scenario which is happening here, there are actually multiple bugs:

* Some process (Ubuntus graphical boot? another XServer spawned by KDM?) tries to activate a different VT just at the same time. Why does it do that? It should not do that.

* Xorg should not hang in such a case.

I filled in a bug about that problem in Xorg here:
https://bugs.freedesktop.org/show_bug.cgi?id=29975

You will find further references and details about the problem on that report.