[SOLVED] Switching VT crashes Xorg after upgrade to Daedalus

Tritonio · 2023-08-16 15:12:20

Hi all. I had a really nice setup on Chimaera where I had one user for gaming and one for everything else. I had stopped using slim because I wanted to avoid having xorg running as root so instead my computer would require me to login on a virtual terminal (Ctrl+Alt+F1) and then I would run startx to start XFCE. This worked perfectly. Both users were able to run separate Xorgs on different virtual terminals and I could switch between them by Ctrl+Alt+F* at will.

After upgrading to Daedalus if I try to switch away from the first Xorg, even if I'm just switching to a plain virtual terminal and not another xorg, even if there's no other Xorg running, the first Xorg crashes and when I switch back to it (Ctrl+Alt+F1) I'm already dropped back at the console.

I found these in the xorg crash log in my user directory:

[  3132.705] (II) seatd_libseat try close /dev/input/event3 (27:27)
[  3132.706] (II) event3  - Video Bus: device removed
[  3132.744] (II) seatd_libseat try close /dev/input/event6 (30:30)
[  3132.745] (II) event6  - Power Button: device removed
[  3132.785] (II) seatd_libseat try close /dev/input/event5 (31:31)
[  3132.785] (II) event5  - Logitech Wireless Mouse: device removed
[  3132.844] (II) seatd_libseat try close /dev/input/event11 (32:32)
[  3132.844] (II) event11 - Integrated_Webcam_FHD: Integrat: device removed
[  3132.888] (II) seatd_libseat try close /dev/input/event2 (33:33)
[  3132.928] (II) seatd_libseat try close /dev/input/event9 (34:34)
[  3132.928] (II) event9  - (redacted by me) Touchpad: device removed
[  3132.992] (II) seatd_libseat try close /dev/input/event1 (35:35)
[  3132.992] (II) event1  - Dell WMI hotkeys: device removed
[  3133.036] (II) seatd_libseat try close /dev/input/event0 (36:36)
[  3133.037] (II) event0  - AT Translated Set 2 keyboard: device removed
[  3133.072] (II) seatd_libseat try close /dev/input/event4 (37:37)
[  3133.128] (II) seatd_libseat try close /dev/input/event8 (38:38)
[  3133.128] (II) event8  - DELL Wireless hotkeys: device removed
[  3133.176] (II) seatd_libseat try close /dev/input/event14 (39:39)
[  3133.177] (II) event14 - BRLTTY 6.6 Linux Screen Driver Keyboard: device removed
[  3133.204] (II) AIGLX: Suspending AIGLX clients for VT switch
[  3134.008] (II) AIGLX: Resuming AIGLX clients after VT switch
[  3134.008] (EE) AMDGPU(0): failed to set mode: Permission denied
[  3134.008] (WW) AMDGPU(0): Failed to set mode on CRTC 0
[  3134.008] (EE) AMDGPU(0): Failed to enable any CRTC
[  3134.008] (EE) 
Fatal server error:
[  3134.008] (EE) EnterVT failed for screen 0

I saw in the release notes for Daedalus that there some changes around running xorg as non-root but I don't understand how they apply to me since I do not use any login manager like elogind, nor do I want to start using one if that's possible. But I do have elogind installed because it's a dependency of digiKam. I'd rather just use startx after having logged in on the console. My user is a member of the video group, I checked again. I'm not sure why I get this: "AMDGPU(0): failed to set mode: Permission denied"

Any ideas? Am I unknowingly using a login manager?

Thank you!

EDIT: I tried installing seatd and now I can switch out of my active xorg and into a VT but it will fail to start a second Xorg under a different user account. I removed it again for now since I think just solving the permission denied issue will make everything as it was before the upgrade.

Last edited by Tritonio (2023-08-16 15:56:00)

fsmithred · 2023-09-23 14:34:50

I can confirm your findings. I have a similar setup but with lxqt instead of xfce and no display manager, and with elogind and seatd installed. Ctrl-alt-F2 drops to console.
Adding a second user, dropping to console to login as that user works, but then startx -- :1 fails.

Here are the Xorg log errors.

