gdm doesn't start

  • Done
  • quality assurance status badge
Details
5 participants
  • Danny Milosavljevic
  • Jack Hill
  • Leo Prikler
  • Raghav Gururajan
  • sirgazil
Owner
unassigned
Submitted by
Jack Hill
Severity
normal
J
J
Jack Hill wrote on 25 Jan 2020 21:32
(address . bug-guix@gnu.org)
alpine.DEB.2.20.2001251518430.11123@marsh.hcoop.net
Hi Guix,

After a recent pull and system reconfigure, gdm does not start at boot.
Instead, I am left with a text console login. sirgazil also described the
problem on irc, "I just did guix pull and sudo system reconfigure, and GDM
never started after waiting for about 10 minutes. This may be the same
problem gnutec was having yesterday..."

The last known good guix for me is
7842ddcbc118cbc2799e22651732b7cdc06b93ee and the first known bad commit is
df6ce9fcb455ac59372f1025e450005ea3190614.

My operating system config is included below:

Best,
Jack

(use-modules (gnu) (gnu system nss) (gnu services xorg)
(gnu packages linux))
(use-service-modules desktop)
(use-package-modules certs gnome scanner security-token)

(operating-system
(host-name "alperton")
(timezone "America/New_York")
(locale "en_US.utf8")

(bootloader (bootloader-configuration
(bootloader grub-bootloader)
(target "/dev/sda")))

;; Specify a mapped device for the encrypted root partition.
;; The UUID is that returned by 'cryptsetup luksUUID'.
(mapped-devices
(list (mapped-device
(source (uuid "f7776767-70c9-44e3-9973-c1334d301348"))
(target "alperton_root")
(type luks-device-mapping))))

(file-systems (cons
(file-system
(device (file-system-label "alperton_root"))
(mount-point "/")
(type "ext4")
(dependencies mapped-devices))
%base-file-systems))

(swap-devices (list "/root/swap"))

(users (cons (user-account
(name "jackhill")
(comment "Jack Hill")
(group "users")
(supplementary-groups '("wheel" "netdev"
"audio" "lp" "video"))
(home-directory "/home/jackhill"))
%base-user-accounts))

;; This is where we specify system-wide packages.
(packages (cons* nss-certs ;for HTTPS access
fuse-exfat
bluez
gvfs ;for user mounts
%base-packages))

;; Add GNOME and/or Xfce---we can choose at the log-in
;; screen with F1. Use the "desktop" services, which
;; include the X11 log-in service, networking with
;; NetworkManager, and more.
(services (cons* (service gnome-desktop-service-type)
(bluetooth-service)
(simple-service 'custom-udev-rules udev-service-type (list sane-backends libu2f-host))
%desktop-services))

(firmware %base-firmware)

;; Allow resolution of '.local' host names with mDNS.
(name-service-switch %mdns-host-lookup-nss))
S
J
J
Jack Hill wrote on 26 Jan 2020 04:33
(name . sirgazil)(address . sirgazil@zoho.com)(name . 39281)(address . 39281@debbugs.gnu.org)
alpine.DEB.2.20.2001252227250.11123@marsh.hcoop.net
I've started bisecting between my known bad and good commits.
Unfortunately, this will be a slow process both because my computer is
only so fast, and because rebooting to check a commit disrupts other work.

That said, why checking one of the bad commits, I noticed that the gdm
process was indeed started by shepherd and hadn't died, but it was not
making any progress for some reason. Running `sudo herd restart
xorg-server` caused it to bring up the gdm greater, and work normally.

I did notice the following in /var/log/gdm/greeter.log There was not
anything interesting in the xorg log. Unfortunately, I didn't think to
strace the gdm process before restarting it.

(EE)gnome-session-binary[837]: WARNING: Lost name on bus: org.gnome.SessionManager

(gsd-screensaver-proxy:927): GLib-GIO-WARNING **: 22:00:51.322: Error releasing name org.freedesktop.ScreenSaver: The connection is closed

