emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: GNU bug Tracking System
Subject: bug#44944: closed (Unable to log into X session via gdm)
Date: Fri, 16 Sep 2022 21:05:02 +0000

Your message dated Fri, 16 Sep 2022 17:03:50 -0400
with message-id <87k063jakp.fsf@gmail.com>
and subject line Re: bug#44944: Unable to log into X session via gdm
has caused the debbugs.gnu.org bug report #44944,
regarding Unable to log into X session via gdm
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
44944: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44944
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: Unable to log into X session via gdm Date: Sun, 29 Nov 2020 14:02:40 +0100
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: pgpmetNDegTWQ.pgp
Description: OpenPGP digital signature


--- End Message ---
--- Begin Message --- Subject: Re: bug#44944: Unable to log into X session via gdm Date: Fri, 16 Sep 2022 17:03:50 -0400 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux)
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


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]