bug#44944: Unable to log into X session via gdm

bug#44944: Unable to log into X session via gdm

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#44944: Unable to log into X session via gdm

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

Danny Milosavljevic <dannym@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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

bug#44944: Unable to log into X session via gdm

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 1137 bytes --]

Hi,

On Sun, 29 Nov 2020 18:00:44 +0100
Marius Bakke <marius@gnu.org> wrote:

> Danny Milosavljevic <dannym@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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#44944: Unable to log into X session via gdm

[Maxim Cournoyer]

Hi,

Danny Milosavljevic <dannym@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

bug#44944: Unable to log into X session via gdm

[Maxim Cournoyer]

Hi,

Maxim Cournoyer <maxim.cournoyer@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#44944: Unable to log into X session via gdm

[bokr]

Hi Maxim,

On +2022-09-16 15:00:22 -0400, Maxim Cournoyer wrote:
> Hi,
> 
> Danny Milosavljevic <dannym@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#44944: Unable to log into X session via gdm

[Maxim Cournoyer]

Hi,

bokr@bokr.com writes:

> Hi Maxim,
>
> On +2022-09-16 15:00:22 -0400, Maxim Cournoyer wrote:
>> Hi,
>> 
>> Danny Milosavljevic <dannym@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#44944: Unable to log into X session via gdm

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 2097 bytes --]



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.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

bug#44944: Unable to log into X session via gdm

[Maxim Cournoyer]

Hello,

Maxime Devos <maximedevos@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