You are not logged in.
Do you have the same problem when you create a new user account?
Sadly yes
I created a user with home directory, set a password for the user, added it to the wheel group (which is uncommented in sudoers file). Then I started sddm, logged into that user account and started an openbox session. Executed startplasma-x11 and got exactly the same error.
Offline
**ggrrrrrrr**
May 15 13:06:39 Zafkiel systemd[1]: Starting User Runtime Directory /run/user/0...
May 15 13:06:39 Zafkiel systemd-logind[741]: New session 1 of user root.
May 15 13:06:39 Zafkiel systemd[1]: Finished User Runtime Directory /run/user/0.
So the runtime dir gets created for your root login, but not kavex (from sddm)
When you login in as kavex on the console, do you get "echo $XDG_RUTIME_DIR" then?
Offline
echo $XDR_RUNTIME_DIR
Exectuted as the kavex user results in
/run/user/1000
Edit: I think I misunderstood your question. Will try to login as kavex user and then check journalctl for the specified lines
Edit: I don't think so. Instead it says now
Mai 17 16:14:41 Zafkiel systemd[1]: Created slice User Slice of UID 1000.
Mai 17 16:14:41 Zafkiel systemd[1]: Starting User Runtime Directory /run/user/1000...
Mai 17 16:14:41 Zafkiel systemd-logind[1566]: New session 1 of user kavex.
Mai 17 16:14:41 Zafkiel systemd[1]: Finished User Runtime Directory /run/user/1000.
My full journalctl -b of that login attempt is here for refference
Last edited by kavex (2022-05-17 14:22:19)
Offline
No, I was curious whether you'd have a proper $XDR_RUNTIME_DIR on a console login and that seems to be the case.
So it's not user specific, limited to (at least some) DM logins and kills $XDR_RUNTIME_DIR (only), yet it seems pam_systemd is still invoked (by at least the SDDM journals)
Let's draw the broadsword:
sudo grep -r XDG_RUNTIME_DIR /etc
Offline
sudo grep -r XDG_RUNTIME_DIR /etc
Gives me
/etc/speech-dispatcher/speechs.conf:# $XDG_RUNTIME_DIR/speech-dispatcher/speechd.sock where $XDR_RUNTIME_DIR
Last edited by kavex (2022-05-18 10:28:01)
Offline
So dead-end
https://cdn.shopify.com/s/files/1/0411/ … _1021x.png
sudo grep -r XDG_RUNTIME_DIR /usr
Offline
sudo grep -r XDG_RUNTIME_DIR /usr
This is what I got
Sorry, I am using the german locale. "Übereinstimmung in Binärdatei" means "match in binary"
Last edited by kavex (2022-05-18 14:19:30)
Offline
But "Übereinstimmung in Binärdatei" isn't in that file - is this only some partial output?
I'm blaming flatpak/xdg-portal-whatever.
I can't prove it, but there's no indication what might cause this, so in doubt: flatpak's fault.
Offline
But "Übereinstimmung in Binärdatei" isn't in that file - is this only some partial output?
Yeah, I got a few lines in the terminal showing a path and then "Übereinstimmung in Binärdatei". I think that was just whenever it found something to add to the actual output.
I'm blaming flatpak/xdg-portal-whatever.
I can't prove it, but there's no indication what might cause this, so in doubt: flatpak's fault.
So there is nothing I can do to fix it? Should I reinstall flatpak, or should I even try to reinstall my system?
Offline
Remove flatpak and the xdg-portal* packages. See what happens.
Before you need to think abotu what action to take, we need to confirm my morally less-than-impeccable accusal…
Offline
So I uninstalled flatpak and every package that contained xdg and portal in its name.
I then started sddm, logged into an openbox session and still the same error.
Except for 2 new lines
kf.service.services: The desktop entry file "/usr/share/applications/qemu.desktop has Type= "Application" but no Exec line
kf.service.sycoca: Invalid Service : "/usr/share/applications/qemu.desktop"
Offline
every package that contained xdg and portal in its name
That does hopefully not include xdg-utils or xdg-user-dirs?
But at this point I'm unfortunately out of ideas how you could have gotten to this state.
pam_systemd doesn't work properly in the context of some DMs, but there's no explanation as to "why".
Offline
That does hopefully not include xdg-utils or xdg-user-dirs?
No, I didn't uninstall those
Do you think trying to reinstall arch will fix anything? I am scared that if I do it it won't change anything
And I know reinstalling is windows morale, but if we are out of ideas, what else could we do?
Edit: Reinstalled the system and everything now. Still the exact same error.
Edit: So I don't know if this is relevant, but if I type "xrandr -q" I only get "Can't open display"
Edit: I went with manjaro on encrypted lvm. I let calamares install manjaro on a partition on my disk and then moved the system via live system onto lvm volumes which are sitting on encrypted partitions. This way the graphics work out of the box.
I will retvisit the arch zfs installation after some updates probably. Until then, I shall mark this thread as solved so it doesn't pollute the board.
Last edited by kavex (2022-05-20 21:37:59)
Offline