Ubuntu

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

Reported by Patrick Welche on 2010-05-26
88
This bug affects 14 people
Affects Status Importance Assigned to Milestone
SLiM
Confirmed
Undecided
Unassigned
X.Org X server
In Progress
High
xdm (Ubuntu)
High
Unassigned
Lucid
High
Unassigned
Maverick
High
Unassigned
Natty
High
Unassigned

Bug Description

Binary package hint: xdm

Bug discovered after upgrading an xdm-using 8.04.2 LTS x86_64-desktop laptop to 10.04 LTS, but now repeated as follows.

Take default gdm-using 10.04 LTS x86_64-desktop laptop
aptitude install xdm
and set xdm as the default window manager
restart

You will now see the ubuntu white/red dots animation, and that's as far as things go.
ctrl-alt f1 gets you a log in prompt
ps ax | grep dm
shows nothing - so this isn't the same as the "both gdm and xdm run" bug.

In fact
ps ax | grep -i x
returns nothing.

Extras: x.org x server v 1.7.6, intel graphics controller. According to kern.log
fb0: inteldrmfb frame buffer device
... drm Initialized i915
vga16fb: not registering due to another framebuffer present

so things should be set for X to start, namely drm Initialized looks hopeful

Yet running xdm -debug 2 from vt1 shows
...
/usr/bin/X :0 vt7 -nolisten tcp -auth /var/lib/xdm/authdir/authfiles/... (all OK)
...
(EE) intel(0): [drm] failed to set drm interface version.
                           Failed to become DRM master.
                           failed to get resources: Bad file descriptor
                           Kernel modesetting setup failed
(EE) Screen(s) found, but none have a useable configuration.
Also surprising as:
drmOpenDevice: node name is /dev/dri/card0
                         open result is 9 (OK)
(Chipset GM45)

So, how come X thinks drm isn't setup, yet the kernel thinks it is?

Work around: put gdm back as default with dpkg-reconfigure {gdm|xdm}

Now comparing Xorg.0.log in broken xdm and working gdm cases, xdm has:

xf86OpenConsole: setpgid failed: Operation not permitted
xf86OpenConsole: setsid failed: Operation not permitted

and later drmOpenByBusid returns nothing as opposed to pci:0000:00:02.0

So, why the permission denied? apparmor not treating xdm as well as it treats gdm?

(no ubuntu-bug -p xdm included, as I am writing this on a working single-boot NetBSD/i386 laptop)
---
Architecture: amd64
DistroRelease: Ubuntu 10.04
Package: xdm 1:1.1.8-6ubuntu2
PackageArchitecture: amd64
ProcEnviron:
 LANGUAGE=en_GB:en
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-22.33-generic 2.6.32.11+drm33.2
Tags: lucid
Uname: Linux 2.6.32-22-generic x86_64
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

Created attachment 18543
mandriva patches against xdm 1.1.8

XDM lacks consolekit support. This results in various problem when XDM is used to login into desktop: for example, DBus messages are blocked by PolicyKit.

I found a set of patches from KDM adapted to XDM in Mandriva SRPMS, but I wonder why they are not upstreamed.

CCing SUSE and Mandriva Xdm maintainers.

Paulo (pcpa): are there any specific reasons why these patches are not upstreamed?

(In reply to comment #1)
> Paulo (pcpa): are there any specific reasons why these patches are not
> upstreamed?

  None that I know of. But I am afraid I don't understand consolekit
very well. I did the patch upon request, based on kde3 kdm's patches.

  But I was told it is working correctly.

While I don't understand what all the changes in those patches are for,
I do understand the GPLv2 header in the new consolekit files - X.Org does
not accept any GPL licensed code in our apps, so these patches will not
be acceptable until relicensed under an MIT-style license.

From a technical standpoint:
- 0004-Support-kdm-extended-syntax-to-reserve-a-server-for.patch
   - is this really needed for consolekit? This seems unrelated.

-0005-Initialize-the-greeter-only-after-checking-if-the-th.patch
   - seems reasonable, though I wonder about side-effects in people's
     setup scripts, if any assumed the xdm greeter window was displayed first

-0006-Ass-console-kit-support-to-xdm.patch
   - I might make this a bit less #ifdef heavy, but it seems okay

-consolekit-xdm/0007-Add-files-required-by-consolekit-support.patch
   - I don't know enough dbus or consolekit to comment on most of this
   - The /proc/%d/stat section would need to be #ifdef linux

Created attachment 28437
xdm-consolekit.diff

This is a patch by Takashi Iwai we're planning to use for openSUSE 11.2. See

  https://bugzilla.novell.com/show_bug.cgi?id=528829

for more details.

Created attachment 34643
xdm-consolekit.diff

Now with better error message when console-kit-daemon is not available/running

Bryce Harrington (bryce) wrote :

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.]

tags: added: needs-xorglog
tags: added: needs-lspci-vvnn
Changed in xdm (Ubuntu):
status: New → Incomplete

apport information

tags: added: apport-collected
description: updated

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...

Bryce Harrington (bryce) on 2010-05-27
tags: added: lucid
Patrick Welche (prlw1) wrote :

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

Patrick Welche (prlw1) wrote :

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...

Patrick Welche (prlw1) wrote :

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)