(gsd-housekeeping:924): GLib-GIO-WARNING **: 22:00:51.322: Error releasing name org.gnome.SettingsDaemon.Housekeeping: The connection is closed

Fatal server error:
(EE) systemd-logind disappeared (stopped/restarted?)
(EE)
(EE)
Please consult the The X.Org Foundation support
for help.
(EE) Please also check the log file at "/var/lib/gdm/.local/share/xorg/Xorg.0.log" for additional information.
(EE)
(EE) systemd-logind: ReleaseControl failed: Connection was disconnected before a reply was received
(EE) Server terminated with error (1). Closing log file.
Gdk-Message: 22:00:51.636: gsd-power: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.

Gdk-Message: 22:00:51.636: gsd-clipboard: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.

Gdk-Message: 22:00:51.636: gsd-keyboard: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.

Gdk-Message: 22:00:51.636: gsd-media-keys: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.

Gdk-Message: 22:00:51.636: .gnome-shell-real: Fatal IO error 4 (Interrupted system call) on X server :0.

Gdk-Message: 22:00:51.636: gsd-wacom: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.

Gdk-Message: 22:00:51.638: gsd-xsettings: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
J
J
Jack Hill wrote on 27 Jan 2020 03:26
(address . sirgazil@zoho.com)
alpine.DEB.2.20.2001262111550.11123@marsh.hcoop.net
According to my git bisect, d36fa50fbf8169018193774782fd21f1b13b9c0e [0]
is the culprit. It makes some sense that the commit is gnome-related, but
I have no idea why adding more packages to the environment should cause
gdm to fail to run properly. Therefore, I am inclined to believe that it is
a weird timing issue as Leo suspects.


On Sun, 26 Jan 2020, Leo Prikler wrote:

Toggle quote (6 lines)
> I saw the same warnings on one of my systems as well, but it boots
> fine. On another one, the same behaviour occurs, but GDM can be
> started manually by restarting xorg-server from a TTY. Note, that I
> can not do so from an SSH remote, because SSH fails to start in a
> similar manner.

My system does indeed have a really slow disk, so perhaps this makes the
problem more likely to happen. Obviously, it would be nice if gdm started
correctly, but in a bigger picture, it would be nice if shepherd had a
better way of dealing with misbehaving services. For example, if shepherd
know how to check the health of a service and restarted it wasn't
responding correctly.

I don't know where to go from here. Hopefully someone more knowledgeable
about gnome and gdm can help us out.

Best,
Jack
R
R
Raghav Gururajan wrote on 27 Jan 2020 04:30
(address . sirgazil@zoho.com)
93d47bbc972a326dd8479b7ecee7ec83@disroot.org
Toggle quote (5 lines)
> According to my git bisect, d36fa50fbf8169018193774782fd21f1b13b9c0e [0] is the culprit. It makes
> some sense that the commit is gnome-related, but I have no idea why adding more packages to the
> environment should cause gdm to fail to run properly. Therefore, I am inclined to believe that it
> is a weird timing issue as Leo suspects.

Interesting! Thanks for the info. Yeah, technically adding those package shouldn't affect gdm, as they are independent of each other. So could be the timing or something else.

Regards,
RG.
J
J
Jack Hill wrote on 27 Jan 2020 05:50
(name . Raghav Gururajan)(address . raghavgururajan@disroot.org)
alpine.DEB.2.20.2001262334250.11123@marsh.hcoop.net
I believe that I've found the problem!

Using the technique that Ludo’ described in
https://issues.guix.gnu.org/issue/34580#17, I was able to grab an strace
of gdm (attached) while it was failing to start properly. I was suspicious
of the following line:

"""
418 22:46:10 sendto(8, "<13>Jan 26 22:46:10 gdm: GdmManager: couldn't
look up username gnome-initial-setup\n", 83, MSG_NOSIGNAL, NULL, 0) = 83
<5.487224>
"""

