Description of problem: After booting the machine, an older version of the login screen appears and I am unable to log in to Gnome Shell. If I log in to "Gnome Classic", then log out, a newer version of the login screen appears. From this newer login screen, I can then log in to Gnome Shell. How reproducible: Always, on my hardware at least Steps to Reproduce: 1. Install Cauldron with Gnome and update 2. Reboot 3. Log In at "old" login screen, select Gnome Classic 4. Log out again - you will now see the "new" login screen 5. You can now log in to Gnome Shell I'm not sure how to take a screenshot of the login screen, but if someone can advise me on how to do this, I will attach them to this bug.
I'm not sure, but maybe a comment in another bug report is about not being able to log in to Gnome3, too https://bugs.mageia.org/show_bug.cgi?id=3863#c8 adding the reporter of that bug to the cc of this one also adding gnome maintainer
CC: (none) => marja11, olav, palm_pre_stl
I've been seeing the same, but only sometimes. I think there is a missing "dependency" on gdm, making it start too early. CC'ing Colin for that reason. If I go to a shell, log in as root and do: service gdm restart then gdm is correctly in "gnome-shell" mode instead of the crappy one.
Priority: Normal => release_blockerStatus: NEW => ASSIGNEDCC: (none) => mageiaTarget Milestone: --- => Mageia 2
Assignee: bugsquad => olav
Hmm, interesting. I've not seen this problem personally, but I can imagine what it would be - i.e. ACLs not applying early enough... typically it's the gdm-welcome pam.d file that should allow the gdm user to access the /dev/dri/* device nodes which in turn allows the gnome-shell version of gdm to work. Not quite sure how this could be an ordering problem however :s
Is this problem still happening currently ? I didn't experencied it myself for a while.
CC: (none) => guillomovitch
I've certainly never seen it. I suspect it can be closed, but I'll let maintainer or reporter decide on that.
(In reply to comment #4) > Is this problem still happening currently ? I didn't experience it myself for > a while. (In reply to comment #5) > I've certainly never seen it. I suspect it can be closed, but I'll let > maintainer or reporter decide on that. Thanks for the feed back :) Lowering priority @ Andrew @ Olav Have you still experienced this problem recently in updated cauldron
Keywords: (none) => NEEDINFOPriority: release_blocker => High
I cannot reproduce this anymore, however my system always seems to want to "auto login" at boot time, even though in System Settings -> User Accounts I have Automatic Login disabled for both the "Guest" user and the only other user on the system. I'd really like to see it boot into the log in screen, and let me type my credentials before I'm happy to say it's resolved. Any ideas where else I need to go to stop the auto-login behaviour?
@Andrew, check /etc/sysconfig/autologin file. Set AUTOLOGIN=no. You are adjusting the KDE only version of autologin, but it could also be set at a lower level. You should also be able to use drakconf to configure this. If in doubt, remove the autologin package. I'll close this bug for admin purposes, but feel free to ask another question if you get stuck :)
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
@Colin - thanks for the suggestion. I have edited /etc/sysconfig/autologin as your suggested and changed AUTOLOGIN=yes to AUTOLOGIN=no. Unfortunately it has made no difference. I then checked (using rpm -qa | grep autologin) and the autologin package was not installed. So I installed it, but still it has made no difference. Should I file another bug report for this? Please let me know if it's better to discuss this somewhere else - I don't want to mess up this particular issue with comments about something else.
Update on last comment - changing /etc/X11/gdm/custom.conf to have: AutomaticLoginEnable=false has stopped the autologin behaviour
OK, so you are in the strange situation that you were using GDM as a login manager, but running KDE and editing autologin settings for KDM. This is why things didn't really work for you but as there is no mystery here (just confusion - and it would be good to solve eventually) I think we can leave this one.
Actually, I take that last comment back, I was thinking KDE's systemsettings not GNOME's This could be a problem, if you would like to test it further (i.e. use the GUI to enable it, check it works, then disable it again and make sure it's disabled). If this is broken, then please open a new bug :)