After upgrading gdm to 3.2.0 and then the current 3.2.1.1-r1 the login window doesn't come up. I see the switch on vt7 to the xserver, but the screen stays black and the wait cursor is visible forever. The problem is seen whether or not I emerge gdm with USE=gnome-shell. I'm using an ATI Radeon card and neither xf86-video-ati nor ati-drivers change the result (gnome-shell works with ati-drivers). In var/log/gdm I don't see :0-greeter.log, only :0-slave.log here its content: gdm-welcome][29581]: pam_unix(gdm-welcome:account): expired password for user gdm (root enforced) Moreover, /var/log/gdm/O.log is only about half of the size than with gdm-3.0.4-r1. I re-emerged xorg-server, dbus, dbus-glib, glib, gtk+, pam, pambase (original with USE=consolekit cracklib gnome-keyring sha512, I then added also mktemp pam_krb5 and pam_ssh) and the mentioned video-drivers and MESA I couldn't find anything related in the forums and in google Reproducible: Always
Created attachment 291339 [details] additional lines in :0.log not present when using gdm-3.0.4-r1 I diffed :0.log using gdm-3.2.1.1-r1 and gdm-3.0.4-r1. The attachment contains lines only present when using gdm-3.2.1.1-r1. If that's of help
> pam_unix(gdm-welcome:account): expired password for user gdm (root enforced) The gdm account should not have a password, and it certainly should not be set to expire. Try the following command: # passwd -d -x 99999 gdm
(In reply to comment #2) > > pam_unix(gdm-welcome:account): expired password for user gdm (root enforced) > > The gdm account should not have a password, and it certainly should not be set > to expire. Try the following command: > # passwd -d -x 99999 gdm I already deleted the passwd yesterday (but the setting was 99997) changing it to the values recommended did not help. Furthermore, I substituted every required by optional in /etc/pam.d/gdm and gdm-welcome, but that didn't help either.
Please attach /var/log/gdm/:0.log from the failing gdm, and give the output of "ps aux |grep gdm" after you see the wait cursor.
Created attachment 291375 [details] /var/log/gdm/:0.log
Created attachment 291377 [details] ps aux | grep gdm
Thanks. So it seems that X at least is launching successfully (although > (WW) RADEON(0): Direct rendering disabled > (EE) RADEON(0): Acceleration initialization failed might prevent you from using gnome-shell). However, gnome-session is either not being launched or is crashing. First, you need to figure out if gnome-session is being launched at all. Please try the following: # cp -p /usr/bin/gnome-session /usr/bin/gnome-session.bck # echo -e "#\041/bin/sh\necho 'XXX: starting gnome-session.bck'\n/usr/bin/gnome-session.bck --debug \"\$@\"" > /usr/bin/gnome-session then restart gdm and see if the 'XXX: starting gnome-session.bck' message appears in /var/log/gdm/ somewhere.
(In reply to comment #7) > Thanks. So it seems that X at least is launching successfully (although > > (WW) RADEON(0): Direct rendering disabled > > (EE) RADEON(0): Acceleration initialization failed > might prevent you from using gnome-shell). with xf86-video-ati gnome-shell is indeed not working - but it works with ati-drivers > However, gnome-session is either not > being launched or is crashing. It appears that it is not being launched at all. With gdm-3.0.4-r2 it is called directly after the dbus-daemon fork. > First, you need to figure out if gnome-session is being launched at all. Please > try the following: > # cp -p /usr/bin/gnome-session /usr/bin/gnome-session.bck > # echo -e "#\041/bin/sh\necho 'XXX: starting > gnome-session.bck'\n/usr/bin/gnome-session.bck --debug \"\$@\"" > > /usr/bin/gnome-session > > then restart gdm and see if the 'XXX: starting gnome-session.bck' message > appears in /var/log/gdm/ somewhere. Only with gdm-3.0.4 but not with 3.2.1.1 (and I re-emerged also gnome-session after the gdm-update.)
Created attachment 291547 [details] 0-slave.log with debug information There were some similar problems reported by Arch-Linux people. However, the solutions suggested there did not help yet. Anyway, I've attached now a :0-slave.log achieved after setting Enable=true in [debug] section of /etc/gdm/custom.conf. The output clearly shows that the authentication is the problem here. Within the output it is written in German that root has requested the user gdm to change his password. (a bit odd, because I run passwd as suggested to remove any password for gdm)
I tried "chage -E -1", but didn't help either. However, I finally succeeded by unmerging gdm removing every left-overs in /etc and /var, the did "userdel gdm", restarted the machine and remerged gdm-3.2.1.1-r1 and let the ebuild settle the uid and everything else. So, I close this bug