so I removed gnome-initial-setup from the propagated-inputs with the
following patch, and, indeed, that resolved the problem with gdm on my
system.

While I'm still not exactly sure why this was causing gdm problems, and
why `herd restart xorg-server` caused gdm to start working correctly, I
think that removing gnome-initial-setup from the gnome meta-package is the
right thing to do. Instead, perhaps it could be provided via its own
service, auto-selected by the installer. If I recall correctly from other
distros (e.g. Fedora), the gnome-initial-setup wizard is run from its own
user on first boot, and after it finishes, the user is logged in as
themselves. That said, gnome-initial-setup did seem to run fine for me the
first time I logged into gnome after it was installed, and hasn't stared
again.

Thoughts?
Jack

P.S. Thanks Raghav for your work on making gnome in guix a better
experience!
Attachment: gdm.log
J
J
Jack Hill wrote on 27 Jan 2020 05:52
[PATCH] gnu: gnome: don't propagate gnome-initial-setup
(address . 39281@debbugs.gnu.org)(name . Jack Hill)(address . jackhill@jackhill.us)
20200127045219.2032-1-jackhill@jackhill.us
Fixes bug#39281

* gnu/packages/gnome.scm (gnome)[propagated-inputs]:
remove gnome-initial-setup
---
gnu/packages/gnome.scm | 1 -
1 file changed, 1 deletion(-)

Toggle diff (14 lines)
diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index e843bdfe08..9db379744a 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -7865,7 +7865,6 @@ world.")
("gnome-control-center" ,gnome-control-center)
("gnome-desktop" ,gnome-desktop)
("gnome-getting-started-docs" ,gnome-getting-started-docs)
- ("gnome-initial-setup" ,gnome-initial-setup)
("gnome-keyring" ,gnome-keyring)
("gnome-menus" ,gnome-menus)
("gnome-session" ,gnome-session)
--
2.25.0
L
L
Leo Prikler wrote on 27 Jan 2020 06:24
Re: bug#39281: gdm doesn't start
078e812400c0944093ac949b71a8782bf5401caf.camel@student.tugraz.at
Am Sonntag, den 26.01.2020, 23:50 -0500 schrieb Jack Hill:
Toggle quote (39 lines)
> I believe that I've found the problem!
>
> Using the technique that Ludo’ described in
> <https://issues.guix.gnu.org/issue/34580#17>;, I was able to grab an
> strace
> of gdm (attached) while it was failing to start properly. I was
> suspicious
> of the following line:
>
> """
> 418 22:46:10 sendto(8, "<13>Jan 26 22:46:10 gdm: GdmManager:
> couldn't
> look up username gnome-initial-setup\n", 83, MSG_NOSIGNAL, NULL, 0) =
> 83
> <5.487224>
> """
>
> so I removed gnome-initial-setup from the propagated-inputs with the
> following patch, and, indeed, that resolved the problem with gdm on
> my
> system.
>
> While I'm still not exactly sure why this was causing gdm problems,
> and
> why `herd restart xorg-server` caused gdm to start working correctly,
> I
> think that removing gnome-initial-setup from the gnome meta-package
> is the
> right thing to do. Instead, perhaps it could be provided via its own
> service, auto-selected by the installer. If I recall correctly from
> other
> distros (e.g. Fedora), the gnome-initial-setup wizard is run from its
> own
> user on first boot, and after it finishes, the user is logged in as
> themselves. That said, gnome-initial-setup did seem to run fine for
> me the
> first time I logged into gnome after it was installed, and hasn't
> stared
> again.
The problem is, that adding gnome-initial-setup in any way to the
operating-system config will likely trigger this bug as well, and not
adding it at all will skip the initial setup until it is installed at
user level (at this point, I'd argue it to be no longer necessary).
You could try creating a file named "/var/lib/gdm/.config/gnome-
initial-setup-done" with the contents "yes" to skip the initial setup,
but I'm pretty sure, that it will be looked up regardless.

Perhaps some GNOME people know how to disable this in other ways, but
it's the first time I've even seen the dialog, so there's not much else
I can say. Btw. are there more logs regarding gnome-initial-setup than
this one? At least in my case none of them seem to land in greeter.log
or messages.

Regards,
Leo
R
R
Raghav Gururajan wrote on 27 Jan 2020 09:51
(name . Jack Hill)(address . jackhill@jackhill.us)
ef5bdc7328c053c19b267dd464483169@disroot.org
Toggle quote (2 lines)
> I believe that I've found the problem!

Nice!

Toggle quote (12 lines)
> Using the technique that Ludo’ described in https://issues.guix.gnu.org/issue/34580#17, I was
> able to grab an strace of gdm (attached) while it was failing to start properly. I was suspicious
> of the following line:
>
> """
> 418 22:46:10 sendto(8, "<13>Jan 26 22:46:10 gdm: GdmManager: couldn't look up username
> gnome-initial-setup\n", 83, MSG_NOSIGNAL, NULL, 0) = 83 <5.487224>
> """
>
> so I removed gnome-initial-setup from the propagated-inputs with the following patch, and, indeed,
> that resolved the problem with gdm on my system.

That's strange. Both our system share similar configuration. But for me gdm works fine with gnome-initial-setup being present. This is confusing.

Toggle quote (10 lines)
> While I'm still not exactly sure why this was causing gdm problems, and why `herd restart
> xorg-server` caused gdm to start working correctly, I think that removing gnome-initial-setup from
> the gnome meta-package is the right thing to do. Instead, perhaps it could be provided via its own
> service, auto-selected by the installer. If I recall correctly from other distros (e.g. Fedora),
> the gnome-initial-setup wizard is run from its own user on first boot, and after it finishes, the
> user is logged in as themselves. That said, gnome-initial-setup did seem to run fine for me the
> first time I logged into gnome after it was installed, and hasn't stared again.
>
> Thoughts?

I would say debugging and fixing would be better than removing. Let me see what I can do.
Toggle quote (2 lines)
> P.S. Thanks Raghav for your work on making gnome in guix a better experience!

10-4 on the sarcasm. ;-)

Regards,
RG.
J
J
Jack Hill wrote on 27 Jan 2020 20:08
(name . Raghav Gururajan)(address . raghavgururajan@disroot.org)
alpine.DEB.2.20.2001271401340.11123@marsh.hcoop.net
On Mon, 27 Jan 2020, Raghav Gururajan wrote:

Toggle quote (7 lines)
>> so I removed gnome-initial-setup from the propagated-inputs with the following patch, and, indeed,
>> that resolved the problem with gdm on my system.
>
> That's strange. Both our system share similar configuration. But for me
> gdm works fine with gnome-initial-setup being present. This is
> confusing.

Indeed, my system does have a really slow disk, so it would not surprise
me if that contributed to it. Of course that shouldn't matter, but that's
the only thing I can think it. It would be nice to hear if sirgazil can
reproduce the fix since I think they were having the same problem on their
computer.

Toggle quote (12 lines)
>> While I'm still not exactly sure why this was causing gdm problems, and why `herd restart
>> xorg-server` caused gdm to start working correctly, I think that removing gnome-initial-setup from
>> the gnome meta-package is the right thing to do. Instead, perhaps it could be provided via its own
>> service, auto-selected by the installer. If I recall correctly from other distros (e.g. Fedora),
>> the gnome-initial-setup wizard is run from its own user on first boot, and after it finishes, the
>> user is logged in as themselves. That said, gnome-initial-setup did seem to run fine for me the
>> first time I logged into gnome after it was installed, and hasn't stared again.
>>
>> Thoughts?
>
> I would say debugging and fixing would be better than removing. Let me see what I can do.

I agree that fixing is better than removing. Good luck debugging. I'm
happy to test, but am currently out of ideas.

Toggle quote (4 lines)
>> P.S. Thanks Raghav for your work on making gnome in guix a better experience!
>
> 10-4 on the sarcasm. ;-)

I'm glad that you took this well :). However, while I'm often sarcastic, I
wasn't trying to be here. What I was trying to express was that while I'm
currently running my system with gnome-initial-setup removed doesn't mean
that I don't appreciate the change to make it present by default.
Fortunately for me, Guix makes this easy compared to other systems!

Best,
Jack
S
S
sirgazil wrote on 27 Jan 2020 20:54
(name . Jack Hill)(address . jackhill@jackhill.us)
16fe8920f9b.fa7d575955256.663632270245241639@zoho.com
---- On Mon, 27 Jan 2020 14:08:44 -0500 Jack Hill <jackhill@jackhill.us> wrote ----
> On Mon, 27 Jan 2020, Raghav Gururajan wrote:
>
> >> so I removed gnome-initial-setup from the propagated-inputs with the following patch, and, indeed,
> >> that resolved the problem with gdm on my system.
> >
> > That's strange. Both our system share similar configuration. But for me
> > gdm works fine with gnome-initial-setup being present. This is
> > confusing.
>
> Indeed, my system does have a really slow disk, so it would not surprise
> me if that contributed to it. Of course that shouldn't matter, but that's
> the only thing I can think it. It would be nice to hear if sirgazil can
> reproduce the fix since I think they were having the same problem on their
> computer.

Was the patch already applied? Because I just pulled, reconfigured and I have the same problem: After a message like this

Jan 27 14:24:57 localhost dbus-daemon[446]: [system] Failed to activate service 'org.freedesktop.Accounts': timed out (service_start_timeout=25000ms)

I only see a flashing caret that makes me think something is going to happen next, but after waiting for more than five minutes, nothing happens. If I go to TTY2, for example, I can log in and "sudo herd restart xorg-server"; then, after a few seconds, GDM is ready in TTY7, and I can log in to the desktop.

For what is worth, my computer has a HDD. I also see this message in /var/log/debug:

Jan 27 14:24:57 localhost gdm: Failed to contact accountsservice: Error calling StartServiceByName for org.freedesktop.Accounts: Timeout was reached

My current Guix:

$ LANG=C guix describe
Generation 11 Jan 27 2020 14:18:01 (current)
guix fcb510c
branch: master
commit: fcb510c541e83291ea6682cba87020a913c64914
J
J
Jack Hill wrote on 27 Jan 2020 21:13
(name . sirgazil)(address . sirgazil@zoho.com)
alpine.DEB.2.20.2001271510350.11123@marsh.hcoop.net
On Mon, 27 Jan 2020, sirgazil wrote:

Toggle quote (2 lines)
> Was the patch already applied? Because I just pulled, reconfigured and I have the same problem: After a message like this

No, the patch wasn't applied, as we're still not sure if there is a better
fix. I applied it to my local copy of guix [0] to test. If you could apply
it locally as well (or just pull from my tree with `guix pull
and confirm that it fixes the problem for you as well, that would be
great.


Best,
Jack
D
D
Danny Milosavljevic wrote on 27 Jan 2020 21:24
(name . sirgazil via Bug reports for GNU Guix)(address . bug-guix@gnu.org)
20200127212434.1738de43@scratchpost.org
Hi,

hmm, if you want to find out whether we could fix it, could you invoke:

useradd gnome-initial-setup

(on the console via ctrl-alt-f1) and then reboot?

If that doesn't fix it I'm all for removing gnome-initial-setup for the time being...
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl4vRwIACgkQ5xo1VCww
uqXPrQgAndORQ1j5dynb5ACLBdIUwNyog1gRsydD0cbvSmHe9oqGgFGSMy0kWzea
57XnHXeicp4GUw26ZDJxoQi6gXDjVRi487w90memJfBEzOIOkZkqzOQwiix35D3l
Jb0hLoj8Q2TFT1LXrtZhCJvR1CeW748ysgh/uN/ttdyppbXeDmc1Z/j4Vv/Qupyg
rTnfPl1wOgBnzl2PuUxpV/mwXkHxPqM5XkKMfZjAA2LGL0A+x2ypPQHizyHow78q
Ny+9HvwNmYY17UB6c0/IoEiXdCGsnFvCPkQ0xkk7Kv9tjQZS6hwzTR9MZ7jvVLff
t46D1s4Ru39OmoFKVTCrTt1jcQjYhQ==
=FF0K
-----END PGP SIGNATURE-----


D
D
Danny Milosavljevic wrote on 27 Jan 2020 21:29
(name . sirgazil via Bug reports for GNU Guix)(address . bug-guix@gnu.org)
20200127212905.4955429b@scratchpost.org
Patch applied to guix master as commit 4fc4e5fdd9da6320aa94eeec61cbb84a7dc9460e
for now.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl4vSBEACgkQ5xo1VCww
uqX95wf7BtUEJPteHn/iG0BNmwzCdLLw0mvU0vsU/xSFXwVuH9IcK2hYDlmyIvo7
pk65RVbmhvxzeiQKH+3kk2pRFIyKDbuZwrWwDkxNFQObhqTH/0kXxpSpPDvvZwU5
D8p1XOgMs+HvLrx0Yurl9NRsUtP677Xed3m2Le/JH+wNUZPS7jNsDox4NZJbd2f2
ulajH1OKgNmutCG/BLmRymrRmu2ZrQJMx1kpwyUhiOHvBimkMLVwkl2c3QrYq/uG
cqm7N385zXpdPrXAQUz40UiDqlEq993U2Ms7m9KXTZNZ3sihW7O1oMfWrmC3UHXH
Xg+I1o4C/oeKF+65pmKMzrnuEc8mQw==
=bNjA
-----END PGP SIGNATURE-----


J
J
Jack Hill wrote on 27 Jan 2020 22:06
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)
alpine.DEB.2.20.2001271603130.11123@marsh.hcoop.net
On Mon, 27 Jan 2020, Danny Milosavljevic wrote:

Toggle quote (6 lines)
> Hi,
>
> hmm, if you want to find out whether we could fix it, could you invoke:
>
> useradd gnome-initial-setup

I added gnome-initial-setup to my operating system config and reconfigured
with 94600c3960d7e2f12a3a9b6d2ed0d98ddacdd055 (the commit before you
appled the patch).

This did not solve the problem for me.

However, the following messages on the console (presumably from logind):

new session c1 for user gnome-initial-setup

followed a little while later by

removed session c1.

During a successful boot, I see

new session c1 for user gdm

followed by the gdm login screen appearing.

Best,
Jack
S
S
sirgazil wrote on 27 Jan 2020 23:07
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)
16fe90bacb9.db79669456866.8464002501351461004@zoho.com
---- On Mon, 27 Jan 2020 15:29:05 -0500 Danny Milosavljevic <dannym@scratchpost.org> wrote ----
> Patch applied to guix master as commit 4fc4e5fdd9da6320aa94eeec61cbb84a7dc9460e
> for now.
>

Problem solved for me :)
R
R
Raghav Gururajan wrote on 28 Jan 2020 06:21
(name . Jack Hill)(address . jackhill@jackhill.us)
7d118f5a9a05204eacd9388cf9578b2a@disroot.org
Toggle quote (5 lines)
> Indeed, my system does have a really slow disk, so it would not surprise me if that contributed to
> it. Of course that shouldn't matter, but that's the only thing I can think it. It would be nice to
> hear if sirgazil can reproduce the fix since I think they were having the same problem on their
> computer.

I see.

Toggle quote (3 lines)
> I agree that fixing is better than removing. Good luck debugging. I'm happy to test, but am
> currently out of ideas.

Cool! I'll keep you posted.

Toggle quote (5 lines)
> I'm glad that you took this well :). However, while I'm often sarcastic, I wasn't trying to be
> here. What I was trying to express was that while I'm currently running my system with
> gnome-initial-setup removed doesn't mean that I don't appreciate the change to make it present by
> default. Fortunately for me, Guix makes this easy compared to other systems!

Haha. All good then. :-)

Regards,
RG.
L
L
Leo Prikler wrote on 28 Jan 2020 10:37
ab9bb7fdaad38c88983f9557ef55d8851224af25.camel@student.tugraz.at
Am Montag, den 27.01.2020, 06:24 +0100 schrieb Leo Prikler:
Toggle quote (3 lines)
> Perhaps some GNOME people know how to disable this in other ways, but
> it's the first time I've even seen the dialog, so there's not much
> else I can say.
Welp, I found the culprit. It appears to be a bug in gdm-service-type
rather than the gnome meta-package. Specifically, the default GDM
setting appears to be to launch the initial-setup inside GDM "on first
boot", whatever GDM interprets that to be. This can be disabled by
setting "daemon/InitialSetupEnable=false".
Adding this setting to GDM does not affect the initial user setup,
which is probably what raghavgururajan wanted to achieve with the
inclusion of this package into gnome. It only skips the initial system
setup -- a step that Guix should already take care of on its own.

