0

首先，对于一个可能很愚蠢的问题，我很抱歉，这是我第一次尝试与 Wayland 合作。但我用谷歌搜索，找不到任何相关的东西。

我开发的系统在运行图形应用程序时非常关键，所以我设法在 systemd 启动之前在 initramfs 步骤上运行 Weston 和所需的应用程序。一切都很好，除了“正常”应用程序，它们轮流从大文件系统运行，拒绝运行，返回“身份验证失败”错误 #3。

这是详细信息。

Initramfs 是基于busybox手工制作的。Weston 的一个应用程序和所需的库（包括 PAM 和其他它拒绝工作的东西）也被复制了。/dev是静态的，具有最少的节点集。/init是一个小型 sh 脚本，它挂载/proc、/run、/sys，运行 Weston 和应用程序，然后挂载主 rootfs 并使用switch_root()传递控制权。除此之外，我将现有的/run安装在/run_old下以保存 Wayland 的套接字。我不确定它是否正确完成，但是 systemd 覆盖了主 rootfs 中的/run，并且应该有一种访问服务器的方法，所以这以某种方式工作。

我还将“ wayland-0 ”套接字和“ wayland-0.lock ”从/run_old链接到主文件系统中的/run。

诊断软件（LayerManagerControl，weston-info）正在运行并显示有关服务器的信息，但是尝试输出图片的所有内容（因此使用/dev/dri/card0）都因上述错误而失败。

这是一段客户端应用程序 strace：

https://pastebin.com/1K3EDUhB

很明显，它正确附加/run/user/0/wayland-0，然后将 ioctl DRM_IOCTL_GET_MAGIC发送到/dev/dri/card0，然后将（？）魔法发送到服务器的套接字，然后输出失败.

从服务器端看，它看起来像这样：

https://pastebin.com/jkmeMzH7

这条线很有趣：

[pid  1107] ioctl(14, DRM_IOCTL_AUTH_MAGIC, 0xfffff92b32d0) = -1 EACCES (Permission denied)

处理 14 个指向（已删除）/dev/dri/card0的点。以下是所有打开的服务器句柄的列表：

https://pastebin.com/RTFNbEDW。

我唯一的线索是switch_root()在切换到主 rootfs 之前递归地删除了 initramfs 中的所有文件，包括/dev/dri/card0（它在带有“已删除”标记的列表中可见）。事实上，新应用程序已经与新的动态创建的 devtmpfs 通信。但我仍然无法理解它如何影响，因为手柄还活着！如果主要/次要编号相同，谁在乎我们确切拥有哪个设备节点以及安装它的时间？所以，线索不是最好的，我什至不知道如何正确检查它。

顺便说一下，这里还有一个 grepped 的服务器跟踪：

$ 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)

这里很清楚第一个图形应用程序正常授权，但后面的不是。

有任何想法吗？

4

1 回答 1

0

因此，原因是我系统上的启动画面在 /dev/dri/card0 上调用 DRM_IOCTL_DROP_MASTER（或 DRM_IOCTL_SET_MASTER），认为它首先运行。

于 2020-04-30T13:49:39.263 回答