Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#64383 - [xorg][systemd] Failed to start X: systemd-logind Operation not permitted

Attached to Project: Arch Linux
Opened by Maksym (Maksym) - Monday, 04 November 2019, 11:58 GMT
Last edited by Christian Hesse (eworm) - Saturday, 08 February 2020, 16:03 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Dave Reisner (falconindy)
Christian Hesse (eworm)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No



Bug appears randomly. Probability 50%.

X server bail out with the message:

(EE) systemd-logind: failed to take device /dev/dri/card0: Operation not permitted
Unable to retrieve master
Fatal server error:
(EE) AddScreen/ScreenInit failed for driver 0

The system updated recently: 04-Nov-2019

Steps to reproduce:
1. No special steps. Just run startx.

After `systemctl restart systemd-logind.service` X server starts OK.
   logs.7z (44.5 KiB)
This task depends upon

Closed by  Christian Hesse (eworm)
Saturday, 08 February 2020, 16:03 GMT
Reason for closing:  Fixed
Additional comments about closing:  systemd-244.2-2
Comment by loqs (loqs) - Monday, 04 November 2019, 12:11 GMT
A bug introduced in systemd 243 please report upstream.
As a workaround enabling early KMS [1] or running X as root [2]

Comment by Maksym (Maksym) - Tuesday, 05 November 2019, 08:49 GMT
Thank you for workaround. Early-KMS-start works for me. I will report bug to systemd.
Comment by Maksym (Maksym) - Tuesday, 05 November 2019, 08:50 GMT Comment by Fedor Dostoyevskiy (bachtiar) - Tuesday, 10 December 2019, 10:33 GMT
I am also affected by this.
It seems that the "Operation not permitted" on /dev/dri/card0 is caused by pacman hook being skipped when running inside arch-chroot. The problem only appears for non-root users (i.e. root can always run startx successfully).

From pacman.log:

[ALPM] running '30-systemd-daemon-reload.hook'...
[ALPM-SCRIPTLET] Running in chroot, ignoring request: daemon-reload

(a) Install xorg on already installed/running system (i.e. "pacman -S xorg xorg-xinint" not in arch-chroot). The hook succeeds and the problem is gone - startx works.
(b) Manually run "systemctl daemon-reload" on a system which is already installed/running.
(c) On already installed/running system, install some other (unrelated) package that will trigger this hook (example: polkit).

Possibly related:

Just out of curiosity - how was this chicken-and-egg situation supposed to work and why did it break?
Comment by loqs (loqs) - Wednesday, 08 January 2020, 00:57 GMT