Bug 947558 - Empty desktop after login
Summary: Empty desktop after login
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: lxdm
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Christoph Wickert
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F19Beta-accepted, F19BetaFreezeException
TreeView+ depends on / blocked
 
Reported: 2013-04-02 18:08 UTC by Jason Montleon
Modified: 2013-05-06 19:52 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-05-06 19:52:13 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
pstree log (3.41 KB, text/plain)
2013-04-14 06:27 UTC, Mamoru TASAKA
no flags Details
ps auwwx & gdb (19.84 KB, text/plain)
2013-04-14 06:31 UTC, Mamoru TASAKA
no flags Details

Description Jason Montleon 2013-04-02 18:08:03 UTC
Description of problem:
After logging in using lxdm I get a blank screen with the desktop wallpaper only. If I don't kill lxdm-binary before trying to reboot it hangs up the reboot process as well.

Version-Release number of selected component (if applicable):



How reproducible:
Seems always, a clean install on a vm, and a desktop upgraded from Fedora 18 where lxdm was working, both show the behavior

Steps to Reproduce:
1. Install Fedora 19 Alpha
2. Intall lxdm, configure lxdm as your display manager, and reboot
3. Login
  
Actual results:
Blank screen

Expected results:
Normal desktop session

Additional info:
gdm is working, although lightdm seems to also be broken (different symptoms).

lxdm.log shows:
tail /var/log/lxdm.log
Loading extension GLX
resize called 1680 1050
** Message: add 0x9cc950

** Message: prepare greeter on :0

** Message: start greeter on :0

** Message: create ConsoleKit session fail

console-kit-daemon was not enabled and was not running, but looking at a Fedora 18 system it looks like it is not enabled there by default, though something started the daemon. Enabling the service, rebooting, and verifying it was running didn't do anything to change things.

I also set selinux permissive and tried again with no success.

Comment 1 Christoph Wickert 2013-04-03 06:25:22 UTC
What version of lxdm is this? What session are you trying to run? Are ConsoleKit and ConsoleKit-x11 installed?

Comment 2 Jason Montleon 2013-04-03 15:02:38 UTC
rpm -q ConsoleKit ConsoleKit-x11 lxdm
ConsoleKit-0.4.5-5.fc19.x86_64
ConsoleKit-x11-0.4.5-5.fc19.x86_64
lxdm-0.4.1-5.fc19.x86_64

I am trying to run Xfce. I have PREFERRED=startxfce4 in /etc/sysconfig/desktop and lxdm configured as the display manager via systemctl.

In the past this was sufficient to get things working, but it is no longer working.

Comment 3 Adam Williamson 2013-04-09 22:12:11 UTC
I see what may be this trying to boot the F19 Alpha LXDE live image: it boots to a completely blank screen.

https://bugzilla.redhat.com/show_bug.cgi?id=922935 happens if I don't pass enforcing=0 , ConsoleKit fails to start up. Passing enforcing=0 makes ConsoleKit start up. But still, system boots to a black screen.

I see the "create ConsoleKit session fail" error in lxdm.log. If I boot with enforcing=0 3 and then 'yum install ConsoleKit-x11' before doing 'systemctl isolate graphical.target', the error goes away - but it still results in a black screen.

I've tried both qxl/SPICE and cirrus/VNC in my VM, so I don't think that's the problem.

At this point I'm somewhat stuck, but hopefully this should be easy to reproduce, at least - just grab https://dl.fedoraproject.org/pub/alt/stage/19-Alpha-RC1/Live/x86_64/Fedora-Live-LXDE-x86_64-19-Alpha-1.iso (or a later build if one is available by the time you read this) and try to boot it. Then you can try the refinements above (enforcing=0 is probably a good one to use at minimum).

Nominating as a freeze exception bug on the basis that it's basically a showstopper for LXDE live spin, if what I'm seeing is the same as this bug.

Comment 4 Mamoru TASAKA 2013-04-14 06:27:43 UTC
Created attachment 735528 [details]
pstree log

I see this issue with my F-19 machine with testing repo enabled (not live) with lxdm (not with lightdm), with selinux fully _dis_abled.

pstree log (for my case) attached.

Comment 5 Mamoru TASAKA 2013-04-14 06:31:35 UTC
Created attachment 735529 [details]
ps auwwx & gdb

ps auwwx result and gdb log for attaching lxdm-binary

Looks like lxdm-binary is hanging at:

(gdb) up 9
#9  0x0804d612 in switch_user (pw=pw@entry=0x42a8cce0 <resbuf.9405>, run=0x84360b0 "/usr/bin/startlxde", 
    env=env@entry=0x843d510) at lxdm.c:987
987         g_spawn_command_line_sync ("/etc/lxdm/PreLogin",NULL,NULL,NULL,NULL);
(gdb) li
982         setenv("USER",pw->pw_name,1);
983         setenv("LOGNAME",pw->pw_name,1);
984         setenv("SHELL",pw->pw_shell,1);
985         setenv("HOME",pw->pw_dir,1);
986     
987         g_spawn_command_line_sync ("/etc/lxdm/PreLogin",NULL,NULL,NULL,NULL); <=========================
988     
989         if( !pw || initgroups(pw->pw_name, pw->pw_gid) ||
990             setgid(pw->pw_gid) || setuid(pw->pw_uid) || setsid() == -1 )
991             exit(EXIT_FAILURE);

i.e. g_spawn_command_line_sync does not return. https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1109251 may be similar issue (this also seems to be g_spawn_command_line_sync hanging).

Maybe better to ask glib2 maintainer for help.

Comment 6 Mamoru TASAKA 2013-04-14 06:34:14 UTC
[tasaka1@localhost ~]$ rpm -q lxdm glib2
lxdm-0.4.1-5.fc19.i686
glib2-2.36.0-1.fc19.i686

Comment 7 Vadim Raskhozhev 2013-05-02 08:02:24 UTC
Same here with F-19 upgraded from F-18 with yum distro-sync. lxdm-0.4.1-5.fc19.x86_64, glib2-2.36.1-1.fc19.x86_64, SELinux disabled.

Comment 8 Vadim Raskhozhev 2013-05-02 19:07:39 UTC
Updating glib2 to 2.36.1-2.fc19 fixed the bug for me.

Comment 9 Adam Williamson 2013-05-03 01:06:43 UTC
Huh. Really? The commit doesn't look particularly relevant:

Changelog 	* Sat Apr 27 2013 Thorsten Leemhuis <fedora> - 2.36.1-2 - Fix pidgin freezes by applying patch from master (#956872)

anyone else seen this magically resolved?

Comment 10 Jason Montleon 2013-05-03 03:14:07 UTC
Haven't tried yet, but see the from comment 5, "i.e. g_spawn_command_line_sync does not return. https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1109251 may be similar issue (this also seems to be g_spawn_command_line_sync hanging)."

There was a suspicion the same issue affecting pidgin was at fault here. It may have been the case.

Comment 11 Adam Williamson 2013-05-03 05:22:41 UTC
aha, I hadn't followed it that closely. makes sense in that case.

Comment 12 Mamoru TASAKA 2013-05-03 08:16:29 UTC
Yeah, confirmed that this bug still remains with glib2-2.36.1-1.fc19.i686, but is not reproducible with glib2-2.36.1-2.fc19.

With glib2-2.36.1-1.fc19.i686 lxdm-binary still hangs at g_spawn_command_line_sync(), glib2-2.36.1-2.fc19 change is actually to fix https://bugzilla.gnome.org/show_bug.cgi?id=698081 (Pidgin hangs in g_spawn_command_line_sync). So I think this is the same issue.

Comment 13 Fedora Update System 2013-05-03 08:25:03 UTC
glib2-2.36.1-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/FEDORA-2013-7106/glib2-2.36.1-2.fc19

Comment 14 Jan Pokorný [poki] 2013-05-03 18:53:53 UTC
Works for me, too.

Comment 15 Adam Williamson 2013-05-03 22:41:35 UTC
Proposing this as a Beta freeze exception as we believe it's what's breaking LXDE live images. We can confirm this with TC3 if I ensure that update is pulled in.

Comment 16 Fedora Update System 2013-05-04 01:44:35 UTC
glib2-2.36.1-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 17 Mamoru TASAKA 2013-05-04 13:31:35 UTC
Reopening to check if this bug is really fixed with (coming) TC3
live image or so. If we can confirm that this bug is not reproducible
with coming TC3, I think this bug can really be closed.

Comment 18 Vadim Raskhozhev 2013-05-06 19:08:11 UTC
Just checked http://dl.fedoraproject.org/pub/alt/stage/19-Beta-TC3/Live/x86_64/Fedora-Live-LXDE-x86_64-19-Beta-TC3-1.iso. LXDE session runs OK, so I think we can close this bug FIXED.

Comment 19 Adam Williamson 2013-05-06 19:52:13 UTC
Thanks.


Note You need to log in before you can comment on or make changes to this bug.