Since failsafe-x was enabled in karmic it starts if gdm is disabled and kdm is used. (low graphics mode error)

i am using NVIDIA geforce 8600M GT and have the same issue. nonfree drivers installed. I do not loose the desktop effects; everything else works right.

I've got a similar problem after updating kubuntu karmic for two computers.

I've found a bad workaround for the first computer by editing /etc/gdm/failsafeXinit
and 'exit'ing the script before the line "# Scan Xorg.0.log for errors".

The second one is unusable even in recovery mode with the workaround.
I have to use the former kernel 2.6.31-14 to get things apparently normal.

I've got a similar problem after the update:
my kdm doesn't even start and Restore-Console is only possible with older-kernels. (Same as Francesco Ziegler said)

Affects me too.

One can find the full error logs in this attachment. The main error complains about /usr/lib/dri/r600_dri.so not being found.

The full error is actually:

(II) AIGLX: Screen 0 is not DRI2 capable
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 12, (OK)
drmOpenByBusid: Searching for BusID pci:0000:02:00.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 12, (OK)
drmOpenByBusid: drmOpenMinor returns 12
drmOpenByBusid: drmGetBusid reports pci:0000:02:00.0
(EE) AIGLX error: dlopen of /usr/lib/dri/r600_dri.so failed (/usr/lib/dri/r600_dri.so: cannot open shared object file: No such file or directory)
(EE) AIGLX: reverting to software rendering
(II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so

Found in Xorg.0.log

Ironically, I think that the bug is the 'low graphics mode' popup itself, and not so much the missing file since I don't run the non-free/fglrx drivers. This (EE) error was probably always present in my logs, but never triggered the popup before.

The low graphics mode popup also gives an option to re-generate the configuration for current hardware but it is not able to generate.

It seems that reverting x11-common to version 7.4+3ubuntu7 by "sudo apt-get install x11-common=7.4+3ubuntu7" makes the bug go away again.

Nope i have done that. I did revert but the issue still persist.

Have you tried reverting the other xorg packages, too?

Hey guys, do you use KDM or GDM as a login manager? We have several deployments here, and it seems that the bug only affects the installations that we have configured to use KDM as login manager (we have both ubuntu-desktop and kubuntu-desktop installed).

Yep, using KDM.

i will also confirm that the problem went away by switching to GDM.

Using KDM as login manager. I can check using GDM but I do not want to switch to GDM as I use kubuntu more.

Michael Ummels >> yes I tried reverting the package it worked well for 1 boot but did not work further. Also I need to install ATI catalyst driver for desktop effects. I don't think this driver has anything to do with this error as before updating it was working fine (with acpi_services=off option).

This is the command i used to revert the package, may be it helps to someone else:
sudo aptitude -V install x11-common=1:7.4+3ubuntu7

reverting x11-common worked for me. thx!
but the ureadhead error message remains.

Changing to gdm helped but another issue is my desktop effects are not staying persistent.
And I don't want to stay gdm. I would prefer KDM login manager as I use Kubuntu more than the gnome.

Changing to gdm command:
sudo dpkg-reconfigure gdm

i think this is an issue in KDM as the issue seems to only effect KDM users, and the issue is solved (for most people anyway) by switching to GDM: http://ubuntuforums.org/showthread.php?t=1343261&page=3

I have very similar problems but the video driver in use is xserver-xorg-video-intel . In addition to "Ubuntu running in low-graphics mode" error though all video is unusable--drop to command prompt, etc, produce a few colored pixels on the virtual terminals but that's all. Recovery mode boots are also unusable on this machine with the 2.6.31-15 kernel and 1:7.4+3ubuntu10 xserver-related packages installed.

The only reliably working configuration was to revert back to the 1:7.4+3ubuntu7 versions of all xserver packages and the 2.6.31-14 kernel.

For those who want try degrading the packages: For me it did not work, but still can be tried.

sudo aptitude install x11-common=1:7.4+3ubuntu7
sudo aptitude remove ureadahead
sudo aptitude install libglu1-xorg-dev=1:7.4+3ubuntu7
sudo aptitude install xlibmesa-gl-dev=1:7.4+3ubuntu7
sudo aptitude install xserver-xorg-video-all=1:7.4+3ubuntu7
sudo aptitude install xserver-xorg-input-all=1:7.4+3ubuntu7
sudo aptitude install xserver-xorg=1:7.4+3ubuntu7
sudo aptitude install xorg=1:7.4+3ubuntu7

reboot after this

With an Intel IGP, even booting up in recovery mode is of no help. After the kubuntu logo fades, I'm faced with a blank screen.

Using a DELL laptop M1210 with an Intel chip set. Upstart gets the wrong screen resolution for the "failsafe" mode which it uses to try and tell me that Ubuntu is using low resolution mode. I'm left looking at a mushed up display. Attempts to reach a console are in vain as all I can get are blank screens.

Booting with a 2.6.28 kernel was the only way I could get any sense out of the system. Both 2.6.31-14 and 2.6.31-15 displayed the same symptoms.

Now rolled back the X updates (as per post 19) and I've got a working system again using 2.6.31-14.

Sorry, last part should read "working system with 2.6.31-15"

I can confirm post #20 and #21. Havin an intel card and kdm as window manager, the x-server-upgrade breaks *both*, the normal boot + rescue mode for *both* kernels 2.6.31-14 and -15.After boot, the only thing to see is a black screen with two "-" signs top left and right.

The only way to solve the problem is booting from a live disc, running a chrooted environment and switch to gdm. see this (germman) manual: http://www.ubuntu-forum.de/artikel/47993/gdm-update-hat-kdm-geschrottet.html

System: ubuntu 9.10, acer travelmate 8371

I found the following workarounds:
During grub boot (or in /boot/grub/menu.lst) edit the kernel options to include nosplash nomodeset
There is still an error during X startup but now the "Exit to console login" works (consoles are no longer all black).
Also after exiting to the console, sometime later an X server with kdm successfully starts on virtual console 8! (I have never before had an X server run on VC 8).

Once you can get to a working console login you can
sudo dpkg-reconfigure gdm

For me this allowed X to start normally on VC7 without any errors. (I guess you have to be sure that gdm is installed before this will work :-).

Same problem here. Kubuntu 9.10, KDE 4.3.4, Nvidia card, nouveau driver.
The x11-common downgrade to 1:7.4+3ubuntu7 did work for me too as a temporary workaround.

I'm not sure if this the same bug I'm seeing, but it sounds similar. Using a Thinkpad T42p with ATI M10 NT/FireGL Mobility T2 chipset.

If I have xserver-xorg-video-vesa installed and "splash" set in kernel command line arguments then I will get the "Ubuntu is running in low-graphics mode" error message and be unable to continue further. Solution is either to remove xserver-xorg-video-vesa or to remove "splash" option from kernel command line arguments. I haven't tried installing gdm.

This bug looks like a dupe of bug #481514

Can anyone else confirm that removing package xserver-xorg-video-vesa or turning off splash fixes this? If not then my bug is different and I shall file another report.

setting nosplash nomodeset as kernel arguments did work for me
I've xserver-xorg-video-vesa 1:2.2.1-1

I got KDM back up with x11-common=1:7.4+3ubuntu10. Details below.

Eli, I think it's related to this.

I have an Intel IGP. I managed to get the failsafe X11 up and running by changing the value for "Driver" from "vesa" to "intel" in the newly created /etc/X11/xorg.conf.failsafe. I believe that xorg.conf.failsafe was created when x11-common=1:7.4+3ubuntu10 was installed. Previously, not even the (not quite) bulletproof failsafe mode would come up, nor any terminals. I had to use a live cd to do anything. Painful.

To get KDM back and running, I created a new xorg.conf file that contains only the following:

Section "Device"
        Identifier "Configured Video Device"
        Driver "intel"
EndSection

I too suffered from this issue after the xorg updates in question. My Toshiba Satellite M45-S265 laptop uses an Intel 915GM graphics card. I also stopped experiencing this issue when switching to GDM. I reverted back to the older xorg package versions as mentioned above, which got rid of the issue. I can now use KDM with no errors.

Prior to this, the only way I could still login with KDM was to hit "ESC" when the Kubuntu splash screen appeared, then hit CTRL+C repeatedly after the bootup steps started appearing onscreen.

cd /etc/init
sudo mv failsafe-x.conf failsafe-x.conf-disable
cd /etc/init.d
sudo mv failsafe-x failsafe-x-disable

works for me -- ive been told that this is an issue related to kdm trying to start before video drivers are loaded: all credit for this workaround goes to doctordruidphd on ubuntuforums. see http://ubuntuforums.org/showthread.php?t=1343261&page=5

Me too with this issue after xorg update. Here on a ATI Radeon Xpress 1100. Reverting to older packages resolved the problem. I try again and download the new packages and the same problem. Using GDM no problem to login. Now I use the following command proposed at the forum, http://ubuntuforums.org/showthread.php?t=1343261&page=5, and KDM is working without problem with all the new packages:
cd /etc/init
sudo mv failsafe-x.conf failsafe-x.conf-disable
cd /etc/init.d
sudo mv failsafe-x failsafe-x-disable

Doctordruid's workaround works for me also. I upgraded the packages I had previously downgraded regarding xorg, etc and performed the steps in doctordruid's workaround. I rebooted and was able to use kdm with no problem.

Nice! Lots of workarounds for this. Can we get the package updated itself with possible bugs removed from Ubuntu?
Anyone can help so that this bug reach to them and they can take action for it?

We would love a bug free ubuntu, don't we?

It's a big free kubuntu that I'm after. Ubuntu users are living free and easy.

It's interesting that this post suggests a timing issue with KDM. http://ubuntuforums.org/showpost.php?p=8420206&postcount=10

I have to report that this bug does also affect other login-managers (well, one at least: Slim).
And I am using a Nvidia 9500gt video card - not an ATI. So it does not seem to have much to do with the video card actually.

I had the same problem: After an update with the automated update-manager yesterday and the following reboot I was left with the "low graphics mode"-error.
_Sometimes_ clicking through "run in low-graphics-mode for one session" etc. led me to my normal login (with Slim). And I would even get a running Compiz... a bit surprising for the expected "low-graphics-mode"... but Compiz would silently die sometime in between and leave me without graphic-effects.
Yet very often after reboot I was left without a login and only with scrambled colors on top of the screen or, even worse, a crashed system with a black blank screen where only turning power off helped!

I tried many possible solution-variations of tinkering with xorg.conf, deleting and reinstalling the Nvidia-drivers etc. - all to no avail. I was so sure that this had something to do with the updated kernel and non-fitting or conflicting video-drivers...

But it was apparently a conflict between GDM and "the other login-manager" - in my case Slim, not KDM.
Directly after deinstalling Slim and "dpkg-reconfigure gdm" the "low-graphics-mode" problem is gone.

Seems to me its _not_ KDM or Slim who are having the bug.

If you have both kdm and gdm installed, you have upstart configurations for both of them:

/etc/init/gdm.conf:
(..)
script
    [ ! -f /etc/X11/default-display-manager -o "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/sbin/gdm" ]
(..)

/etc/init/kdm.conf:
(..)
script
    [ ! -f /etc/X11/default-display-manager -o "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/bin/kdm" ]
(..)

Since that fatal xserver-xorg update, we also have

/etc/init/failsafe-x.conf:
(..)
start on stopped gdm EXIT_STATUS=[!0]
stop on runlevel [06]

task

exec /etc/gdm/failsafeXServer

If kdm is the active display manager, /etc/X11/default-display-manager contains "/usr/bin/kdm", so upstart will try to start both gdm and kdm, but gdm will fail because of the check quoted above. This will emit a stopped gdm event with EXIT_STATUS != 0, which will start /etc/gdm/failsafeXServer. Now both kdm and failsafeXServer are started and we have a problem.

One solution is to add the following line at the start of /etc/gdm/failsafeXServer:

[ ! -f /etc/X11/default-display-manager -o "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/sbin/gdm" ] || exit 0

This will terminate failsafeXServer if the default display manager is not gdm.

As a patch for the system configuration:
--------------------------------------------------
--- /etc/gdm/failsafeXServer.orig 2009-12-06 12:42:47.000000000 +0100
+++ /etc/gdm/failsafeXServer 2009-12-06 12:44:09.000000000 +0100
@@ -24,6 +24,8 @@
 # not, write to the Free Software Foundation, Inc., 59 Temple Place,
 # Suite 330, Boston, MA 02111-1307 USA

+[ ! -f /etc/X11/default-display-manager -o "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/sbin/gdm" ] || exit 0
+
 xorg_conf_failsafe=${BPX_XORG_CONF_FAILSAFE:-"/etc/X11/xorg.conf.failsafe"}
 xorg_conf=${BPX_XORG_CONF:-"/etc/X11/xorg.conf"}
 run_dexconf=${BPX_RUN_DEXCONF:-"yes"}
-------------------------------------------------

and as a patch for the xserver-xorg package:
-------------------------------------------------
diff -ru xorg-ubuntu-git.orig/debian/local/Failsafe/failsafeXServer xorg-ubuntu-git/debian/local/Failsafe/failsafeXServer
--- xorg-ubuntu-git.orig/debian/local/Failsafe/failsafeXServer 2009-11-09 08:58:44.000000000 +0100
+++ xorg-ubuntu-git/debian/local/Failsafe/failsafeXServer 2009-12-06 13:21:02.000000000 +0100
@@ -24,6 +24,8 @@
 # not, write to the Free Software Foundation, Inc., 59 Temple Place,
 # Suite 330, Boston, MA 02111-1307 USA

+[ ! -f /etc/X11/default-display-manager -o "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/sbin/gdm" ] || exit 0
+
 xorg_conf_failsafe=${BPX_XORG_CONF_FAILSAFE:-"/etc/X11/xorg.conf.failsafe"}
 xorg_conf=${BPX_XORG_CONF:-"/etc/X11/xorg.conf"}
 run_dexconf=${BPX_RUN_DEXCONF:-"yes"}
-------------------------------------------------

Anyone with 2.6.31-16 installed? And is this problem resolved with it? I am worried that should we install it or not.

Update: I have updated with 2.6.31-16 by selecting the required packages. Things are working fine. I still have the 7 packages downgraded (mentioned above) waiting to be updated. I hope it works for everyone else.

Debdiff for karmic-proposed

Although the proposed patch will fix this, it isn't the best approach.

The "failsafeXServer" script should be split off from gdm, made its own package,
and should be aware of all possible login managers.

The man page init(5) has a lovely example:

   stop on stopping gdm or stopping kdm

What's wanted is for /etc/init/failsafe-x.conf to say something like:

   start on stopped $(basename $(cat /etc/X11/default-display-manager))

I don't know if Upstart's parsing supports that sort of shell pipeline substitution.
I also don't know if it is true in all cases that the _service_ ("gdm", "xdm" etc.)
name and the name of the binary shoved into /etc/X11/default-display-manager
match in this manner. So the above is only a conceptual example.

What is even more wanted is a concept of a generic service in Upstart. Similar
to how several .deb packages can provide a single service (Java plugin, web
browser, etc.); similar to how /etc/alternatives works:

   start on stopped display-manager

and some other parts of the system deal with mapping "display-manager" to
whatever it's supposed to be.

BTW this problem has entirely to do with gdm's X failsafe script vs. other login
managers, and nothing to do with kernel releases, choice of video driver, etc.
I'm having the problem with xdm + nVidia open source driver (whatever it's
called).