I've attached a patch, that should take care of this bug. So far, I've
only tested it in a VM (with the package added back into gnome), so it
would be nice if one of you could test this with a real reboot before
commiting.

Regards,
Leo
From 9c467dfeb2ab942cf70c0f7f75886e052c864907 Mon Sep 17 00:00:00 2001
From: Leo Prikler <leo.prikler@student.tugraz.at>
Date: Mon, 27 Jan 2020 23:56:57 +0100
Subject: [PATCH] services: Disable initial setup in GDM.

* gnu/services/xorg.scm (gdm-configuration-file):
Disable gnome-initial-setup. Starting it from GDM is probably not the right
idea, given that a configuration record for gdm already exists, and it also
causes bugs like #39281.
---
gnu/services/xorg.scm | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

Toggle diff (18 lines)
diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm
index 9c84f7413f..2b2fd7539d 100644
--- a/gnu/services/xorg.scm
+++ b/gnu/services/xorg.scm
@@ -862,7 +862,10 @@ the GNOME desktop environment.")
"#TimedLoginEnable=false\n"
"#TimedLogin=\n"
"#TimedLoginDelay=0\n"
- "#InitialSetupEnable=true\n"
+ ;; Disable initial system setup inside GDM.
+ ;; Whatever settings are set there should already be
+ ;; taken care of through `guix system'.
+ "InitialSetupEnable=false\n"
;; Enable me once X is working.
"WaylandEnable=false\n"
"\n"
--
2.25.0
J
J
Jack Hill wrote on 28 Jan 2020 19:03
(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)
alpine.DEB.2.20.2001281301020.11123@marsh.hcoop.net
On Tue, 28 Jan 2020, Leo Prikler wrote:

Toggle quote (5 lines)
> I've attached a patch, that should take care of this bug. So far, I've
> only tested it in a VM (with the package added back into gnome), so it
> would be nice if one of you could test this with a real reboot before
> commiting.

I'm happy to report that after applying this patch on top of
94600c3960d7e2f12a3a9b6d2ed0d98ddacdd055 (i.e. with gnome-initial-setup
still part of the gnome meta-package), reconfiguring, and rebooting,
everything works as expected. GDM starts up, and after I log it, I'm
presented with the initial setup wizard.

Thanks everyone,
Jack
S
S
sirgazil wrote on 28 Jan 2020 19:18
(name . Jack Hill)(address . jackhill@jackhill.us)
16fed60046d.e785ebce7220.4165514918301758651@zoho.com
---- On Tue, 28 Jan 2020 13:03:08 -0500 Jack Hill <jackhill@jackhill.us> wrote ----
> On Tue, 28 Jan 2020, Leo Prikler wrote:
>
> > I've attached a patch, that should take care of this bug. So far, I've
> > only tested it in a VM (with the package added back into gnome), so it
> > would be nice if one of you could test this with a real reboot before
> > commiting.

I uncommented gnome-initial-setup, applied Leo's patch, and GDM works as expected.

> I'm happy to report that after applying this patch on top of
> 94600c3960d7e2f12a3a9b6d2ed0d98ddacdd055 (i.e. with gnome-initial-setup
> still part of the gnome meta-package), reconfiguring, and rebooting,
> everything works as expected. GDM starts up, and after I log it, I'm
> presented with the initial setup wizard.
>

The initial setup window did not appear in my case, but I assume it is because somewhere in my system something says I already went through the setup (I did see the window in a previous boot).
J
J
Jack Hill wrote on 28 Jan 2020 19:21
(name . sirgazil)(address . sirgazil@zoho.com)
alpine.DEB.2.20.2001281319370.11123@marsh.hcoop.net
On Tue, 28 Jan 2020, sirgazil wrote:

Toggle quote (4 lines)
> The initial setup window did not appear in my case, but I assume it is
> because somewhere in my system something says I already went through the
> setup (I did see the window in a previous boot).

I beilieve this it tell if it has already run by looking for by
~/.config/gnome-initial-setup-done

Best,
Jack
S
S
sirgazil wrote on 28 Jan 2020 19:26
(name . Jack Hill)(address . jackhill@jackhill.us)
16fed676163.b33840257296.1998320631430839925@zoho.com
---- On Tue, 28 Jan 2020 13:21:40 -0500 Jack Hill <jackhill@jackhill.us> wrote ----
> On Tue, 28 Jan 2020, sirgazil wrote:
>
> > The initial setup window did not appear in my case, but I assume it is
> > because somewhere in my system something says I already went through the
> > setup (I did see the window in a previous boot).
>
> I beilieve this it tell if it has already run by looking for by
> ~/.config/gnome-initial-setup-done

Yep, that file is present.

I also tried with a new user, and the initial setup window was shown as expected.

Thanks,
D
D
Danny Milosavljevic wrote on 28 Jan 2020 21:11
20200128211127.0ba2388f@scratchpost.org
Hi,

thanks for the investigation and patch.

Pushed to guix master as commit 9111f9750084cbc214d36e2ee16308f8edabf11d.

Re-added gnome-initial-setup to gnome with
commit 24882d3d9a0529f34217aac2da2c8d6e2a076a63.

Closing bug report.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl4wlW8ACgkQ5xo1VCww
uqX0swf/UHoK2D5chg1cT6hQh2FZ99In7EbbOM+LR/yJXf8HPU3FdN8J83z2SoWp
qTzWESOE+9F9S0fG/LNkYe+y1t2YeM6qKydN5RjPPdTbnWzd7KuUv6qDZWl7knK1
tC4ZzzWLavy0qq7Rm4LYAs0ETVG4PFfQJvr4L8y62H2NmoPR7MFPIxXJ6KcZkHCg
ZXzKy/B4eN6sr04qIhqkY2ApF5qnrc4MgKuWk58JcxI0embE0o75XH6t5YQQXtOe
U4t0dktBt9wGognTpFTzL6/Olw2vWO1Sm1adW7RrmjgWKB6ZWfbIBBoX80z9jJ2N
fa/O+QkAqn9nWlVmM5/dk9r5SYXAqQ==
=wGEi
-----END PGP SIGNATURE-----


Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 39281@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 39281
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch