Заранее прошу прощения за потенциально ламерский вопрос. Это мой первый опыт работы с Wayland.
Система, которую я разрабатываю, очень критична по времени запуска графической подсистемы, поэтому возникла идея запускать Weston и нужное приложение ещё на этапе initramfs. Желаемое получилось, но внезапно появилась проблема запуска остальных приложений, из «основного» юзерспейса, а именно они отказываются запускаться, возвращая ошибку «Authentication Failed» под номером 3.
Вот подробности.
Initramfs была собрана вручную, на базе busybox. Weston с приложением и либами были тоже скопированы (включая либы PAM и прочий мусор, без которого не взлетело). /dev статичен, с минимумом необходимых нод. /init представляет собой маленький sh-скрипт, который монтирует /proc, /run, /sys, запускает Weston и приложение, а потом монтирует основной корень и передаёт туда управление через switch_root(). Помимо этого, я монтирую в новую ФС существующий /run под именем /run_old, чтобы спасти сокет Wayland’a. Я не уверен, что последнее сделано правильно, но systemd в основной ФС затирает содержимое /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, дальше шлёт (?) magic в сокет сервера, который уже посылает приложение нафиг.
Со стороны сервера всё выглядит так:
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() перед переключением на основную ФС рекурсиво удаляет все файлы в initramfs, включая /dev/dri/card0 (это видно выше по пометке «(deleted)»). И по факту новые приложения уже общаются с другим, динамически созданным devtmpfs. Но я не понимаю, как это должно влиять, так как хендл-то у нас всё равно жив, да и какая разница, какая у нас нода устройства и когда она примонтирована, если Major/Minor номера совпадают! В общем, зацепка так себе, и я даже не знаю, как её нормально проверить. Неактуально
Кстати, вот ещё грепнутый кусок трассировки сервера:
$ 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)
Видно, что первое граф. приложение (из initramfs) авторизуется нормально, но не последующие.
Есть идеи, куда копать?
UPD:
в общем, я монтирую devtmpfs вместо статического /dev, оно правильно переносится в основную rootfs, все хендлы живы, в /proc/x/FD никаких удалённых файлов. Тем не менее, продолжаем иметь ту же проблему