Another possible field workaround, besides switching to gdm or patching one
of the mentioned scripts, would be to _remove_ gdm. This might be difficult,
depending on what else is marked dependent on it.

Hmmm, in fact I see that the various "failsafe*" files are part of the "x11-common" package, not of
gdm. The simple fact that "x11-common" is laying files down in directory "/etc/gdm" is a warning
flag (I'm mildly surprised that `lintian` doesn't complain about it).

@Bela: I completely agree with you that this isn't the best solution. But we should at least upload the existing fix/workaround now to fix the regression and then maybe open another bug about adding other DM support to failsave-x in lucid.

Accepted gdm into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I had success with Philip's gdm patch! "kdm[1064]: X server died during startup" and "kdm[1064]: Failed to start X server. Starting failsafe X server." are not to be found in the syslog.

PLEASE refactor this "upstart sprawl." This was a very painful bug for me. As an Intel IGP owner, I wasn't even given a terminal to fall back to. It would be a shame if this bug reared its head again.

I have fixed packages queued in my ppa for anyone that doesn't want to build gdm on their own (or wait for the official update). https://launchpad.net/~kachristmas/+archive/ppa

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

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

  * debian/gdm.upstart: Do not fail with exit status !=0 on startup
    when disabled. LP: #491483
 -- Philip Muskovac <email address hidden> Mon, 07 Dec 2009 19:33:05 +0100

