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¹. > > 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. > > This happens whenever I upgrade the system. This makes the system > rather frustrating to use. I don’t know if booting into an older system > generation would result in the same problem, but my guess is that it > would because both GDM and GNOME Shell appear to be leaving some binary > files behind that cause different versions to crash unceremoneously. > > 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). ¹ https://sources.debian.org/src/gdm3/3.30.2-3/debian/gdm3.postinst/#L76 -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted