Package: guix;
Reported by: Danny Milosavljevic <dannym <at> scratchpost.org>
Date: Sun, 29 Nov 2020 13:03:01 UTC
Severity: normal
Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 44944 in the body.
You can then email your comments to 44944 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-guix <at> gnu.org:bug#44944; Package guix.
(Sun, 29 Nov 2020 13:03:01 GMT) Full text and rfc822 format available.Danny Milosavljevic <dannym <at> scratchpost.org>:bug-guix <at> gnu.org.
(Sun, 29 Nov 2020 13:03:01 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Danny Milosavljevic <dannym <at> scratchpost.org> To: <bug-guix <at> gnu.org> Subject: Unable to log into X session via gdm Date: Sun, 29 Nov 2020 14:02:40 +0100
[Message part 1 (text/plain, inline)]
The latest guix system reconfigure (of yesterday) left me unable to login into my X session. guix system rollback DID NOT fix it. I would enter my password and it would "try" to login and return right back to the gdm login screen. I've since removed gdm from my OS configuration (because I have to do actual *work* on this computer), but I think it would have been enough to just chown /var/lib/gdm and rm ~/.xsession-errors (!) in order to make it work again. Does that mean that user ids are non-reproducible? Why not have user_id = hash(user_name) ? Then they *are* reproducible. (I've tried finding the spot where those user accounts are generated/updated but so far have been unable to) Anyway, this is just to record the problem and workaround. I won't do further research on this problem on it on this computer. The "gdm" system account is gone by now because I've removed gdm from the OS configuration--and I don't plan on adding it ever again. For reference, in order to remove gdm from the system configuration in /etc/config.scm, do: (1) Replace %desktop-services by (remove (lambda (service) (eq? (service-kind service) gdm-service-type)) %desktop-services) (2) Add (service slim-service-type) to SERVICES in /etc/config.scm (3) guix system reconfigure /etc/config.scm
[Message part 2 (application/pgp-signature, inline)]
bug-guix <at> gnu.org:bug#44944; Package guix.
(Sun, 29 Nov 2020 17:01:02 GMT) Full text and rfc822 format available.Message #8 received at 44944 <at> debbugs.gnu.org (full text, mbox):
From: Marius Bakke <marius <at> gnu.org> To: Danny Milosavljevic <dannym <at> scratchpost.org>, 44944 <at> debbugs.gnu.org Subject: Re: bug#44944: Unable to log into X session via gdm Date: Sun, 29 Nov 2020 18:00:44 +0100
[Message part 1 (text/plain, inline)]
Danny Milosavljevic <dannym <at> scratchpost.org> skriver: > The latest guix system reconfigure (of yesterday) left me unable to login into > my X session. guix system rollback DID NOT fix it. > > I would enter my password and it would "try" to login and return right back to > the gdm login screen. Can you find any clues in the log files as to why this happened? Did you reboot after reconfiguring?
[signature.asc (application/pgp-signature, inline)]
bug-guix <at> gnu.org:bug#44944; Package guix.
(Sun, 29 Nov 2020 21:21:02 GMT) Full text and rfc822 format available.Message #11 received at 44944 <at> debbugs.gnu.org (full text, mbox):
From: Danny Milosavljevic <dannym <at> scratchpost.org> To: Marius Bakke <marius <at> gnu.org> Cc: 44944 <at> debbugs.gnu.org Subject: Re: bug#44944: Unable to log into X session via gdm Date: Sun, 29 Nov 2020 22:20:20 +0100
[Message part 1 (text/plain, inline)]
Hi, On Sun, 29 Nov 2020 18:00:44 +0100 Marius Bakke <marius <at> gnu.org> wrote: > Danny Milosavljevic <dannym <at> scratchpost.org> skriver: > > > The latest guix system reconfigure (of yesterday) left me unable to login into > > my X session. guix system rollback DID NOT fix it. > > > > I would enter my password and it would "try" to login and return right back to > > the gdm login screen. > > Can you find any clues in the log files as to why this happened? I did check, but there were not really good clues in the logs, among other things because it seemed that ~/.xsession-errors did not get updated. ls did report that ~/.xsession-errors belongs to me, but it still didn't update it, which is why I then removed it. But I only did that after removing gdm as well, so I don't know whether removing gdm or removing ~/.xsession-errors or both fixed it. Checking the logs again, I have only this interesting line: >Nov 29 04:24:26 localhost gdm: GdmDisplay: Session never registered, failing > Did you reboot after reconfiguring? I had selected the older system generation in the grub boot menu.
[Message part 2 (application/pgp-signature, inline)]
bug-guix <at> gnu.org:bug#44944; Package guix.
(Fri, 16 Sep 2022 19:01:02 GMT) Full text and rfc822 format available.Message #14 received at 44944 <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: Danny Milosavljevic <dannym <at> scratchpost.org> Cc: 44944 <at> debbugs.gnu.org Subject: Re: bug#44944: Unable to log into X session via gdm Date: Fri, 16 Sep 2022 15:00:22 -0400
Hi, Danny Milosavljevic <dannym <at> scratchpost.org> writes: > The latest guix system reconfigure (of yesterday) left me unable to login into > my X session. guix system rollback DID NOT fix it. > > I would enter my password and it would "try" to login and return right back to > the gdm login screen. > > I've since removed gdm from my OS configuration (because I have to do actual > *work* on this computer), but I think it would have been enough to just > chown /var/lib/gdm and rm ~/.xsession-errors (!) in order to make it work > again. > > Does that mean that user ids are non-reproducible? > > Why not have user_id = hash(user_name) ? Then they *are* reproducible. That'd be cool, but how would you implement such a hash, that returns something fixed between 0 and 1024? That doesn't sound feasible, although I'm no hash function expert. > (I've tried finding the spot where those user accounts are generated/updated > but so far have been unable to) > > Anyway, this is just to record the problem and workaround. I won't do > further research on this problem on it on this computer. > > The "gdm" system account is gone by now because I've removed gdm from the > OS configuration--and I don't plan on adding it ever again. I experienced the exact same problem as you. My topmost /var/lib/gdm directory has the correct permissions, but it contains stale entries that were created in the past by a different GDM user whose ID is no longer the same: --8<---------------cut here---------------start------------->8--- /var/lib/gdm: total 616 drwx------ 1 gdm gdm 46 Sep 16 09:09 . drwxr-xr-x 1 root root 222 May 7 20:40 .. drwxr-xr-x 1 nixbld04 opendht 62 Dec 7 2021 .cache drwx------ 1 nixbld04 opendht 44 Dec 7 2021 .config -rw------- 1 955 gdm 1146880 Sep 16 09:09 core drwxr-xr-x 1 nixbld04 opendht 10 Dec 7 2021 .local /var/lib/gdm/.cache: total 0 drwxr-xr-x 1 nixbld04 opendht 62 Dec 7 2021 . drwx------ 1 gdm gdm 46 Sep 16 09:09 .. drwxr-xr-x 1 nixbld04 opendht 384 Dec 7 2021 fontconfig drwxr-xr-x 1 nixbld04 opendht 6 Dec 7 2021 ibus drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 mesa_shader_cache /var/lib/gdm/.cache/fontconfig: total 84 drwxr-xr-x 1 nixbld04 opendht 384 Dec 7 2021 . drwxr-xr-x 1 nixbld04 opendht 62 Dec 7 2021 .. -rw-r--r-- 1 nixbld04 opendht 18496 Dec 7 2021 23ef510a04af7dd5ac1a2dbd06c4afd1-le64.cache-7 -rw-r--r-- 1 nixbld04 opendht 272 Dec 7 2021 269249ae71e4e445ff7f16f21dcb6de5-le64.cache-7 -rw-r--r-- 1 nixbld04 opendht 256 Dec 7 2021 50fa4f3b9c91fead50cbfcdae3296c45-le64.cache-7 -rw-r--r-- 1 nixbld04 opendht 50584 Dec 7 2021 a927202dec7f348d7a0569dcad9f19a8-le64.cache-7 -rw-r--r-- 1 nixbld04 opendht 200 Dec 7 2021 CACHEDIR.TAG /var/lib/gdm/.cache/ibus: total 0 drwxr-xr-x 1 nixbld04 opendht 6 Dec 7 2021 . drwxr-xr-x 1 nixbld04 opendht 62 Dec 7 2021 .. drwxr-xr-x 1 nixbld04 opendht 16 Dec 7 2021 bus /var/lib/gdm/.cache/ibus/bus: total 172 drwxr-xr-x 1 nixbld04 opendht 16 Dec 7 2021 . drwxr-xr-x 1 nixbld04 opendht 6 Dec 7 2021 .. -rw-r--r-- 1 nixbld04 opendht 173300 Dec 7 2021 registry /var/lib/gdm/.cache/mesa_shader_cache: total 36 drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 . drwxr-xr-x 1 nixbld04 opendht 62 Dec 7 2021 .. drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 02 drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 72 drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 88 drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 a3 drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 c4 drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 f9 -rw-r--r-- 1 nixbld04 opendht 1310728 Dec 7 2021 index /var/lib/gdm/.cache/mesa_shader_cache/02: total 4 drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 . drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 .. -rw-r--r-- 1 nixbld04 opendht 868 Dec 7 2021 f0edfe0ef96096640b39ff4d2786b503a60a43 /var/lib/gdm/.cache/mesa_shader_cache/72: total 4 drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 . drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 .. -rw-r--r-- 1 nixbld04 opendht 989 Dec 7 2021 7cd650943c7a3136f424df6a67c7897f922307 /var/lib/gdm/.cache/mesa_shader_cache/88: total 4 drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 . drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 .. -rw-r--r-- 1 nixbld04 opendht 755 Dec 7 2021 d03ceaeebc55f4b3c972e855775b2c21381b60 /var/lib/gdm/.cache/mesa_shader_cache/a3: total 4 drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 . drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 .. -rw-r--r-- 1 nixbld04 opendht 1187 Dec 7 2021 2d688084f93805f8921dab8d7a8de5e0f1bc66 /var/lib/gdm/.cache/mesa_shader_cache/c4: total 4 drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 . drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 .. -rw-r--r-- 1 nixbld04 opendht 523 Dec 7 2021 93ffa46c262472c8d01161a581304a790b71ff /var/lib/gdm/.cache/mesa_shader_cache/f9: total 4 drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 . drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 .. -rw-r--r-- 1 nixbld04 opendht 742 Dec 7 2021 14f5ad63c0e5edcc46473d056d0b5e38415f99 /var/lib/gdm/.config: total 0 drwx------ 1 nixbld04 opendht 44 Dec 7 2021 . drwx------ 1 gdm gdm 46 Sep 16 09:09 .. drwx------ 1 nixbld04 opendht 26 Dec 7 2021 gnome-session drwx------ 1 nixbld04 opendht 6 Dec 7 2021 ibus drwx------ 1 nixbld04 opendht 500 Dec 7 2021 pulse /var/lib/gdm/.config/gnome-session: total 0 drwx------ 1 nixbld04 opendht 26 Dec 7 2021 . drwx------ 1 nixbld04 opendht 44 Dec 7 2021 .. drwx------ 1 nixbld04 opendht 0 Dec 7 2021 saved-session /var/lib/gdm/.config/gnome-session/saved-session: total 0 drwx------ 1 nixbld04 opendht 0 Dec 7 2021 . drwx------ 1 nixbld04 opendht 26 Dec 7 2021 .. /var/lib/gdm/.config/ibus: total 0 drwx------ 1 nixbld04 opendht 6 Dec 7 2021 . drwx------ 1 nixbld04 opendht 44 Dec 7 2021 .. drwx------ 1 nixbld04 opendht 78 Dec 8 2021 bus /var/lib/gdm/.config/ibus/bus: total 4 drwx------ 1 nixbld04 opendht 78 Dec 8 2021 . drwx------ 1 nixbld04 opendht 6 Dec 7 2021 .. -rw-r--r-- 1 nixbld04 opendht 380 Dec 8 2021 c096feaf19ce3a0a450915775e7ec8e3-unix-0 /var/lib/gdm/.config/pulse: total 64 drwx------ 1 nixbld04 opendht 500 Dec 7 2021 . drwx------ 1 nixbld04 opendht 44 Dec 7 2021 .. -rw------- 1 nixbld04 opendht 36864 Dec 7 2021 c096feaf19ce3a0a450915775e7ec8e3-card-database.tdb -rw------- 1 nixbld04 opendht 1 Dec 8 2021 c096feaf19ce3a0a450915775e7ec8e3-default-sink -rw------- 1 nixbld04 opendht 1 Dec 8 2021 c096feaf19ce3a0a450915775e7ec8e3-default-source -rw------- 1 nixbld04 opendht 12288 Dec 8 2021 c096feaf19ce3a0a450915775e7ec8e3-device-volumes.tdb -rw------- 1 nixbld04 opendht 696 Dec 7 2021 c096feaf19ce3a0a450915775e7ec8e3-stream-volumes.tdb -rw------- 1 nixbld04 opendht 256 Dec 7 2021 cookie /var/lib/gdm/.local: total 0 drwxr-xr-x 1 nixbld04 opendht 10 Dec 7 2021 . drwx------ 1 gdm gdm 46 Sep 16 09:09 .. drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 share /var/lib/gdm/.local/share: total 0 drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 . drwxr-xr-x 1 nixbld04 opendht 10 Dec 7 2021 .. drwx------ 1 nixbld04 opendht 0 Dec 7 2021 applications drwx------ 1 nixbld04 opendht 0 Dec 7 2021 gnome-shell drwxr-xr-x 1 nixbld04 opendht 82 Dec 7 2021 icc drwx------ 1 nixbld04 opendht 0 Dec 7 2021 sounds drwxr-xr-x 1 nixbld04 opendht 96 Dec 8 2021 xorg /var/lib/gdm/.local/share/applications: total 0 drwx------ 1 nixbld04 opendht 0 Dec 7 2021 . drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 .. /var/lib/gdm/.local/share/gnome-shell: total 0 drwx------ 1 nixbld04 opendht 0 Dec 7 2021 . drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 .. /var/lib/gdm/.local/share/icc: total 4 drwxr-xr-x 1 nixbld04 opendht 82 Dec 7 2021 . drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 .. -rw-r--r-- 1 nixbld04 opendht 1448 Dec 7 2021 edid-5add33c88281761e832ba5f60ec1628e.icc /var/lib/gdm/.local/share/sounds: total 0 drwx------ 1 nixbld04 opendht 0 Dec 7 2021 . drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 .. /var/lib/gdm/.local/share/xorg: total 132 drwxr-xr-x 1 nixbld04 opendht 96 Dec 8 2021 . drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 .. -rw-r--r-- 1 nixbld04 opendht 52932 Dec 8 2021 Xorg.0.log -rw-r--r-- 1 nixbld04 opendht 53878 Dec 8 2021 Xorg.0.log.old -rw-r--r-- 1 nixbld04 opendht 10481 Dec 8 2021 Xorg.1.log -rw-r--r-- 1 nixbld04 opendht 10481 Dec 8 2021 Xorg.1.log.old --8<---------------cut here---------------end--------------->8--- We have some logic in %gdm-activation that was supposed to fix that, but it doesn't kick in, because it has some optimization to not recurse if the top dir has the correct permissions, and since d429878daf3 the top directory permissions are always controlled at system activation time (and this must happen before the gdm activation script runs). I'll follow-up with a patch that puts /var/lib/gdm on a tmpfs. This should avoid many pitfalls people have had. Thanks, Maxim
Maxim Cournoyer <maxim.cournoyer <at> gmail.com>:Danny Milosavljevic <dannym <at> scratchpost.org>:Message #19 received at 44944-done <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: Danny Milosavljevic <dannym <at> scratchpost.org> Cc: 44944-done <at> debbugs.gnu.org Subject: Re: bug#44944: Unable to log into X session via gdm Date: Fri, 16 Sep 2022 17:03:50 -0400
Hi, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes: [...] > /var/lib/gdm/.local/share/xorg: > total 132 > drwxr-xr-x 1 nixbld04 opendht 96 Dec 8 2021 . > drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 .. > -rw-r--r-- 1 nixbld04 opendht 52932 Dec 8 2021 Xorg.0.log > -rw-r--r-- 1 nixbld04 opendht 53878 Dec 8 2021 Xorg.0.log.old > -rw-r--r-- 1 nixbld04 opendht 10481 Dec 8 2021 Xorg.1.log > -rw-r--r-- 1 nixbld04 opendht 10481 Dec 8 2021 Xorg.1.log.old > > We have some logic in %gdm-activation that was supposed to fix that, but > it doesn't kick in, because it has some optimization to not recurse if > the top dir has the correct permissions, and since d429878daf3 the top > directory permissions are always controlled at system activation time > (and this must happen before the gdm activation script runs). > > I'll follow-up with a patch that puts /var/lib/gdm on a tmpfs. This > should avoid many pitfalls people have had. Pushed as d7e56aebec. This should fix the issue for good! Closing. Maxim
bug-guix <at> gnu.org:bug#44944; Package guix.
(Tue, 20 Sep 2022 14:51:01 GMT) Full text and rfc822 format available.Message #22 received at 44944 <at> debbugs.gnu.org (full text, mbox):
From: bokr <at> bokr.com To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> Cc: Danny Milosavljevic <dannym <at> scratchpost.org>, 44944 <at> debbugs.gnu.org Subject: Re: bug#44944: Unable to log into X session via gdm Date: Tue, 20 Sep 2022 16:49:57 +0200
Hi Maxim, On +2022-09-16 15:00:22 -0400, Maxim Cournoyer wrote: > Hi, > > Danny Milosavljevic <dannym <at> scratchpost.org> writes: > > > The latest guix system reconfigure (of yesterday) left me unable to login into > > my X session. guix system rollback DID NOT fix it. > > > > I would enter my password and it would "try" to login and return right back to > > the gdm login screen. > > > > I've since removed gdm from my OS configuration (because I have to do actual > > *work* on this computer), but I think it would have been enough to just > > chown /var/lib/gdm and rm ~/.xsession-errors (!) in order to make it work > > again. > > > > Does that mean that user ids are non-reproducible? > > > > Why not have user_id = hash(user_name) ? Then they *are* reproducible. > > That'd be cool, but how would you implement such a hash, that returns > something fixed between 0 and 1024? That doesn't sound feasible, > although I'm no hash function expert. > To "return something fixed between 0 and 1024" (1023?) In a context with less than 1024 users, couldn't one wrap Danny's "hash(username)" with a local function that finds a 0..1023 index into a trusted table of hash(username) values represented as string lines? Similar to the idea of representing 32-bit sRGB 16-million-colors+transparency with an 8-bit pallette index -- or even a 1-bit index for fg/bg alternates to black/white. BTW, for the unlimited-number-of-users case, what sets the 1024 range limit? > > (I've tried finding the spot where those user accounts are generated/updated > > but so far have been unable to) > > > > Anyway, this is just to record the problem and workaround. I won't do > > further research on this problem on it on this computer. > > > > The "gdm" system account is gone by now because I've removed gdm from the > > OS configuration--and I don't plan on adding it ever again. > > I experienced the exact same problem as you. My topmost /var/lib/gdm > directory has the correct permissions, but it contains stale entries > that were created in the past by a different GDM user whose ID is no > longer the same: > > --8<---------------cut here---------------start------------->8--- > /var/lib/gdm: > total 616 > drwx------ 1 gdm gdm 46 Sep 16 09:09 . > drwxr-xr-x 1 root root 222 May 7 20:40 .. > drwxr-xr-x 1 nixbld04 opendht 62 Dec 7 2021 .cache > drwx------ 1 nixbld04 opendht 44 Dec 7 2021 .config > -rw------- 1 955 gdm 1146880 Sep 16 09:09 core > drwxr-xr-x 1 nixbld04 opendht 10 Dec 7 2021 .local > > /var/lib/gdm/.cache: > total 0 > drwxr-xr-x 1 nixbld04 opendht 62 Dec 7 2021 . > drwx------ 1 gdm gdm 46 Sep 16 09:09 .. > drwxr-xr-x 1 nixbld04 opendht 384 Dec 7 2021 fontconfig > drwxr-xr-x 1 nixbld04 opendht 6 Dec 7 2021 ibus > drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 mesa_shader_cache > > /var/lib/gdm/.cache/fontconfig: > total 84 > drwxr-xr-x 1 nixbld04 opendht 384 Dec 7 2021 . > drwxr-xr-x 1 nixbld04 opendht 62 Dec 7 2021 .. > -rw-r--r-- 1 nixbld04 opendht 18496 Dec 7 2021 23ef510a04af7dd5ac1a2dbd06c4afd1-le64.cache-7 > -rw-r--r-- 1 nixbld04 opendht 272 Dec 7 2021 269249ae71e4e445ff7f16f21dcb6de5-le64.cache-7 > -rw-r--r-- 1 nixbld04 opendht 256 Dec 7 2021 50fa4f3b9c91fead50cbfcdae3296c45-le64.cache-7 > -rw-r--r-- 1 nixbld04 opendht 50584 Dec 7 2021 a927202dec7f348d7a0569dcad9f19a8-le64.cache-7 > -rw-r--r-- 1 nixbld04 opendht 200 Dec 7 2021 CACHEDIR.TAG > > /var/lib/gdm/.cache/ibus: > total 0 > drwxr-xr-x 1 nixbld04 opendht 6 Dec 7 2021 . > drwxr-xr-x 1 nixbld04 opendht 62 Dec 7 2021 .. > drwxr-xr-x 1 nixbld04 opendht 16 Dec 7 2021 bus > > /var/lib/gdm/.cache/ibus/bus: > total 172 > drwxr-xr-x 1 nixbld04 opendht 16 Dec 7 2021 . > drwxr-xr-x 1 nixbld04 opendht 6 Dec 7 2021 .. > -rw-r--r-- 1 nixbld04 opendht 173300 Dec 7 2021 registry > > /var/lib/gdm/.cache/mesa_shader_cache: > total 36 > drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 . > drwxr-xr-x 1 nixbld04 opendht 62 Dec 7 2021 .. > drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 02 > drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 72 > drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 88 > drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 a3 > drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 c4 > drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 f9 > -rw-r--r-- 1 nixbld04 opendht 1310728 Dec 7 2021 index > > /var/lib/gdm/.cache/mesa_shader_cache/02: > total 4 > drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 . > drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 .. > -rw-r--r-- 1 nixbld04 opendht 868 Dec 7 2021 f0edfe0ef96096640b39ff4d2786b503a60a43 > > /var/lib/gdm/.cache/mesa_shader_cache/72: > total 4 > drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 . > drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 .. > -rw-r--r-- 1 nixbld04 opendht 989 Dec 7 2021 7cd650943c7a3136f424df6a67c7897f922307 > > /var/lib/gdm/.cache/mesa_shader_cache/88: > total 4 > drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 . > drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 .. > -rw-r--r-- 1 nixbld04 opendht 755 Dec 7 2021 d03ceaeebc55f4b3c972e855775b2c21381b60 > > /var/lib/gdm/.cache/mesa_shader_cache/a3: > total 4 > drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 . > drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 .. > -rw-r--r-- 1 nixbld04 opendht 1187 Dec 7 2021 2d688084f93805f8921dab8d7a8de5e0f1bc66 > > /var/lib/gdm/.cache/mesa_shader_cache/c4: > total 4 > drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 . > drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 .. > -rw-r--r-- 1 nixbld04 opendht 523 Dec 7 2021 93ffa46c262472c8d01161a581304a790b71ff > > /var/lib/gdm/.cache/mesa_shader_cache/f9: > total 4 > drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 . > drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 .. > -rw-r--r-- 1 nixbld04 opendht 742 Dec 7 2021 14f5ad63c0e5edcc46473d056d0b5e38415f99 > > /var/lib/gdm/.config: > total 0 > drwx------ 1 nixbld04 opendht 44 Dec 7 2021 . > drwx------ 1 gdm gdm 46 Sep 16 09:09 .. > drwx------ 1 nixbld04 opendht 26 Dec 7 2021 gnome-session > drwx------ 1 nixbld04 opendht 6 Dec 7 2021 ibus > drwx------ 1 nixbld04 opendht 500 Dec 7 2021 pulse > > /var/lib/gdm/.config/gnome-session: > total 0 > drwx------ 1 nixbld04 opendht 26 Dec 7 2021 . > drwx------ 1 nixbld04 opendht 44 Dec 7 2021 .. > drwx------ 1 nixbld04 opendht 0 Dec 7 2021 saved-session > > /var/lib/gdm/.config/gnome-session/saved-session: > total 0 > drwx------ 1 nixbld04 opendht 0 Dec 7 2021 . > drwx------ 1 nixbld04 opendht 26 Dec 7 2021 .. > > /var/lib/gdm/.config/ibus: > total 0 > drwx------ 1 nixbld04 opendht 6 Dec 7 2021 . > drwx------ 1 nixbld04 opendht 44 Dec 7 2021 .. > drwx------ 1 nixbld04 opendht 78 Dec 8 2021 bus > > /var/lib/gdm/.config/ibus/bus: > total 4 > drwx------ 1 nixbld04 opendht 78 Dec 8 2021 . > drwx------ 1 nixbld04 opendht 6 Dec 7 2021 .. > -rw-r--r-- 1 nixbld04 opendht 380 Dec 8 2021 c096feaf19ce3a0a450915775e7ec8e3-unix-0 > > /var/lib/gdm/.config/pulse: > total 64 > drwx------ 1 nixbld04 opendht 500 Dec 7 2021 . > drwx------ 1 nixbld04 opendht 44 Dec 7 2021 .. > -rw------- 1 nixbld04 opendht 36864 Dec 7 2021 c096feaf19ce3a0a450915775e7ec8e3-card-database.tdb > -rw------- 1 nixbld04 opendht 1 Dec 8 2021 c096feaf19ce3a0a450915775e7ec8e3-default-sink > -rw------- 1 nixbld04 opendht 1 Dec 8 2021 c096feaf19ce3a0a450915775e7ec8e3-default-source > -rw------- 1 nixbld04 opendht 12288 Dec 8 2021 c096feaf19ce3a0a450915775e7ec8e3-device-volumes.tdb > -rw------- 1 nixbld04 opendht 696 Dec 7 2021 c096feaf19ce3a0a450915775e7ec8e3-stream-volumes.tdb > -rw------- 1 nixbld04 opendht 256 Dec 7 2021 cookie > > /var/lib/gdm/.local: > total 0 > drwxr-xr-x 1 nixbld04 opendht 10 Dec 7 2021 . > drwx------ 1 gdm gdm 46 Sep 16 09:09 .. > drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 share > > /var/lib/gdm/.local/share: > total 0 > drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 . > drwxr-xr-x 1 nixbld04 opendht 10 Dec 7 2021 .. > drwx------ 1 nixbld04 opendht 0 Dec 7 2021 applications > drwx------ 1 nixbld04 opendht 0 Dec 7 2021 gnome-shell > drwxr-xr-x 1 nixbld04 opendht 82 Dec 7 2021 icc > drwx------ 1 nixbld04 opendht 0 Dec 7 2021 sounds > drwxr-xr-x 1 nixbld04 opendht 96 Dec 8 2021 xorg > > /var/lib/gdm/.local/share/applications: > total 0 > drwx------ 1 nixbld04 opendht 0 Dec 7 2021 . > drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 .. > > /var/lib/gdm/.local/share/gnome-shell: > total 0 > drwx------ 1 nixbld04 opendht 0 Dec 7 2021 . > drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 .. > > /var/lib/gdm/.local/share/icc: > total 4 > drwxr-xr-x 1 nixbld04 opendht 82 Dec 7 2021 . > drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 .. > -rw-r--r-- 1 nixbld04 opendht 1448 Dec 7 2021 edid-5add33c88281761e832ba5f60ec1628e.icc > > /var/lib/gdm/.local/share/sounds: > total 0 > drwx------ 1 nixbld04 opendht 0 Dec 7 2021 . > drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 .. > > /var/lib/gdm/.local/share/xorg: > total 132 > drwxr-xr-x 1 nixbld04 opendht 96 Dec 8 2021 . > drwxr-xr-x 1 nixbld04 opendht 72 Dec 7 2021 .. > -rw-r--r-- 1 nixbld04 opendht 52932 Dec 8 2021 Xorg.0.log > -rw-r--r-- 1 nixbld04 opendht 53878 Dec 8 2021 Xorg.0.log.old > -rw-r--r-- 1 nixbld04 opendht 10481 Dec 8 2021 Xorg.1.log > -rw-r--r-- 1 nixbld04 opendht 10481 Dec 8 2021 Xorg.1.log.old > --8<---------------cut here---------------end--------------->8--- > > We have some logic in %gdm-activation that was supposed to fix that, but > it doesn't kick in, because it has some optimization to not recurse if > the top dir has the correct permissions, and since d429878daf3 the top > directory permissions are always controlled at system activation time > (and this must happen before the gdm activation script runs). > > I'll follow-up with a patch that puts /var/lib/gdm on a tmpfs. This > should avoid many pitfalls people have had. > > Thanks, > > Maxim > > > PS. WDYT.. (If there isn't a tool already available that'd make it easy to use the one-liners pro devs can concoct off the top of their heads :) ..of having a package that would install a script to output a reminder of stale-cache-items-in-general? It could e.g. be triggered on login by a user more than <some configured time> since last login, with output similar to guile's. As a model I notice guile seems to notice stale cached .go files, as demoed by: --8<---------------cut here---------------start------------->8--- $ cat is-this-stale_q #!/usr/bin/env -S guile -s !# (display "Test 1: is this stale??\n") --8<---------------cut here---------------end--------------->8--- --8<---------------cut here---------------start------------->8--- $ ./is-this-stale_q ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0 ;;; or pass the --no-auto-compile argument to disable. ;;; compiling /home/bokr/BS/bs20220919_2206/./is-this-stale_q ;;; compiled /home/bokr/.cache/guile/ccache/2.2-LE-8-3.A/home/bokr/BS/bs20220919_2206/is-this-stale_q.go Test 1: is this stale?? --8<---------------cut here---------------end--------------->8--- --8<---------------cut here---------------start------------->8--- $ ./is-this-stale_q Test 1: is this stale?? --8<---------------cut here---------------end--------------->8--- $ fg # back to emacs for mod: s/Test 1/Test 2/ emacs -nw is-this-stale_q --8<---------------cut here---------------start------------->8--- $ ./is-this-stale_q ;;; note: source file /home/bokr/BS/bs20220919_2206/./is-this-stale_q ;;; newer than compiled /home/bokr/.cache/guile/ccache/2.2-LE-8-3.A/home/bokr/BS/bs20220919_2206/is-this-stale_q.go ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0 ;;; or pass the --no-auto-compile argument to disable. ;;; compiling /home/bokr/BS/bs20220919_2206/./is-this-stale_q ;;; compiled /home/bokr/.cache/guile/ccache/2.2-LE-8-3.A/home/bokr/BS/bs20220919_2206/is-this-stale_q.go Test 2: is this stale?? --8<---------------cut here---------------end--------------->8--- --8<---------------cut here---------------start------------->8--- $ ./is-this-stale_q Test 2: is this stale?? --8<---------------cut here---------------end--------------->8---
bug-guix <at> gnu.org:bug#44944; Package guix.
(Thu, 22 Sep 2022 04:12:02 GMT) Full text and rfc822 format available.Message #25 received at 44944 <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: bokr <at> bokr.com Cc: Danny Milosavljevic <dannym <at> scratchpost.org>, 44944 <at> debbugs.gnu.org Subject: Re: bug#44944: Unable to log into X session via gdm Date: Thu, 22 Sep 2022 00:11:49 -0400
Hi, bokr <at> bokr.com writes: > Hi Maxim, > > On +2022-09-16 15:00:22 -0400, Maxim Cournoyer wrote: >> Hi, >> >> Danny Milosavljevic <dannym <at> scratchpost.org> writes: >> >> > The latest guix system reconfigure (of yesterday) left me unable to login into >> > my X session. guix system rollback DID NOT fix it. >> > >> > I would enter my password and it would "try" to login and return right back to >> > the gdm login screen. >> > >> > I've since removed gdm from my OS configuration (because I have to do actual >> > *work* on this computer), but I think it would have been enough to just >> > chown /var/lib/gdm and rm ~/.xsession-errors (!) in order to make it work >> > again. >> > >> > Does that mean that user ids are non-reproducible? >> > >> > Why not have user_id = hash(user_name) ? Then they *are* reproducible. >> >> That'd be cool, but how would you implement such a hash, that returns >> something fixed between 0 and 1024? That doesn't sound feasible, >> although I'm no hash function expert. >> > > To "return something fixed between 0 and 1024" (1023?) In a context > with less than 1024 users, couldn't one wrap Danny's "hash(username)" > with a local function that finds a 0..1023 index into a trusted table > of hash(username) values represented as string lines? I'm not sure I follow. If you had some pseudo-code, that might help me :-). > Similar to the idea of representing 32-bit sRGB 16-million-colors+transparency > with an 8-bit pallette index -- or even a 1-bit index for fg/bg alternates > to black/white. I'd need to read more deeply about the topic to understand, but I welcome mathematicians wizards to devise a cute little function to do that :-). > BTW, for the unlimited-number-of-users case, what sets the 1024 range limit? It's just a convention for "system" users, e.g. users typically not having a home directory, and perhaps other traits. It can differ between distributions. Some information about it here [0]. [0] https://unix.stackexchange.com/a/80279/82353 Thanks, Maxim
bug-guix <at> gnu.org:bug#44944; Package guix.
(Sun, 25 Sep 2022 11:48:01 GMT) Full text and rfc822 format available.Message #28 received at 44944 <at> debbugs.gnu.org (full text, mbox):
From: Maxime Devos <maximedevos <at> telenet.be> To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, Danny Milosavljevic <dannym <at> scratchpost.org> Cc: 44944 <at> debbugs.gnu.org Subject: Re: bug#44944: Unable to log into X session via gdm Date: Sun, 25 Sep 2022 13:47:15 +0200
[Message part 1 (text/plain, inline)]
On 16-09-2022 21:00, Maxim Cournoyer wrote:
> That'd be cool, but how would you implement such a hash, that returns
> something fixed between 0 and 1024? That doesn't sound feasible,
> although I'm no hash function expert.
Remember that any function from X to a finite set Y is a hash function
-- this included very simple ones like e.g. X={1,...,N}, Y={1,...,N},
map every number \(k\) to \(k\).
You can't implement such a hash without hash collisions, due to the
pigeonhole principle, as there are more inputs (user names) that outputs
(numbers between 0 and 1024).
Users can't share uids, so hash collisions are unacceptable.
As collisions are unacceptable (and not just tolerable but disliked),
the 'uniformity' property of some hash functions is unneeded.
If we limit ourselves to only having 1025 users in total, then with some
care there aren't any hash collisions (see proposal by bokr) (*), but
that would place a limit on how many services can be written for Guix.
Of course, an individual system might only have < 1025 users as not all
services are enabled, but then the hash function would depend on the
system in question. However, Guix cannot tell in advance what usernames
will be used in the future, so it would need to gradually build up its
hash function (state!) and remember old 'deleted' users (state!).
But if you have to remember the old users anyway and gradually build up
a hash function, then you might as well simplify things by not going for
a classically "good" hash function but rather a simple table that is
gradually build up (technically a hash function), as I've tried out in
<https://issues.guix.gnu.org/36508#21> (currently limited to uids, gid
not yet supported, also largely untested).
(*) Implementation:
(define (hash username)
(define %table
`(("root" . 0)
("foo" . 1)
("bar" . 2)
; <insert entries for all other (system) usernames in Guix here>
[...]))
(or (assoc-ref %table username)
(error "doesn't exist")))
Greetings,
Maxime.
[OpenPGP_0x49E3EE22191725EE.asc (application/pgp-keys, attachment)]
[OpenPGP_signature (application/pgp-signature, attachment)]
bug-guix <at> gnu.org:bug#44944; Package guix.
(Tue, 27 Sep 2022 00:13:01 GMT) Full text and rfc822 format available.Message #31 received at 44944 <at> debbugs.gnu.org (full text, mbox):
From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> To: Maxime Devos <maximedevos <at> telenet.be> Cc: Danny Milosavljevic <dannym <at> scratchpost.org>, 44944 <at> debbugs.gnu.org Subject: Re: bug#44944: Unable to log into X session via gdm Date: Mon, 26 Sep 2022 20:12:31 -0400
Hello,
Maxime Devos <maximedevos <at> telenet.be> writes:
> On 16-09-2022 21:00, Maxim Cournoyer wrote:
>> That'd be cool, but how would you implement such a hash, that returns
>> something fixed between 0 and 1024? That doesn't sound feasible,
>> although I'm no hash function expert.
>
> Remember that any function from X to a finite set Y is a hash function
> -- this included very simple ones like e.g. X={1,...,N}, Y={1,...,N},
> map every number \(k\) to \(k\).
[...]
> But if you have to remember the old users anyway and gradually build
> up a hash function, then you might as well simplify things by not
> going for a classically "good" hash function but rather a simple table
> that is gradually build up (technically a hash function), as I've
> tried out in <https://issues.guix.gnu.org/36508#21> (currently limited
> to uids, gid not yet supported, also largely untested).
>
> (*) Implementation:
>
> (define (hash username)
> (define %table
> `(("root" . 0)
> ("foo" . 1)
> ("bar" . 2)
> ; <insert entries for all other (system) usernames in Guix here>
> [...]))
> (or (assoc-ref %table username)
> (error "doesn't exist")))
Thanks for explaining. Thinking some more about it, it seems having
such a function would be of limited value after all: it'd only be useful
to avoid confusion about stale files ownership by avoiding to reuse any
user id used in the present or past; it wouldn't avoid having stale
files with the wrong ownership.
So the solution seems to instead be extra careful with removing as much
state as we can, and checking things in activation scripts. For GDM for
example I was able to put the /var/lib/gdm directory on a tmpfs which
gets reset on every reboot, which should help with this and other (stale
cache files) problem its service had.
Thanks,
Maxim
Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org.
(Tue, 25 Oct 2022 11:24:09 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.