Please disregard the packages in my PPA and use the official proposed packages. Martin Pitt beat me by a minute.

Hi ! (sorry for my bad english)

sorry I don't read all answer...

your problem is a same of that =>

https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/459639

?

No, you say in post #13 there that you do NOT have gdm installed, this
bug is about failsave-x launching while gdm is installed.

On 12/08/2009 12:03 AM, jajaX wrote:
> Hi ! (sorry for my bad english)
>
> sorry I don't read all answer...
>
> your problem is a same of that =>
>
> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/459639
>
> ?
>
>

Is the official update out? Or I need to wait for a while? I know I can take it from proposed but still would prefer from the official updates.

@Philip Muskovac: What you mentioned in post #66, I would like to get updates on the same. As I also agree with Bela as the failsafe-x should be aware of all the DMs installed on the system. Could you please let me/us know if some different bug is opened to resolve the same.

Manish,

we need to test it from -proposed first and ensure that the update does not cause regressions and fixes the problem. So any help with that and feedback is appreciated. Thank you!

I'm waiting for 3 weeks for a patch for my Laptop(Intel), my home PC(NVIDIA) and my PC at work(NVIDIA). What a shame that such things could happen. It cost me so much time. Is Karmic a beta? When will the repositories be updatet?

dm [2009-12-08 10:33 -0000]:
> When will the repositories be updatet?

