Hi Ricardo, Ricardo Wurmus <rek...@elephly.net> writes:
> 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. Taking a closer look, I see that stuff like whether the on-screen keyboard should be displayed gets saved there, too. 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? -- Tim
