GNU bug report logs - #40652
GDM does not starts after April 10 system reconfigure

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 40652 in the body.
You can then email your comments to 40652 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: R Veera Kumar <vkor <at> vkten.in>
To: bug-guix <at> gnu.org
Subject: GDM does not starts after April 10 system reconfigure
Date: Thu, 16 Apr 2020 05:50:20 +0530

I am using guix.git master branch.

I did guix system reconfigure on April 10 with gnome, mate, xfce and enlightenment service-types.
It was working. And next day I again did that and gdm does not starts anymore.

Initial console says:

New session c1 of user gdm.
Removed session c1.


/var/log/messages says:

gdm: Child process -325 was already dead.


/var/log/gdm/greeter.log says:

(EE)
Fatal server error:
(EE) Cannot open log file "/var/lib/gdm/.local/share/xorg/Xorg.pid-330.log"
(EE)
(EE)
Please consult the The X.Org Foundation support
         at http://wiki.x.org
 for help.
(EE)
Unable to run X server

Any help would be appreciated!

Veera

Message #8 received at 40652 <at> debbugs.gnu.org (full text, mbox):

From: R Veera Kumar <vkor <at> vkten.in>
To: 40652 <at> debbugs.gnu.org
Subject: SLIM is working though with gnome, mate, xfce and enlightenment
Date: Thu, 16 Apr 2020 06:44:57 +0530

I checked that the installed system is working with SLIM.

All gnome, mate, xfce and enlightenment are working.

Perhaps the gdm patch for 1.1.0 release is causing the problem, which
changes xsession path.

Regards,
Veera

Message #11 received at 40652 <at> debbugs.gnu.org (full text, mbox):

From: R Veera Kumar <vkor <at> vkten.in>
To: 40652 <at> debbugs.gnu.org
Subject: Local build of gdm without gdm-xsession.patch still fails to start
Date: Thu, 16 Apr 2020 08:28:19 +0530

Tried local build of gdm using master branch without gdm-xsession.patch still
fails to start it.

Updated master to 8080c03d14ccdd7897a902966ea4aeea8dbfd359 commit
Date:   Wed Apr 15 19:44:41 2020 +0200

And done guix system reconfigure still gdm failing to start.

Regards,
Veera

Message #14 received at 40652 <at> debbugs.gnu.org (full text, mbox):

From: sirgazil <sirgazil <at> zoho.com>
To: "40652" <40652 <at> debbugs.gnu.org>
Subject: GDM does not starts after April 10 system reconfigure
Date: Thu, 16 Apr 2020 04:19:05 +0000

I just pull and configured my system and get the same problem.

New session c1 of user gdm.
Removed session c1.

"/var/log/messages" shows the following messages between some ntpd messages:

Apr 15 22:31:06 localhost gdm: Child process -537 was already dead. 
Apr 15 22:35:29 localhost gdm: Child process -558 was already dead. 
Apr 15 22:39:14 localhost gdm: Child process -538 was already dead. 



$ guix describe
Generation 71	Apr 15 2020 21:34:09	(current)
  sirgazil-x 66d4b67
    repository URL: https://gitlab.com/sirgazil/guix-channel-x.git
    branch: master
    commit: 66d4b677875c84d0b7a946376cd4885f202094eb
  guix 8080c03
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: 8080c03d14ccdd7897a902966ea4aeea8dbfd359


---
https://sirgazil.bitbucket.io/

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Rene <pacoon <at> protonmail.com>
To: "bug-guix <at> gnu.org" <bug-guix <at> gnu.org>
Subject: bug#40652: GDM does not starts after April 10 system reconfigure
Date: Thu, 16 Apr 2020 04:53:29 +0000

[Message part 1 (text/plain, inline)]

Hello,

can you try the following workaround ?, consider backing up the directories before deleting.

https://lists.gnu.org/archive/html/bug-guix/2019-08/msg00020.html

I hope it works.

Rene

[Message part 2 (text/html, inline)]

Message #20 received at 40652 <at> debbugs.gnu.org (full text, mbox):