It will move to -updates when the package in -proposed got confirmed
to work.

I have activated 'proposed' in sources.list.

deb http://archive.ubuntu.com/ubuntu/ karmic-proposed restricted main multiverse universe

But I can't see the 'gdm (2.29.1-0ubuntu3)'

Sorry, the package had a bad version number; I uploaded 2.28.1-0ubuntu2.1 to karmic-proposed now.

> But I can't see the 'gdm (2.29.1-0ubuntu3)'

That's the version for lucid, not for karmic.

This bug affects only KDM (Kubuntu) users, why is not mentioned in the above list?

s/only/also

Surprise, with the new GDM package I have a usable notebook again. It seems, the patch does what it should. Thank you for all the help. But I think, such a bug should be found before so many users get an unusable system.

Thanks
DM

I also have just tried out the proposed gdm fix and am all up and running again. Thanks to all who have helped with this one. My situation was Ubuntu install where I added kubuntu-desktop and chose kdm, hence gdm and kdm co-resident. As laptop had intel graphics I got as others with intel graphics have commented only garbled console and no X. Initial workaround for me was to remove the splash option in grub interactively. But now all working fine. Thanks again.

This bug was fixed in the package gdm - 2.28.1-0ubuntu2.1

---------------
gdm (2.28.1-0ubuntu2.1) karmic-proposed; urgency=low

  * debian/gdm.upstart: Do not fail with exit status !=0 on startup
    when disabled. LP: #491483
 -- Philip Muskovac <email address hidden> Mon, 07 Dec 2009 16:30:05 +0100

