First of all, sorry for a potentially silly question, it’s my first attempt to work with Wayland. But i’ve googled and could not find anything related.
The system which i develop, is very time-critical in running graphicall applications, so i’ve managed to run Weston and the desired application on initramfs step before systemd starts. Everything went fine, except that “normal” applications, which on their turn run from big filesystem, refuse to run, returning “Authentication failed” error #3.
Here are the details.
Initramfs was manually crafted and based on busybox. Weston with one application and needed libraries (including PAM and other stuff without which it was refusing to work) were also copied. /dev is static, with minimal set of nodes. /init is a small sh-script, which mounts /proc, /run, /sys, runs Weston and the application, then mounts main rootfs and passes control using switch_root(). Besides that, i mount the existing /run under /run_old to save Wayland’s socket. I’m not sure if it’s done correctly, but systemd overwrites /run in the main rootfs, and there should be a way to access the server, so this is working somehow.
I also link “wayland-0” socket and “wayland-0.lock” from /run_old to /run in the main filesystem.
The diagnostinc software (LayerManagerControl, weston-info) is working and show the information regarding the server, but everything which tries to output a picture (hence using /dev/dri/card0), fails with the overmentioned error.
Here is a piece of client application strace:
It’s clear that it correctly attaches /run/user/0/wayland-0, then it sends ioctl DRM_IOCTL_GET_MAGIC to /dev/dri/card0, then sends (?) magic to the socket of the server, which in its turn outputs a failure.
From the server’s side it looks like this:
This line is interesting:
[pid 1107] ioctl(14, DRM_IOCTL_AUTH_MAGIC, 0xfffff92b32d0) = -1 EACCES (Permission denied)
Handle 14 points to (already deleted) /dev/dri/card0. Here is the list of all open server’s handles:
https://pastebin.com/RTFNbEDW.
The only clue i have, is that switch_root() before switching to the main rootfs recursively removes all files in the initramfs, including /dev/dri/card0 (it’s visible in the list with “deleted” mark). And in fact the new applications already communicate with the new dynamically created devtmpfs. But i still cannot understand how it can influence, because the handle is still alive! And who matters which device node we have exactly and in which moment it has been mounted, if major/minor numbers are the same? So, the clue is not the best, and i even don’t know how to check it correctly.
By the way, here is one more grepped piece of the servers trace:
$ grep "AUTH_MAGIC" strace-wayland-log [pid 1107] ioctl(14, DRM_IOCTL_AUTH_MAGIC, 0xfffff92b32d0) = 0 [pid 1107] ioctl(14, DRM_IOCTL_AUTH_MAGIC, 0xfffff92b32d0) = -1 EACCES (Permission denied) [pid 1107] ioctl(14, DRM_IOCTL_AUTH_MAGIC, 0xfffff92b32d0) = -1 EACCES (Permission denied) [pid 1107] ioctl(14, DRM_IOCTL_AUTH_MAGIC, 0xfffff92b32d0) = -1 EACCES (Permission denied) [pid 1107] ioctl(14, DRM_IOCTL_AUTH_MAGIC, 0xfffff92b32d0) = -1 EACCES (Permission denied) [pid 1107] ioctl(14, DRM_IOCTL_AUTH_MAGIC, 0xfffff92b32d0) = -1 EACCES (Permission denied)
Here it’s quite clear that the first graphical application authorizes normally, but not the following ones.
Any ideas?
Advertisement
Answer
So, the reason was that Splash screen on my system was calling DRM_IOCTL_DROP_MASTER (or DRM_IOCTL_SET_MASTER) on /dev/dri/card0 believing that it’s run first.