From: R Veera Kumar <vkor <at> vkten.in>
To: 40652 <at> debbugs.gnu.org
Subject: #36924 way solves the problem for me
Date: Thu, 16 Apr 2020 11:01:37 +0530

The solution in bug #36924 solved the problem in my system.

Remove /var/lib/gdm and make a empty one instead.

Thanks Rene!

Regards,
Veera

Message #23 received at 40652 <at> debbugs.gnu.org (full text, mbox):

From: Guillaume Le Vaillant <glv <at> posteo.net>
To: 40652 <at> debbugs.gnu.org
Subject: Re: bug#40652: #36924 way solves the problem for me
Date: Thu, 16 Apr 2020 09:32:18 +0200

[Message part 1 (text/plain, inline)]

R Veera Kumar <vkor <at> vkten.in> skribis:

> The solution in bug #36924 solved the problem in my system.
>
> Remove /var/lib/gdm and make a empty one instead.
>
> Thanks Rene!
>
> Regards,
> Veera

I don't know if it's related, but recently I had GDM crashes at boot
after reconfiguring a system using gdm-service-type (generation n) to
make it use slim-service-type instead (generation n+1), and then
reconfiguring to gdm-service-type again (generation n+2).

The problem was that the 'gdm' user id number (or group id number) was
not the same in generations n and n+2, which prevented GDM from
accessing the '/var/lib/gdm' directory.

Changing the permissions with "chown -R gdm.gdm /var/lib/gdm" or
deleting '/var/lib/gdm' to force the creation of a new one with correct
permissions allowed GDM to work correctly again.

[signature.asc (application/pgp-signature, inline)]

Message #26 received at 40652 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Guillaume Le Vaillant <glv <at> posteo.net>
Cc: 40652 <at> debbugs.gnu.org
Subject: Re: bug#40652: #36924 way solves the problem for me
Date: Thu, 16 Apr 2020 10:43:50 +0200

Hi Guillaume,

Guillaume Le Vaillant <glv <at> posteo.net> skribis:

> I don't know if it's related, but recently I had GDM crashes at boot
> after reconfiguring a system using gdm-service-type (generation n) to
> make it use slim-service-type instead (generation n+1), and then
> reconfiguring to gdm-service-type again (generation n+2).
>
> The problem was that the 'gdm' user id number (or group id number) was
> not the same in generations n and n+2, which prevented GDM from
> accessing the '/var/lib/gdm' directory.

When did that happen?

Commit a43e9157ef479e94c19951cc9d228cf153bf78ee (Sep. 2019) supposedly
ensures that /var/lib/gdm has proper ownership.

Thanks,
Ludo’.

Message #29 received at 40652 <at> debbugs.gnu.org (full text, mbox):

From: Guillaume Le Vaillant <glv <at> posteo.net>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 40652 <at> debbugs.gnu.org
Subject: Re: bug#40652: #36924 way solves the problem for me
Date: Thu, 16 Apr 2020 10:57:26 +0200

[Message part 1 (text/plain, inline)]

Ludovic Courtès <ludo <at> gnu.org> skribis:

> Hi Guillaume,
>
> Guillaume Le Vaillant <glv <at> posteo.net> skribis:
>
>> I don't know if it's related, but recently I had GDM crashes at boot
>> after reconfiguring a system using gdm-service-type (generation n) to
>> make it use slim-service-type instead (generation n+1), and then
>> reconfiguring to gdm-service-type again (generation n+2).
>>
>> The problem was that the 'gdm' user id number (or group id number) was
>> not the same in generations n and n+2, which prevented GDM from
>> accessing the '/var/lib/gdm' directory.
>
> When did that happen?
>
> Commit a43e9157ef479e94c19951cc9d228cf153bf78ee (Sep. 2019) supposedly
> ensures that /var/lib/gdm has proper ownership.
>
> Thanks,
> Ludo’.

I think it was around 2 weeks ago.

[signature.asc (application/pgp-signature, inline)]

Message #32 received at 40652 <at> debbugs.gnu.org (full text, mbox):