Can someone tells to people like me that does not have gdm installed at all, but only kdm, how they can have this bug fixed? We opened a new bug but we ended up dupe of this.

However I do not see kdm here involved in the patching.

This bug also affected single-user mode. While it no longer occurs after the fix, the script for failsafe-x should be disabled when booting with kernel option single. It is otherwise extremely ironic that this so-called failsafe-x has the potential to (and in fact did) cause the real failsafe boot option to fail.

gdm and kdm currently check for this. A similar check should be added.

Likewise, kdm's init config should get the similar patch, to avoid this problem from occurring in a possible future kdm-based failsafe X to complement the one that current depends on gdm.

Actually, can failsafe-x be set up to never run unless starting-dm has been emitted? I see a
    initctl emit starting-dm DM=kdm
and a similar line in gdm.conf. I don't know how upstart works, but presumably one can configure it to only consider running if starting-dm has occurred. That seems like a more reasonable fix to failsafe X's propensity to start unwanted and hang machines.

If you don't have gdm installed, you don't have this bug. The failsafe-X job is only ever run when gdm tries to run and fails.

I've reviewed the set of bugs marked as duplicates of this one, and un-duped those that don't match - including bug #459639, which appears to be the one under discussion.

This bug was never a kdm bug; closing the kdebase-workspace tasks as invalid.

> This bug also affected single-user mode.

It affected only systems that had both kdm and gdm installed, with kdm configured as the preferred DM. Users with only gdm installed were not affected by this bug, with or without booting in single-user mode, because the gdm job already exits '0' if it detects the system was booted in single user mode.

I am aware of this; I know the details of this problem, having discovered it independently in the days I spent figuring out why Ubuntu failed to boot on my laptop into either X or single-user mode.

