[SOLVED] GDM does not start on boot

Bidski · 2019-07-31 22:50:04

I have a new install of arch on my laptop. I have installed GDM along with Gnome and I have enabled the GDM service, but GDM just doesnt start. Every time I boot I end up at a tty login. If I login and start GDM as

sudo systemctl start gdm

then GDM will start as expected.

I have googled around to try and find some answers and I have tried everything I have found (enabling early KMS with nvidia drivers, setting the GDM service to have Idle type, disabling the wayland backend), nothing has worked.

I was just having a look at the GDM systemd service file and I noticed this line

After=rc-local.service plymouth-start.service systemd-user-sessions.service

However, rc-local.service and plymouth-start.service dont exist on my system (neither does plymouth-quit.service which is mentioned in another part of the GDM service file).

Is systemd failing to start GDM because it is waiting for these non-existent services?

The GDM wiki page and the GDM package both make no mention of having plymouth and rc-local as dependencies. Are they meant to be dependencies or is the service file in error?

If none of these are in error, what could be stopping GDM from starting on boot?

Last edited by Bidski (2019-08-01 03:38:55)

jasonwryan · 2019-07-31 22:55:10

Please post the output of `systemctl list-unit-files --state=enabled` and `systemctl status gdm.service`

Moving to NC...

Bidski · 2019-07-31 23:03:50

This is from after tty login

$ systemctl list-unit-files --state=enabled
UNIT FILE                              STATE  
autovt@.service                        enabled
dbus-fi.w1.wpa_supplicant1.service     enabled
dbus-org.freedesktop.timesync1.service enabled
dhcpcd.service                         enabled
display-manager.service                enabled
gdm.service                            enabled
getty@.service                         enabled
systemd-timesyncd.service              enabled
wpa_supplicant.service                 enabled
remote-fs.target                       enabled

10 unit files listed.

$ systemctl status gdm.service
● gdm.service - GNOME Display Manager
   Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled; vendor preset: disabled)
   Active: inactive (dead)

This is from after I started GDM and logged in via the GUI

$ systemctl list-unit-files --state=enabled
UNIT FILE                              STATE  
autovt@.service                        enabled
dbus-fi.w1.wpa_supplicant1.service     enabled
dbus-org.freedesktop.timesync1.service enabled
dhcpcd.service                         enabled
display-manager.service                enabled
gdm.service                            enabled
getty@.service                         enabled
systemd-timesyncd.service              enabled
wpa_supplicant.service                 enabled
remote-fs.target                       enabled

10 unit files listed.

$ systemctl status gdm.service
● gdm.service - GNOME Display Manager
   Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2019-08-01 08:59:50 AEST; 41s ago
 Main PID: 784 (gdm)
    Tasks: 3 (limit: 4915)
   Memory: 7.2M
   CGroup: /system.slice/gdm.service
           └─784 /usr/bin/gdm

Aug 01 08:59:50 bidski-laptop systemd[1]: Starting GNOME Display Manager...
Aug 01 08:59:50 bidski-laptop systemd[1]: Started GNOME Display Manager.
Aug 01 09:00:00 bidski-laptop gdm-password][996]: gkr-pam: unable to locate daemon control file
Aug 01 09:00:00 bidski-laptop gdm-password][996]: pam_unix(gdm-password:session): session opened for user bidski by (uid=0)

jasonwryan · 2019-07-31 23:07:43

file /etc/systemd/system/display-manager.service

Bidski · 2019-07-31 23:08:44

$ file /etc/systemd/system/display-manager.service
/etc/systemd/system/display-manager.service: symbolic link to /usr/lib/systemd/system/gdm.service

jasonwryan · 2019-07-31 23:15:55

That all looks legit. Look through the journal to see if there are some clues as to why it is not starting.

loqs · 2019-07-31 23:17:06

systemctl get-default

Bidski · 2019-07-31 23:19:00

jasonwryan wrote:

That all looks legit. Look through the journal to see if there are some clues as to why it is not starting.

Any hints as to what I should look for? I am honestly at a loss with this.

$ systemctl get-default
multi-user.target

jasonwryan · 2019-07-31 23:23:00

https://wiki.archlinux.org/index.php/Sy … ing_output

Also, see the systemd page, notably:

The standard target is default.target, which is a symlink to graphical.target. This roughly corresponds to the old runlevel 5.

That would explain it not starting...

Bidski · 2019-07-31 23:30:47

$ journalctl -xb -p err..alert
-- Logs begin at Thu 2019-07-25 20:37:04 AEST, end at Thu 2019-08-01 09:22:07 AEST. --
Aug 01 08:59:01 bidski-laptop kernel: pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Uncorrected (Non-Fatal), t>
Aug 01 08:59:01 bidski-laptop kernel: pcieport 0000:00:1c.5: AER:   device [8086:9d15] error status/mask=00008000/000>
Aug 01 08:59:01 bidski-laptop kernel: pcieport 0000:00:1c.5: AER:    [15] CmpltAbrt              (First)
Aug 01 08:59:01 bidski-laptop kernel: pcieport 0000:00:1c.5: AER:   TLP Header: 00000000 00000000 00000000 00000000
Aug 01 09:00:00 bidski-laptop gdm-password][996]: gkr-pam: unable to locate daemon control file

$  journalctl -xb -u gdm.service 
-- Logs begin at Thu 2019-07-25 20:37:04 AEST, end at Thu 2019-08-01 09:22:07 AEST. --
Aug 01 08:59:50 bidski-laptop systemd[1]: Starting GNOME Display Manager...
-- Subject: A start job for unit gdm.service has begun execution
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- A start job for unit gdm.service has begun execution.
-- 
-- The job identifier is 364.
Aug 01 08:59:50 bidski-laptop systemd[1]: Started GNOME Display Manager.
-- Subject: A start job for unit gdm.service has finished successfully
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- A start job for unit gdm.service has finished successfully.
-- 
-- The job identifier is 364.
Aug 01 09:00:00 bidski-laptop gdm-password][996]: gkr-pam: unable to locate daemon control file
Aug 01 09:00:00 bidski-laptop gdm-password][996]: pam_unix(gdm-password:session): session opened for user bidski by (uid=0)

$ sudo  lspci -v -s 00:1c.5
00:1c.5 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #6 (rev f1) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 124
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
	I/O behind bridge: 00003000-00003fff [size=4K]
	Memory behind bridge: a4000000-a40fffff [size=1M]
	Prefetchable memory behind bridge: None
	Capabilities: [40] Express Root Port (Slot+), MSI 00
	Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
	Capabilities: [90] Subsystem: Hewlett-Packard Company Sunrise Point-LP PCI Express Root Port
	Capabilities: [a0] Power Management version 3
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [140] Access Control Services
	Capabilities: [200] L1 PM Substates
	Capabilities: [220] Secondary PCI Express <?>
	Kernel driver in use: pcieport

jasonwryan · 2019-07-31 23:32:05

jasonwryan wrote:

Also, see the systemd page, notably:
The standard target is default.target, which is a symlink to graphical.target. This roughly corresponds to the old runlevel 5.
That would explain it not starting...

Bidski · 2019-08-01 01:28:35

jasonwryan wrote:

jasonwryan wrote:
Also, see the systemd page, notably:
The standard target is default.target, which is a symlink to graphical.target. This roughly corresponds to the old runlevel 5.
That would explain it not starting...

Setting the default target to graphical.target fixed the issue. Should that have been set automatically by something?

jasonwryan · 2019-08-01 01:53:46

I would look back through your shell history and see that you didn't set it to multi-user at some point.

Please remember to mark your thread as [Solved] by editing your first post and prepending it to the title.

Brown · 2020-12-05 13:58:39

setting default target to graphical.target works for me too!

Bidski wrote:

jasonwryan wrote:
jasonwryan wrote:
Also, see the systemd page, notably:

That would explain it not starting...
Setting the default target to graphical.target fixed the issue. Should that have been set automatically by something?

Arch Linux

#1 2019-07-31 22:50:04

[SOLVED] GDM does not start on boot

#2 2019-07-31 22:55:10

Re: [SOLVED] GDM does not start on boot

#3 2019-07-31 23:03:50

Re: [SOLVED] GDM does not start on boot

#4 2019-07-31 23:07:43

Re: [SOLVED] GDM does not start on boot

#5 2019-07-31 23:08:44

Re: [SOLVED] GDM does not start on boot

#6 2019-07-31 23:15:55

Re: [SOLVED] GDM does not start on boot

#7 2019-07-31 23:17:06

Re: [SOLVED] GDM does not start on boot

#8 2019-07-31 23:19:00

Re: [SOLVED] GDM does not start on boot

#9 2019-07-31 23:23:00

Re: [SOLVED] GDM does not start on boot

#10 2019-07-31 23:30:47

Re: [SOLVED] GDM does not start on boot

#11 2019-07-31 23:32:05

Re: [SOLVED] GDM does not start on boot

#12 2019-08-01 01:28:35

Re: [SOLVED] GDM does not start on boot

#13 2019-08-01 01:53:46

Re: [SOLVED] GDM does not start on boot

#14 2020-12-05 13:58:39

Re: [SOLVED] GDM does not start on boot

Board footer