Hey Tim,
>> Turns out that the problem was with a stale /var/lib/gdm – which makes >> me wonder: we do we have this at all? “/var/lib/gdm” is the “gdm” user >> account’s home directory. But it’s not like this really needs to be >> persistent, I think. >> >> I moved it out of the way and the gdm login prompt appeared within a few >> seconds. After restarting xorg-server the directory was recreated. >> >> Now, I *still* cannot actually log in, but the problem is likely very >> similar. >> >> [two minutes pass] >> >> Yup, after moving /home/rekado/.cache out of the way, everything is fine >> and I can log in. >> >> What should we do about this? For gdm I think it would make sense to >> add an activation service extension that clears the gdm user’s home >> directory. And more generally, maybe we should offer a generic cache >> cleaner service. >> >> Thoughts? > > I had a similar issue where the UID of the “gdm” user had changed > between reconfigures. I think it happened because I removed the GDM > service for a while and then brought it back. It took me a while to > figure it out, because of course everything looks fine at first glance. > However, GDM could no longer access “/var/lib/gdm”, and I had to remove > it to fix the problem. > > The X.org logs all end up in that directory, so it might a little > frustrating for someone having X.org issues if we delete that directory > all the time. I don’t remember if they get copied anywhere else. Can we cause the logs to be put in /var/log with all the other logs? > Maybe it would make more sense to delete the “/var/lib/gdm/.cache” > folder and ensure the permissions of the rest of it in an activation > script. WDYT? That would work, too, though the .local directory (this time in my own user’s home directory) has proven to be harmful in my past work on GNOME upgrades. -- Ricardo
