Description of problem: after "yum update" my Fedora system, desktop manager can't start. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: workaround problem - after booting in runlevel 5, login to another terminal window by pressing ALT+F2, for example. When user enter login and password (this is not easy, because system is switching screen back to system tty time to time), then he must switch system to runlevel 3 (telinit 3 with root user privileges). switch back to user account and run XWindow system by typing "startx" in terminal. By the way - when we change runlevel, we need to restart crond daemon (/etc/init.d/crond stop/start), because it stop working after changing runlevel. [root@timelock andy]# chkconfig --list | grep crond crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off [root@timelock andy]#
Created attachment 467691 [details] messages file
Created attachment 467692 [details] lxdm log file
it looks like lxdm is calling X with bad options, so, lxdm bug? does it work if you switch to gdm? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Where are these options coming from? Did you start lxdm manually? Please give us the content of /etc/lxdm/lxdm.conf /etc/sysconfig/desktop Thanks in advance.
i don't try gdm yet, but thank you for your answer [andy@timelock ~]$ cat /etc/sysconfig/desktop PREFERRED=/usr/bin/startlxde DISPLAYMANAGER=/usr/sbin/lxdm [andy@timelock ~]$ cat /etc/lxdm/lxdm.conf cat: /etc/lxdm/lxdm.conf: Permission denied [andy@timelock ~]$ su - Password: [root@timelock ~]# cat /etc/lxdm/lxdm.conf [base] # autologin=dgod # session=/usr/bin/startlxde # numlock=0 greeter=/usr/libexec/lxdm-greeter-gtk [server] arg=/usr/bin/X -nr vt1 [display] gtk_theme=Clearlooks bg=/usr/share/backgrounds/default.png bottom_pane=1 lang=1 theme=Industrial [input] [userlist] disable=0 white= black= [root@timelock ~]#
Ok, lxdm.conf is fine. It looks you are running systemd, right? What happens if you comment out the line starting with arg=... ? Can you tell me what package versions you are using? rpm -q fedora-release lxdm systemd systemd-sysvinit systemd-utils
I'm using rawhide and yes, i'm using systemd. Version of packages: [andy@timelock ~]$ rpm -qa | egrep "(fedora-release|lxdm|systemd)" systemd-units-16-1.fc15.i686 fedora-release-notes-14.1.2-1.fc15.noarch systemd-16-1.fc15.i686 lxdm-0.3.0-2.fc15.i686 [andy@timelock ~]$ You want what I would comment out the line in the file /etc/lxdm/lxdm.conf in [server] stanza?
I saw lxdm login, when i'm comment out /etc/lxdm/lxdm.conf: [server] #arg=/usr/bin/X -nr vt1 but i can't log in, because, after i enter my login and password - lxdm displays login again and again (infinite loop).
Can you try with selinux in permissive mode just to be sure? Can you login in runlevel 3 and run LXDE with startlxde?
christoph: I just hit this bug testing something (I had to use lxdm as gdm in Rawhide live images appears to be broken). The bad -nr parameter is indeed in lxdm.conf out of the box - after a fresh install of lxdm - and it prevents lxdm from running. If I remove it from lxdm.conf, lxdm runs, and I could log in (I didn't hit the infinite loop Andy hit). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Thanks for testing, Adam. On which VT is LXDM starting? /me needs to set up a rawhide box...
honestly, I didn't check, I was at the end of my tether just trying to test the damn thing I was testing so once I got LXDM to start, I didn't investigate further =) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
what i'm need to do?
I just ran into this, and tested it. With the config file line changed to: arg=/usr/bin/X vt1 (That is, just remove the '-nr'), everything works fine and LXDM starts on vt1. `man Xorg` gives no mention of this `nr` option, but I found something about it here: http://www.mail-archive.com/xorg-devel@lists.x.org/msg09360.html, and further digging suggests it's something to do with "smooth Plymouth -> X transitions", which is of course little consolation if one is getting no login manager. So, uh, does someone know what it's supposed to do? I think the right thing is to not encode any fancy X options in per-display-manager config files, but may
changing the summary so we can find this damn thing better. I think what this is meant to do is tell X to start on vt1 (not vt7), which does indeed help with smooth plymouth -> LXDE transition, but it's hardly critical. I think if we can't figure out the correct form of the parameter in current X we should just drop it for now. This currently breaks the LXDE spin for F15 Alpha.
hum, actually, just the 'vt1' alone should do that. So I don't know what the -nr is for.
this has been changed in the last two upstream commits: http://lxde.git.sourceforge.net/git/gitweb.cgi?p=lxde/lxdm;a=history;f=data/lxdm.conf.in;h=7cb5f8747ad8e3494455d4979f54e9deee18771f;hb=HEAD I will commit the relevant changes to our lxdm and see if that fixes it.
lxdm-0.3.0-4.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/lxdm-0.3.0-4.fc15
if people could test and +1 the update it'd really help. I have tested it in a live image I built here and it worked fine.
After i'm removed "-nr" option, lxdm works fine. [andy@timelock tmp]$ rpm -qa | grep lxdm lxdm-0.3.0-3.fc15.i686 [andy@timelock tmp]$ But i have not tried "-background" option.
please just test by installing the updated package from updates-testing or koji and report success or failure to bodhi via the link above. thanks!
i'm downloaded package from link above, and installed this package in my system: [andy@timelock ~]$ rpm -qa | grep lxdm lxdm-0.3.0-4.fc15.i686 [andy@timelock ~]$ Problem solved, you may close this bug. Adam, Christoph, Matthew - thank you very much!
Is the new option working as intended, or should it be "-background none"? I also note that my existing config file got moved to .rpmsave, instead of getting an .rpmnew file. If I had configured other things (like autologin), I would have preferred that to be preserved.
New option working as "-background vt1" [root@timelock ~]# cat /etc/lxdm/lxdm.conf [base] # autologin=dgod # session=/usr/bin/startlxde # numlock=0 greeter=/usr/libexec/lxdm-greeter-gtk [server] arg=/usr/bin/X -background vt1 [display] gtk_theme=Clearlooks bg=/usr/share/backgrounds/default.png bottom_pane=1 lang=1 theme=Industrial [input] [userlist] disable=0 white= black= [root@timelock ~]#
matthew: just plain '-background' is what upstream has; I actually just re-diffed an upstream patch. If you run X with some garbage options, to see the help output, it shows: -background [none] create root window with no background the square brackets indicating the none is optional. X has a somewhat odd convention that the minus sign in some parameters is taken *literally* and means 'disable this' - so -background can be read 'minus background' and means 'disable the background'. See also -xinerama , for instance - you might think it means 'use xinerama', but you'd be dead wrong. =)
Okay, sounds good. I still think it should be config(noreplace), but that's a separate bug.
(In reply to comment #28) > Okay, sounds good. I still think it should be config(noreplace), but that's a > separate bug. In fact removing (noreplace) was the result of a another bug. We need to make sure that lxdm is operational after an update and we can only guarantee that with a new config file because the behavior of lxdm has changed quite often in the past. Sorry I have been so unresponsive in this bug, I'm just too busy with my dayjob. A big thanks to Adam for taking over!
+1 to including this as a nice-to-have (NTH) bug. This issue adheres to the NTH principles [1] [1] https://fedoraproject.org/wiki/QA:SOP_nth_bug_process#Nice-to-have_bug_principles
+1 to including as a HTH bug
thanks - can you push it through the freeze, then?
lxdm-0.3.0-4.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.