If kdm was used, then this bug also occurred in single-user mode because the configuration check occurs before the single-user check and returned a non-zero exit status. The failsafe-x init script lacks a sanity check to not run when booting into single-user mode, like kdm and gdm do have. While it is true that this bug cannot currently be triggered, this package is *failsafe* X. If care cannot be taken to make sure it doesn't kill the system due to driver problems, extreme care should at least be taken to ensure it does not break existing, more fail-proof, failsafe methods.

If the gdm script ever accidentally returns a non-zero exit status from a future change for whatever reason, this bug will happen again and we will attempt to launch failsafe-x on single-user mode. This is especially unfortunate; presumably if I'm booting into recovery mode, it means that failsafe X already failed and launching it again only risks further disabling the user's machine. It would be good engineering to, for instance, add a check in failsafe-x's script. If not by listening for the starting-dm event, at least do the same /proc/cmdline check that gdm does.

Perhaps change the start on rule to

start on (stopped gdm EXIT_STATUS=[!0] and starting-dm)

But I don't know upstart particularly well, and I cannot test this on my machine; any attempt to bring up failsafe X results in killing it.

I'd really like to purge my systems of this failsafe-x nonsense. Is there documentation some where that explain how to disable the ironically named program? When I was bit by this bug, I didn't have access to another computer to search for a solution. I didn't have a console to read the logs. I didn't have a boot disc either. I had no way of getting a boot disc. I was hosed. It was awful, simply awful.

Upgraded a Dell laptop Ubuntu 8.04 -> 8.10 -> 9.04 -> 9.10. The last upgrade introduced a problem: upon boot there is a popup (of which only the top is visible, the rest is below the bottom edge of the screen) telling me "Ubuntu running in low-graphics mode". Upon ^C I get a console prompt, and "startx" correctly starts X. The problem reappears upon reboot. Commenting out the last line in /etc/init/failsafe-x.conf avoids the popup. (Now no X is started at all, but I am happy with that and can start X with "startx" when desired.)

I will be out of the office starting 12/19/2009 and will not return until
01/13/2010.

Vacation. In urgent cases try to call my mobile at +49-171-765 5871

Just saying that comment #32 solves this problem for anyone using gdm-2.20 also.

This bug affects my multiseat system with Karmic. I am using just gdm and due to the latest gdm doesn't support multiseat I had to downgrade to gdm 2.20. When my X is starting, there are some error messages in the xorg.log which do not affect any functionality as far as I can say

(II) config/hal: Adding input device Logitech 2.4GHz Cordless Desktop
(EE) config/hal: NewInputDeviceRequest failed (8)
(II) config/hal: Adding input device UVC Camera (046d:0990)
(EE) config/hal: NewInputDeviceRequest failed (8)
(II) config/hal: Adding input device Logitech 2.4GHz Cordless Desktop
(EE) config/hal: NewInputDeviceRequest failed (8)
(II) config/hal: Adding input device Power Button
(EE) config/hal: NewInputDeviceRequest failed (8)
(II) config/hal: Adding input device Microsoft Microsoft Wireless Optical Desktop® 1.00
(EE) config/hal: NewInputDeviceRequest failed (8)
(II) config/hal: Adding input device Microsoft Microsoft Wireless Optical Desktop® 1.00
(EE) config/hal: NewInputDeviceRequest failed (8)
(II) config/hal: Adding input device Logitech 2.4GHz Cordless Desktop
(EE) config/hal: NewInputDeviceRequest failed (8)
(II) config/hal: Adding input device Sleep Button
(EE) config/hal: NewInputDeviceRequest failed (8)
(II) config/hal: Adding input device Logitech 2.4GHz Cordless Desktop
(EE) config/hal: NewInputDeviceRequest failed (8)
(II) config/hal: Adding input device Power Button
(EE) config/hal: NewInputDeviceRequest failed (8)
(II) config/hal: Adding input device Macintosh mouse button emulation
(EE) config/hal: NewInputDeviceRequest failed (8)

The failsage-X, particulary the failsafeXInit script detects these messages it attempts to start the failsafe X even though the original X session is working just fine. Then I get problem that the failsafe X runs into conflict with the original X session and I get message

There already appears to be an X server running on display :0.....

Since I cannot figure out how to get rid of the error messages in my xorg log I have to disable failsafe X as described in comment #32.

Just one more comment, if this bug was fixed in latest gdm, to allow people who use multiseat system to take advantages of this fix, it would be nice if can be backported to gdm 2.20.

Yes, there is a task open on this bug report for the gdm-2.20 package, but it doesn't appear that anyone has taken responsibility yet for fixing the bug there.

Xubuntu 9.10 user with ONLY gdm & xfce installed, and 6hrs of his life he will never get back. Rant follows, solution at end:

Boy did this ruin and waste my entire day. I had to reboot to get ALSA backports because the mic on my 3810T is broken with karmic, and actually even with backports it's still broken when using pulseaudio, but fine if I kill pulse. I figured I could get rid of the hideous gdm (non-)theme on my Xubuntu in the process. Unfortunately all the gdm 'theme' changing HOWTOs (by which they really just mean BG or icons) relied on gnome-appearance-properties from gnome-control-center, which would add about 120mb of crap an XFCE user on an SSD neither desires nor has the space for. And the one laudable attempt to spare users the pain of this gdm regression (https://launchpad.net/gdm2setup) failed to change the gdm BG, only xsplash's. I digress. After an hour wasted, I decided to downgrade to gdm-2.20 to get some themes. Mistake!

Fine, /usr/bin/X11R6 no longer exists and someone forgot to fix gdm.conf before putting this in the repositories. No big deal. Reboot. Blank screen. No access to any VTs (tty1-6). Can boot in single-user, and pull S30gdm out of rc2.d. Oh wait, why are those scripts there? No changes seem to have any effect. Another hour disappears. Finally I blindly: log into a blank console, configure networking, add routes, start sshd, and use a colleague's computer to access my machine.
ps -ef ... failsafeXServer? WTF is this? Now the painful discovery of this nightmare called 'upstart' (I should've known something was fishy when Ubuntu lacked an inittab) Adorably, failsafeXServer is referred to as 'bulletproof-X' in /etc/init/failsafe-x.conf. Hah! Not for Intel chipsets. Fortunately this allowed me to find this thread, and Kevin Christmas's blessed post (#30) about hacking 'vesa' to 'intel' in xorg.conf.failsafe.

Finally I can boot into some sort of "low graphics mode," and I begin to feel at home in this thread. So, why isn't it booting gdm?? Oh, it's checking for a /etc/X11/default-display-manager, which I don't have... maybe that'll fix it. Nope. OK I'll just comment that out of init/gdm.conf. Still no go. Wait, what on earth is "gdm-binary??"

So basically gdm-2.20 is broken in these ways
a) Refers to /usr/bin/X11R6 in /etc/gdm/gdm.conf

stale /etc/init/gdm.conf depends on:
b) default-display-manager
c) gdm-binary

...which don't exist... and this was complicated by the broken 'vesa' driver on intel chipsets.

WHAT WORKED:
Creating /etc/X11/default-display-manager with "/usr/sbin/gdm"
and
Changing 'gdm-binary' to '/usr/sbin/gdm' in /etc/init/gdm.conf.

WHAT HELPED:
'vesa' to 'intel' in /etc/X11/xorg.conf.failsafe

Still confused: should gdm be run through the init scripts (S30gdm) or via upstart? Why do both exist? There seems to be a mix and match of daemons that start through one or the other... which feels like anything but clean design. Can someone explain, or correct me?

PS. Why is this a 'low' priority: https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/498732
And why is that bug in gdm and not gdm-2.20? Is the broken init/gdm.conf left over from gdm, or did it come with ...

I don't use gdm, and hit this bug. I was able to make the dialog go away by moving these files out of /etc/init:
gdm.conf failsafe-x.conf plymouth* usplash.conf
I'm sure I didn't need to eliminate all of those, but just failsafe-x.conf alone didn't do it so I cast a wider net.

On

This bug still re-appears in lucid. The underlying problem seems to be that /etc/init.d/failsafe-x.conf is in the wrong package. x11-common should know nothing about gdm and yet here is a gdm referencing file, so as soon as you stop using gdm 2.3, the system is broken. This file should be in the gdm package - along with its supporting cast of files, or perhaps in a separate package where there is need for common elements amongst display managers.

I came up against this problem with re-deploying gdm 2-20 in the lucid environment (to get multi-seat working).

We're not going to fix this issue for karmic or lucid since we don't want to risk regressing anyone, but going forward the plan is to move failsafe-x into a separate package called xdiagnose.