[  1363.893] (EE) [libseat/backend/seatd.c:66] Could not connect to socket /run/seatd.sock: Permission denied
[  1364.045] (EE) [libseat/backend/logind.c:137] Could not take device: Device or resource busy
[  1364.045] (EE) seatd_libseat open graphics /dev/dri/card0 (-1) failed: -11
[  1364.086] (EE) Failed to load module "psb" (module does not exist, 0)
[  1364.088] (EE) Failed to load module "psbdrv" (module does not exist, 0)
[  1364.103] (EE) Unable to find a valid framebuffer device
[  1364.105] (EE) open /dev/fb0: Permission denied
[  1364.106] (EE) Screen 0 deleted because of no matching config section.
[  1364.106] (EE) Screen 1 deleted because of no matching config section.
[  1364.107] (EE) Screen 1 deleted because of no matching config section.
[  1364.511] (EE) modeset(0): drmSetMaster failed: Permission denied
[  1364.511] (EE) 
[  1364.511] (EE) AddScreen/ScreenInit failed for driver 0
[  1364.511] (EE) 
[  1364.531] (EE) Server terminated with error (1). Closing log file.

ralph.ronnquist · 2023-09-23 23:19:26

There are a couple of issues at play here.

Firstly, that the Xserver was modified to obtain its input streams via a mediating process, either logind or seatd. When neither is available, there is a builtin seatd implementing mediation, and that requires the running user to have access to the input devices (typically group "input") and graphics (typically group video"). (Or being root).

Secondly, there is a bug in the daedalus Xserver version concerning USB keyboards. #793. This was recently fixed and published in version 21.1.8-1devuan2, which is available in excalibur but not yet backported to daedalus.

Note that the introduction of input access mediation in Debian brought in systemd (systemd-logind) to X, and that caused a fair bit of work to handle. In particular to untie the bind to logind and offer seatd as alternative, including the built-in variant that in principle should offer the legacy use (where the Xorg user has direct access rights to both graphics and inputs). Notably seatd is only concerned with input mediation and it does not extend to any of the other functions provided by logind (login manager, lid switch action, etc etc).

Thus, in short, Xorg is now forked and the daedalus version (2:21.1.7-3devuan1) is the first fork release. It has issues with VT switching and this might be resolved in the upcoming version 2:21.1.8-1devuan2 which should find its way to daedalus fairly soon.

ralph.ronnquist · 2023-09-23 23:28:55

@fsmithred, your second user doesn't have access to graphics, and you also need to direct Xorg to the VT concerned as it otherwise will try to use "the next free", an action that requires root permission (or more specifically access to /dev/ttyN for VT N).

Thus, with graphics access, you might have success with startx -- :1 vt$(tty|tr -c -d '[0-9]')
That last bit is vtN where N is the number in the output of the tty command.

Tritonio · 2023-09-25 07:40:12

Thanks for the confirmation @fsmithred.

Does any of these changes affect the ability of one user to keylog the other user when both users run X servers? Without a mediation process like seatd/logind or with any of them.

And while we're at it, since both users have video membership, does that mean that even when switching away from their X, a process under such a user can capture the screen of the other user?

@ralph.ronnquist I tried the command you posted but it unfortunately didn't work. The second user isn't a member of input btw. First it tried with seatd and failed with "Could not poll connection: Broken pipe" then it tried with logind and it failed with "Could not take device: Device or resource busy"

ralph.ronnquist · 2023-09-25 09:10:55

If seatd or logind (elogind) are running as system services they will be able mediate input access for a non-root user running Xorg. If not, then the users must themselves be in input group for accessing the input devices.

The Devuan fork expands the logind method with the seatd alternative, and it includes the "built-in seatd" variant to cater for the legacy use where the Xorg user has sufficient access to both graphics and inputs.

Unfortunately Xorg at daedalus is slightly broken around some VT switch scenarios. It that has got fixed for the current excalibur version and I think/hope this version is going to turn up for daedalus soonish.

I'm not an expert on this but afaiui key logging can't really happen merely with device node access but would be done via event capture within X. Still I believe the idea of restricting device node access for input devices is based on security reasoning.

I don't know whether and how the graphics device separates the displays of different Xorg.

Tritonio · 2023-09-25 10:27:09

So the build-in seatd works only for users that have both input and graphics access? None of my regular users have input group membership so I guess this built-in doesn't come into play here. Just to confirm that I understand correctly, back i Chimaera my X was using logind for input mediation and that let me startx under different users at the same time (I was not passing any arguments to startx either). Now there seem to be three problems in Daedalus:

startx(logind) now crashes when switching to another VT, so I cannot test what would happen if a second startx(logind) session was started. I assume it would work fine like in Chimaera.
startx(logind) fails with "Device or resource busy" if there is a startx(seatd) session already running under another user.
startx(seatd) fails with "Broken pipe" if there is a startx(seatd) session already running under another user.

ralph.ronnquist · 2023-09-27 21:33:17

Note that the VT switching patch for xserver-xorg-core has been applied for daedalus.

A normal upgrade brings it in, if your sources.list includes daedalus-proposed-updates.

fsmithred · 2023-09-27 22:51:42

That fixed it. Thanks! I can start a second xserver as another user.

I pinned daedalus-proposed-updates to a lower priority so that I had to specify that I wanted xserver-xorg-core. I got that package and xserver-common without getting other stuff that's currently in proposed-updtaes. I saw some pam stuff and wanted to make sure that just these two packages were needed.

semil · 2023-09-28 13:03:49

I as well don’t want whatever else happens to be in daedalus-proposed-updates. How would I set my pinning properly?

I looked around and found apt_preferences(5), and I think I have an idea of what to do for Package and Pin-Priority, but it is not obvious what would be correct for Pin: release a= or n= to correspond to daedalus-proposed-updates.

I don’t want to get it wrong and make a mess and need more help to undo it all.

ralph.ronnquist · 2023-09-28 13:33:25

Add the file /etc/apt/preferences.d/reluctant-daedalus-proposed-updates
Package: *
Pin: release n=daedalus-proposed-updates
Pin-Priority: 90

(any file in that directory)

That pinning makes packages from daedalus-proposed-updates only installable on demand. Eg.

# apt-get install --no-install-recommends -t daedalus-proposed-updates \
    xserver-xorg-core xserver-common

semil · 2023-09-29 01:58:39

Thanks!

Tritonio · 2023-10-09 08:55:19

I think I just got the update in the main repositories!

EDIT: works great for me now! Many many thanks!

Last edited by Tritonio (2023-10-09 11:52:54)

The officially official Devuan Forum!

#1 2023-08-16 15:12:20

[SOLVED] Switching VT crashes Xorg after upgrade to Daedalus

#2 2023-09-23 14:34:50

Re: [SOLVED] Switching VT crashes Xorg after upgrade to Daedalus

#3 2023-09-23 23:19:26

Re: [SOLVED] Switching VT crashes Xorg after upgrade to Daedalus

#4 2023-09-23 23:28:55

Re: [SOLVED] Switching VT crashes Xorg after upgrade to Daedalus

#5 2023-09-25 07:40:12

Re: [SOLVED] Switching VT crashes Xorg after upgrade to Daedalus

#6 2023-09-25 09:10:55

Re: [SOLVED] Switching VT crashes Xorg after upgrade to Daedalus

#7 2023-09-25 10:27:09

Re: [SOLVED] Switching VT crashes Xorg after upgrade to Daedalus

#8 2023-09-27 21:33:17

Re: [SOLVED] Switching VT crashes Xorg after upgrade to Daedalus

#9 2023-09-27 22:51:42

Re: [SOLVED] Switching VT crashes Xorg after upgrade to Daedalus

#10 2023-09-28 13:03:49

Re: [SOLVED] Switching VT crashes Xorg after upgrade to Daedalus

#11 2023-09-28 13:33:25

Re: [SOLVED] Switching VT crashes Xorg after upgrade to Daedalus

#12 2023-09-29 01:58:39

Re: [SOLVED] Switching VT crashes Xorg after upgrade to Daedalus

#13 2023-10-09 08:55:19

Re: [SOLVED] Switching VT crashes Xorg after upgrade to Daedalus

Board footer