Not possible to use xdm/wdm, only can use gdm (Lucid, Maverick)

Hi Patrick,

Please run the command 'apport-collect BUGNUMBER', which will attach several files we need for debugging.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

apport information

So, I just jumped through the hoop to get around the "needinfo" tag - I think you'll find that all the necessary info is in fact in the original bug report. Extra precise requests for particular experiments to try and particular bits of missing information will gladly be provided. This general "send us loads of logs which may or may not contain the needle in the haystack" (as these are now collected on the working gdm) seems silly...

lspci --vvnn output
Just provided to jump through "needinfo" hoop - no useful information here.

This Xorg.0.log is from a broken xdm run, so shows the "Operation not permitted" written up in the bug report. No more info than in the original bug report, but provided for the "needinfo" hoop. It would be nice to actually get to working on resolving the bug...

Is it right that

$ ls -l /usr/bin/Xorg
-rwxr-xr-x 1 root root 1901280 2010-04-23 18:16 /usr/bin/Xorg

? (I am used to seeing -rws--x--x, then again this must be OK for gdm to work)

Making Xorg setuid (with hindsight obviously) didn't change anything.

The

(WW) xf86OpenConsole: setpgid failed: Operation not permitted
(WW) xf86OpenConsole: setsid failed: Operation not permitted

of the original report is definitely the cause. Looking at a copy of xorg I happen to have, i.e., not necessarily the one used in ubuntu, I see that in xorg-server/dist/hw/xfree86/os-support/linux/lnx_init.c, the calls to setpgid() and setsid() are enclosed in an if(!KeepTty) block. Adding -keeptty to /etc/X11/xdm/Xservers gets me an xdm login prompt and avoids the hang. This isn't the answer, as -keeptty isn't meant for usual operation, and again makes me wonder how gdm is treated differently - as the call is made by the same server in each case.

It seems that I was luckily to get a prompt - I can't get the prompt repeatedly - diffing against the without -keeptty Xorg.0.log, the only difference with -keeptty is that there is no "Operation not permitted" - the drm still fails.

Now I see how I was "lucky" in 7:

If you run gdm, kill it, then xdm will work.
Somehow gdm manages to initialise drm, ie avoids:

(EE) intel(0): [drm] failed to set drm interface version.
(EE) intel(0): Failed to become DRM master.

So simply, I had a some stage run gdm => xdm thereafter, no matter what I tried, would work.

Any clues anyone? (This is an intel (xdriinfo says i965) which I think means that the X driver needs kernel support. What stumps me, is that gdm works, therefore the kernel support must be there, and the driver OK - but what is the difference between the way gdm calls Xorg and the way xdm calls it?)

xinit behaves in the same way as xdm.
drmSetMaster is in xf86drm.c of libdrm, and does an ioctl. How can this be different for gdm vs xdm?

I ran into this problem with xdm and xinit, so I tried switching to SLiM (Simple Login Manager - http://slim.berlios.de/), but I ran into the same problem. It works great, if I've run GDM first, but it fails otherwise. I would like to use something other than GDM.

I can confirm this bug affects both xdm and slim. Running the slim binary directly ("/usr/bin/slim") will work, but calling it through star-stop-daemon ("start-stop-daemon --start --name slim --startas /usr/bin/slim") will cause the error reported in the bug.

Messy workaround for now:
In "/etc/init.d/slim" replace:
start-stop-daemon --start $SSD_START_ARGS ||echo -n " already running"
with:
exec $DAEMON

A similar workaround will work for xdm too.

Slightly better workaround:

In "/etc/init.d/slim" replace:

start-stop-daemon --start $SSD_START_ARGS ||echo -n " already running"

with:

if [ "$(pidof slim)" ]
then
  echo -n " already running"
else
  exec /usr/bin/slim
fi

Same problem on Radeon 9250 / Maverick.

The workaround doesn't for for me on Maverick.

The workaround in /etc/init.d/slim does work for me in Maverick, but I am running on an Intel i915 (8086:2A42). I also added "i915.modeset=1" to my boot options due to bug #566379. Comment 32 for that bug mentions adding "nomodeset" to boot options so X would work with ATI and Radeon.

FTR I'm seeing this on maverick, with radeon.modeset=1 (and options radeon modeset=1) on a Thinkpad T60p, lspci says "ATI Technologies Inc M56GL [Mobility FireGL V5200]", with the fglrx drivers --purged (because they dropped support for this chipset a while back - with the useless proprietary drivers installed, X starts fine but all GL code (glxinfo, glxgears) dies with a near-immediate coredump.)

With the "start gdm, kill gdm, start xdm" workaround, I get working glxinfo and glxgears.

(I haven't tried turning off modeset with fglrx purged, yet.)

I can confirm this issue also with maverick on a Intel 915GM. Just starting xdm after a reboot crashes X with:
[ 158.212] (EE) intel(0): [drm] failed to set drm interface version.
[ 158.212] (EE) intel(0): Failed to become DRM master.
[ 158.212] (**) intel(0): Depth 24, (--) framebuffer bpp 32
[ 158.212] (==) intel(0): RGB weight 888
[ 158.212] (==) intel(0): Default visual is TrueColor
[ 158.212] (II) intel(0): Integrated Graphics Chipset: Intel(R) 915GM
[ 158.212] (--) intel(0): Chipset: "915GM"
[ 158.212] (==) intel(0): video overlay key set to 0x101fe
[ 158.212] (EE) intel(0): failed to get resources: Bad file descriptor
[ 158.212] (EE) intel(0): Kernel modesetting setup failed

Starting kdm, stopping kdm and then starting xdm works as already described before.

This appears to be caused by the xdm package not integrating with upstart. The plymouth process which holds the console open is waiting for a signal that the xdm job is starting up, so that it can let go of the console; but the xdm package, which is not well cared for in Ubuntu, doesn't have an upstart job, so there's no signal sent, which means the plymouth and xdm processes are fighting over the console.

Marking bug #723698 as a duplicate of this one. This is unfixed in natty, maverick and lucid.

Is xdk really the right place to fix it, seeing it also seems to be broken in SLiM, wdm, and probably every other login manager except kdm and gdm?

i installed slim through apt-get and also through package files(software center) and when i type this ,"slim -p /usr/share/slim/themes/default"login screen screenshot comes up but when i restart my computer ,it gets struck at boot no login screen appears .please tell what is wrong i m doing installed all libraries given in packages manually but still no solution

What is the status of this bug - why has it not been assigned to anyone and why does it seem that no one is doing any work on it?

xdm upstream closed it as wontfix, because they claim nobody is interested into it. How come???

Seems that xdm bug is unrelated, it's about consolekit support.

I seem to be seeing this bug also. Trying Slim doesn't get past black screen after the Ubuntu loading logo.

I don't even get access to the virtual terminals, but I have SSH access from another computer and the xorg logs seem very similar to the original poster's, although it seems not to be a permissions issue. The intel driver and drm issue seems to be there...

The workaround in comment #13 works for me. Thank you very much.

Hope this can be fixed properly. Gnome 3 may be beautiful, but it's more or less useless on slower computers.

This bug affects Ubuntu 10.10, Maverick Meerkat. Maverick has reached end-of-life and is no longer supported, so I am closing the bugtask for Maverick. Please upgrade to a newer version of Ubuntu.
More information here: https://lists.ubuntu.com/archives/ubuntu-announce/2012-April/000158.html

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".