From mboxrd@z Thu Jan 1 00:00:00 1970 From: Efraim Flashner Subject: Re: fixing GDM + GNOME Shell Date: Mon, 5 Aug 2019 10:17:19 +0300 Message-ID: <20190805071719.GB15819@E2140> References: <87tvawzlvq.fsf@elephly.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8P1HSweYDcXXzwPJ" Return-path: Content-Disposition: inline In-Reply-To: <87tvawzlvq.fsf@elephly.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ricardo Wurmus Cc: guix-devel@gnu.org, bug-guix@gnu.org List-Id: bug-guix.gnu.org --8P1HSweYDcXXzwPJ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 04, 2019 at 11:00:41PM +0200, Ricardo Wurmus wrote: > Hi Guix, >=20 > Today I again couldn=E2=80=99t log into my workstation after upgrading the > system. I=E2=80=99m using GDM + GNOME Shell. >=20 > At first GDM wouldn=E2=80=99t 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=C2=B9. >=20 > GDM came up after a reboot, but I still couldn=E2=80=99t 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. >=20 > 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. >=20 > This happens whenever I upgrade the system. This makes the system > rather frustrating to use. I don=E2=80=99t 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. >=20 > 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). =C2=B9 https://sources.debian.org/src/gdm3/3.30.2-3/debian/gdm3.postinst/#L= 76 --=20 Efraim Flashner =D7=90=D7=A4=D7=A8=D7=99=D7=9D = =D7=A4=D7=9C=D7=A9=D7=A0=D7=A8 GPG key =3D A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted --8P1HSweYDcXXzwPJ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAl1H1/IACgkQQarn3Mo9 g1G5VhAAsibD5ztLCeQoH3V8uNSGHhxreveiSAs1ZRB63xKot5+77Yc6dVWbfQOn FO+0kD4ltjlaD+FplwoR+3qBUzshx+Gs+5NJi6EJJfWlt6mM7mOpUlry3uVJ5iFA Y0lR9mw+xc2Yaj/oaXiimmncpGVs8aCqNM5lSugIuACL3e0JTOVX1Dzatuc1HW7+ DRrAIpnz+2Jwdf8n8lDBRVf6skJHh3cMKEWYxO/xRABeaAESjOxvWq8sB0TEpCSe bZdMjAUV9eoWE+gIPbqLjdAjBTHy69BKj6tRgn1meZCvQv1CsdVDkqJUVJJ1p9fm K5VjXij092gnXDGkdDYUm2B4loTYodwva45x5O5Eb7z12wq6+zCsYcD3Ir0+twFf hM2Q8ptCwVr55bpO48I8KpWkAJi8jn+RiDNro3BZK+IfOcHAusKdEqcdA3wEQzs0 99qkeTKbBa8sTAmI44lqYTrkrWg6mIeWXamgr0Xkb6bZM2YwkgdmsqhGFb1hs1uW dOhfBrULNBMMARMiFIR3Muurqo/pRVqR3V/4aK0a+y4XdmE7eab2dhQs9DwPjYLl WqaSF7X5XfLi7GQZKEzbZOEqH2D7e03zKKximVjkO/7wrGZ4qr17mC8k2/U6voEB Yw9Xwo3hacJHGLbwG/7k79yQ4lM9oR/H0mR3RcwqNoZ7NTwKJaY= =ZKzJ -----END PGP SIGNATURE----- --8P1HSweYDcXXzwPJ--