FS#71937 - [lightdm] starts too early at boot

Attached to Project: Arch Linux
Opened by Stephan S (buzo) - Friday, 27 August 2021, 09:05 GMT
Last edited by Andreas Radke (AndyRTR) - Sunday, 13 February 2022, 09:36 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Maxime Gauduin (Alucryd)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Since I've switched to a newer graphic card, lightdm does not start any more at boot, because the (in my case) required kernel module amdgpu is not ready yet (especially /dev/dri/card0 and /dev/fb0 are still missing). When I restart lightdm.service manually it works flawlessly, but I have to do this after every reboot.

Package versions:
lightdm 1:1.30.0-4
lightdm-gtk-greeter 1:2.0.8-1
xorg-server 1.20.13-2
xorg-xwayland 21.1.2-1
xf86-video-amdgpu 21.0.0-1
xf86-video-fbdev 0.5.0-2

Excerpt from journal:

Aug 27 10:14:44 xyli kernel: amdgpu 0000:0a:00.0: amdgpu: use vbios provided pptable
Aug 27 10:14:44 xyli systemd[1]: lightdm.service: Scheduled restart job, restart counter is at 5.
Aug 27 10:14:44 xyli systemd[1]: Stopped Light Display Manager.
Aug 27 10:14:44 xyli audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=lightdm comm="
systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Aug 27 10:14:44 xyli audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=lightdm comm="s
ystemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Aug 27 10:14:44 xyli systemd[1]: lightdm.service: Start request repeated too quickly.
Aug 27 10:14:44 xyli systemd[1]: lightdm.service: Failed with result 'exit-code'.
Aug 27 10:14:44 xyli systemd[1]: Failed to start Light Display Manager.
Aug 27 10:14:44 xyli kernel: amdgpu 0000:0a:00.0: amdgpu: SMU is initialized successfully!
Aug 27 10:14:44 xyli kernel: [drm] Display Core initialized with v3.2.132!
[…]

Excerpt from Xorg.0.log:

[ 16.008] (EE) open /dev/dri/card0: No such file or directory
[ 16.008] (II) Loading sub module "fbdevhw"
[ 16.008] (II) LoadModule: "fbdevhw"
[ 16.008] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[ 16.008] (II) Module fbdevhw: vendor="X.Org Foundation"
[ 16.008] compiled for 1.20.13, module version = 0.0.2
[ 16.008] ABI class: X.Org Video Driver, version 24.1
[ 16.008] (EE) Unable to find a valid framebuffer device
[ 16.008] (WW) Falling back to old probe method for fbdev
[ 16.008] (II) Loading sub module "fbdevhw"
[ 16.008] (II) LoadModule: "fbdevhw"
[ 16.008] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[ 16.008] (II) Module fbdevhw: vendor="X.Org Foundation"
[ 16.008] compiled for 1.20.13, module version = 0.0.2
[ 16.008] ABI class: X.Org Video Driver, version 24.1
[ 16.009] (EE) open /dev/fb0: No such file or directory
[ 16.009] (EE) Screen 0 deleted because of no matching config section.
[ 16.009] (II) UnloadModule: "modesetting"
[ 16.009] (EE) Screen 0 deleted because of no matching config section.
[ 16.009] (II) UnloadModule: "fbdev"
[ 16.009] (II) UnloadSubModule: "fbdevhw"
[ 16.009] (EE) Device(s) detected, but none match those in the config file.
[ 16.009] (EE)
Fatal server error:
[ 16.009] (EE) no screens found(EE)
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Sunday, 13 February 2022, 09:36 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Arch way is to ship unchanged plain upstream configuration.
Comment by loqs (loqs) - Friday, 27 August 2021, 11:18 GMT Comment by Siegfried Metz (NiceGuy) - Friday, 27 August 2021, 14:30 GMT
Also get rid of xf86-video-fbdev (no *-vesa either) especially with a mighty AMD graphics card. :)
Comment by Stephan S (buzo) - Friday, 27 August 2021, 19:23 GMT
I tried [1], and that worked – thanks! How about changing the default config accordingly? I cannot think of any setup where not waiting for the graphics driver would make sense.

*-vesa was already gone, and I have removed *-fbdev now, too – thanks.

Loading...