Efraim Flashner <[email protected]> writes:
> On Sun, Aug 04, 2019 at 11:00:41PM +0200, Ricardo Wurmus wrote: >> Hi Guix, >> >> Today I again couldn’t log into my workstation after upgrading the >> system. I’m using GDM + GNOME Shell. >> >> At first GDM wouldn’t start. I knew what to do: remove /var/lib/gdm, >> because some state must have accumulated there. > > For this one can we create a single-shot service that, on reconfigure or > boot, removes this directory and recreates it? In fact, it seems this is > basically what Debian does¹. I suggested as much earlier, but it seems like a hack. Is this how GNOME expects this state directory to be handled? The fact that Debian does this is reassuring (or not…), but I would very much like to avoid adding even more hacks. >> GDM came up after a reboot, but I still couldn’t log in. Instead I was >> thrown back to the login screen without any error message. I looked in >> ~/.cache/gdm/session.log for information, but it only told me that >> gnome-shell was killed. Thanks. >> >> After removing both .local/share and .cache out of the way I could log >> in again. > > This part seems a little harder to automate. /etc/skel is only sourced > when a user is created, so it's hard to make sweeping changes to help > people in this case, if they even want automated help. I'm guessing > making .cache/gdm(?) read-only would create other issues. Does anyone know why this happens at all? What are the cached data? Can we do without? >> What can we do to make GDM and GNOME Shell more reliable? > > Modify the logout scripts to remove a users' .cache file seems extreme. > Some of the other options, such as removing and recreating directories > would address other issues we've had (such as /var/cache/fontconfig). In my opinion generating a global /var/cache/fontconfig should be prevented; removing it seems again like an avoidable hack. -- Ricardo
