gdm doesn't start

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))

For what is worth, I saw the following warnings when guix system reconfigure was running:

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

at http://wiki.x.org

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.

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.

[0] http://git.savannah.gnu.org/cgit/guix.git/commit/?id=d36fa50fbf8169018193774782fd21f1b13b9c0e

On Sun, 26 Jan 2020, Leo Prikler wrote:

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

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.

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!

Fixes bug#39281

remove gnome-initial-setup

---

gnu/packages/gnome.scm | 1 -

1 file changed, 1 deletion(-)

Am Sonntag, den 26.01.2020, 23:50 -0500 schrieb Jack Hill:

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

Nice!

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

I would say debugging and fixing would be better than removing. Let me see what I can do.

10-4 on the sarcasm. ;-)

Regards,

RG.

On Mon, 27 Jan 2020, Raghav Gururajan wrote:

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 agree that fixing is better than removing. Good luck debugging. I'm

happy to test, but am currently out of ideas.

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

---- 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

repository URL: https://git.savannah.gnu.org/git/guix.git

branch: master

commit: fcb510c541e83291ea6682cba87020a913c64914

On Mon, 27 Jan 2020, sirgazil wrote:

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

--url="https://gitab.oit.duke.edu/jackhill/guix.git"--branch="gdm-fix"`)

and confirm that it fixes the problem for you as well, that would be

great.

[0] https://gitlab.oit.duke.edu/jackhill/guix/tree/gdm-fix

Best,

Jack

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...

Patch applied to guix master as commit 4fc4e5fdd9da6320aa94eeec61cbb84a7dc9460e

for now.

On Mon, 27 Jan 2020, Danny Milosavljevic wrote:

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

---- 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 :)

I see.

Cool! I'll keep you posted.

Haha. All good then. :-)

Regards,

RG.

Am Montag, den 27.01.2020, 06:24 +0100 schrieb Leo Prikler:

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

On Tue, 28 Jan 2020, Leo Prikler wrote:

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

---- 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).

On Tue, 28 Jan 2020, sirgazil wrote:

I beilieve this it tell if it has already run by looking for by

~/.config/gnome-initial-setup-done

Best,

Jack

---- 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,

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.