From: Guillaume Le Vaillant <glv <at> posteo.net>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 40652 <at> debbugs.gnu.org
Subject: Re: bug#40652: #36924 way solves the problem for me
Date: Thu, 16 Apr 2020 11:24:38 +0200

[Message part 1 (text/plain, inline)]

Guillaume Le Vaillant <glv <at> posteo.net> skribis:

> Ludovic Courtès <ludo <at> gnu.org> skribis:
>
>> Hi Guillaume,
>>
>> Guillaume Le Vaillant <glv <at> posteo.net> skribis:
>>
>>> I don't know if it's related, but recently I had GDM crashes at boot
>>> after reconfiguring a system using gdm-service-type (generation n) to
>>> make it use slim-service-type instead (generation n+1), and then
>>> reconfiguring to gdm-service-type again (generation n+2).
>>>
>>> The problem was that the 'gdm' user id number (or group id number) was
>>> not the same in generations n and n+2, which prevented GDM from
>>> accessing the '/var/lib/gdm' directory.
>>
>> When did that happen?
>>
>> Commit a43e9157ef479e94c19951cc9d228cf153bf78ee (Sep. 2019) supposedly
>> ensures that /var/lib/gdm has proper ownership.
>>
>> Thanks,
>> Ludo’.
>
> I think it was around 2 weeks ago.

Concerning the service extensions of gdm-service-type, is it guaranteed
that %gdm-activation will be run after %gdm-accounts and not before?
If it's not the case it could explain the problem...

[signature.asc (application/pgp-signature, inline)]

Message #35 received at 40652 <at> debbugs.gnu.org (full text, mbox):

From: sirgazil <sirgazil <at> zoho.com>
To: "40652" <40652 <at> debbugs.gnu.org>
Subject: GDM does not starts after April 10 system reconfigure
Date: Thu, 16 Apr 2020 14:05:51 +0000

Yes, Rene, that worked.

I deleted "/var/lib/gdm" and also ".local/share" and ".cache", which were 4.7 GiB and 2.9 GiB respectively.

Reading bug #36924 now I remember I've been through this before.

Message #38 received at 40652 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Guillaume Le Vaillant <glv <at> posteo.net>
Cc: 40652 <at> debbugs.gnu.org
Subject: Re: bug#40652: #36924 way solves the problem for me
Date: Thu, 16 Apr 2020 23:03:02 +0200

Guillaume Le Vaillant <glv <at> posteo.net> skribis:

> Guillaume Le Vaillant <glv <at> posteo.net> skribis:
>
>> Ludovic Courtès <ludo <at> gnu.org> skribis:
>>
>>> Hi Guillaume,
>>>
>>> Guillaume Le Vaillant <glv <at> posteo.net> skribis:
>>>
>>>> I don't know if it's related, but recently I had GDM crashes at boot
>>>> after reconfiguring a system using gdm-service-type (generation n) to
>>>> make it use slim-service-type instead (generation n+1), and then
>>>> reconfiguring to gdm-service-type again (generation n+2).
>>>>
>>>> The problem was that the 'gdm' user id number (or group id number) was
>>>> not the same in generations n and n+2, which prevented GDM from
>>>> accessing the '/var/lib/gdm' directory.
>>>
>>> When did that happen?
>>>
>>> Commit a43e9157ef479e94c19951cc9d228cf153bf78ee (Sep. 2019) supposedly
>>> ensures that /var/lib/gdm has proper ownership.
>>>
>>> Thanks,
>>> Ludo’.
>>
>> I think it was around 2 weeks ago.
>
> Concerning the service extensions of gdm-service-type, is it guaranteed
> that %gdm-activation will be run after %gdm-accounts and not before?
> If it's not the case it could explain the problem...

‘%gdm-activation’ would throw an exception if the “gdm” user didn’t
exist, so apparently it’s run before the activation snippet of
‘account-service-type’ (the ordering guarantee is not explicit.)

Hmm I wonder what I’m missing then.  Would you like to try again?

Now, I think we should generalize this chown thing and apply it to all
the user accounts.  ‘user-homes’ would chown recursively if needed or
use the newfangled shiftfs, like systemd-homed does¹.

Thoughts?

Ludo’.

¹ https://systemd.io/HOME_DIRECTORY/

Message #41 received at 40652 <at> debbugs.gnu.org (full text, mbox):

From: Guillaume Le Vaillant <glv <at> posteo.net>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 40652 <at> debbugs.gnu.org
Subject: Re: bug#40652: #36924 way solves the problem for me
Date: Fri, 17 Apr 2020 11:06:48 +0200

[Message part 1 (text/plain, inline)]

Ludovic Courtès <ludo <at> gnu.org> skribis:

> ‘%gdm-activation’ would throw an exception if the “gdm” user didn’t
> exist, so apparently it’s run before the activation snippet of
> ‘account-service-type’ (the ordering guarantee is not explicit.)
>
> Hmm I wonder what I’m missing then.  Would you like to try again?

I tried again and I wasn't able to reproduce the problem.
Maybe I did something weird with my config last time, but I can't
remember what it could have been...

> Now, I think we should generalize this chown thing and apply it to all
> the user accounts.  ‘user-homes’ would chown recursively if needed or
> use the newfangled shiftfs, like systemd-homed does¹.
>
> Thoughts?
> Ludo’.
>
> ¹ https://systemd.io/HOME_DIRECTORY/

A recursive chown for system accounts (with their home directory
somewhere in '/var') sounds like a good idea.

For user accounts (in '/home'), I guess it could be slightly annoying if
a user wants to set a specific group id to some of their files and if it
gets set back to the 'users' group at each system reconfiguration.
However it's probably not a very common use case, and if we only change
the files' uid, they could end up with an invalid gid anyway.

[signature.asc (application/pgp-signature, inline)]

Message #44 received at 40652 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Guillaume Le Vaillant <glv <at> posteo.net>
Cc: 40652 <at> debbugs.gnu.org
Subject: Re: bug#40652: #36924 way solves the problem for me
Date: Sat, 18 Apr 2020 18:40:17 +0200

Hi,

Guillaume Le Vaillant <glv <at> posteo.net> skribis:

> Ludovic Courtès <ludo <at> gnu.org> skribis:
>
>> ‘%gdm-activation’ would throw an exception if the “gdm” user didn’t
>> exist, so apparently it’s run before the activation snippet of
>> ‘account-service-type’ (the ordering guarantee is not explicit.)
>>
>> Hmm I wonder what I’m missing then.  Would you like to try again?
>
> I tried again and I wasn't able to reproduce the problem.
> Maybe I did something weird with my config last time, but I can't
> remember what it could have been...

OK.

>> Now, I think we should generalize this chown thing and apply it to all
>> the user accounts.  ‘user-homes’ would chown recursively if needed or
>> use the newfangled shiftfs, like systemd-homed does¹.
>>
>> Thoughts?
>> Ludo’.
>>
>> ¹ https://systemd.io/HOME_DIRECTORY/
>
> A recursive chown for system accounts (with their home directory
> somewhere in '/var') sounds like a good idea.
>
> For user accounts (in '/home'), I guess it could be slightly annoying if
> a user wants to set a specific group id to some of their files and if it
> gets set back to the 'users' group at each system reconfiguration.
> However it's probably not a very common use case, and if we only change
> the files' uid, they could end up with an invalid gid anyway.

Right.  The recursive chown would only happen if the home directory
itself has the wrong UID though, so that would still let you fiddle with
ownership of the files within it.  Worth trying!

Thanks,
Ludo’.

Message #49 received at 40652-done <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: R Veera Kumar <vkor <at> vkten.in>
Cc: 40652-done <at> debbugs.gnu.org
Subject: Re: bug#40652: GDM does not starts after April 10 system reconfigure
Date: Thu, 09 Jun 2022 20:40:50 -0400

Hello,

R Veera Kumar <vkor <at> vkten.in> writes:

> The solution in bug #36924 solved the problem in my system.
>
> Remove /var/lib/gdm and make a empty one instead.

Thanks for letting us know.

Closing since #36924 is still open.

Thanks,

Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.