Bryce Harrington (bryce) on 2010-05-28
tags: removed: needs-xorglog
tags: removed: needs-lspci-vvnn
Changed in xdm (Ubuntu):
status: Incomplete → Confirmed
Bryce Harrington (bryce) on 2010-05-28
tags: added: hardy
Patrick Welche (prlw1) wrote :

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.

Patrick Welche (prlw1) wrote :

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.

Patrick Welche (prlw1) wrote :

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?)

Patrick Welche (prlw1) wrote :

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.

Thorin Hopkins (topy) wrote :

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.

Thorin Hopkins (topy) wrote :

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

It seems nobody apart from Mandriva/openSUSE is interested into having this support in xdm. Hence closing as WONTFIX.

Yury V. Zaytsev (zyv) wrote :

Same problem on Radeon 9250 / Maverick.

tags: added: maverick
summary: - [Lucid] Not possible to use xdm, only can use gdm
+ Not possible to use xdm/wdm, only can use gdm (Lucid, Maverick)
Yury V. Zaytsev (zyv) wrote :

The workaround doesn't for for me on Maverick.

Changed in slim:
status: New → Confirmed

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.

Mark Eichin (eichin-gmail) wrote :

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.

Steve Langasek (vorlon) on 2011-02-23
Changed in xdm (Ubuntu):
importance: Undecided → High
status: Confirmed → Triaged
Steve Langasek (vorlon) wrote :

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.

affects: slim → lqueue
Changed in xdm (Ubuntu Maverick):
status: New → Triaged
Changed in xdm (Ubuntu Lucid):
status: New → Triaged
importance: Undecided → High
Changed in xdm (Ubuntu Maverick):
importance: Undecided → High
Changed in xorg-server:
importance: Unknown → High
status: Unknown → Won't Fix

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?

Prashant Gupta (prashu20) wrote :

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

Changed in slim:
status: New → Confirmed
Peter Byrne (peter-byrne) wrote :

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?

Yury V. Zaytsev (zyv) wrote :

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

Yves-Alexis Perez (corsac) wrote :

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

Robert Muil (robertmuil) wrote :

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.

(In reply to comment #6)
> It seems nobody apart from Mandriva/openSUSE is interested into having this
> support in xdm. Hence closing as WONTFIX.

Untrue as both ArchLinux and Gentoo are carrying custom patch to enable native ConsoleKit support in XDM too.

Can we reopen this bug, please?

Four downstream dists seem like enough.

Reviews of each of the three as of yet unreviewed patches are welcome.

These urls are mentioned in Gentoo’s patch:

http://bugs.gentoo.org/360987
http://projects.archlinux.org/svntogit/packages.git/plain/trunk/xdm-consolekit.patch?h=packages/xorg-xdm
http://lists.x.org/archives/xorg-devel/2011-February/019615.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=615020

Samuli: I don’t see any license info in the patch in portage; it is definitively under an MIT-style license?

(In reply to comment #8)
> Four downstream dists seem like enough.
>
> Reviews of each of the three as of yet unreviewed patches are welcome.

Yes, as maintainer, I've been waiting for someone to review the patches
on the xorg-devel list (since I don't have time to learn enough about the
consolekit API myself to figure out if they're doing the right things) and
not really caring if someone is playing games with the bug state here
because they're feeling pissy.

Hopefully between those four dists you can find at least *one* person
willing to put in the time to give the patches a review.

I will impose only two absolutely required conditions on such patches:
 - Unlike the first set submitted for this bug, they must be under a
   MIT license, not changing the xdm license to GPL or anything else.
 - They must do whatever autoconf or other checks are necessary to
   avoid breaking systems without consolekit.

(In reply to comment #8)
> Four downstream dists seem like enough.
>
> Reviews of each of the three as of yet unreviewed patches are welcome.
>
> These urls are mentioned in Gentoo’s patch:
>
> http://bugs.gentoo.org/360987
> http://projects.archlinux.org/svntogit/packages.git/plain/trunk/xdm-consolekit.patch?h=packages/xorg-xdm
> http://lists.x.org/archives/xorg-devel/2011-February/019615.html
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=615020
>
>
> Samuli: I don’t see any license info in the patch in portage; it is
> definitively under an MIT-style license?

The patch in Arch and Gentoo is modified (improved) copy of the OpenSuSE patch. So license is presumably same as what OpenSuSE is using for their patch.

(In reply to comment #9)
> - They must do whatever autoconf or other checks are necessary to
> avoid breaking systems without consolekit.

This seems to be covered with the Arch/Gentoo patch based on testing. Tested it pretty exhaustively before pushing it to our users.

Changed in xorg-server:
status: Won't Fix → In Progress

Sure, my patch just follows the license of the original code. So it's in MIT/X11 license.

> Sure, my patch just follows the license of the original code. So it's
> in MIT/X11 license.

Cool. And to be clear, I only asked because of the license issue with
the first patch on this bug report.

JC Hulce (soaringsky) wrote :

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

Changed in xdm (Ubuntu Maverick):
status: Triaged → Invalid
dino99 (9d9) on 2013-05-10
Changed in xdm (Ubuntu Natty):
status: Triaged → Invalid
tags: removed: hardy maverick
bugbot (bugbot) on 2013-05-16
tags: added: maverick
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.