☰

sddm / plasma 升级至 18.04 后出现 OpenGL 问题

tag-icon • tag-icon nvidia 18.04 kubuntu opengl
sddm / plasma 升级至 18.04 后出现 OpenGL 问题

我已经多次升级了我的 Kubuntu 系统（带有 Nvidia GPU 的桌面工作站），并且我正在使用 nvidia 二进制驱动程序。最近，在升级到 18.04（bionic）后，我遇到了黑屏启动后用鼠标光标。显然，我使用的是 sddm，调试时我发现/var/log/sddm.log包含

GREETER: Could not initialize GLX

我还发现了以下更详细的消息journalctl -e -t sddm-greeter：

Failed to create OpenGL context for format QSurfaceFormat(version 2.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 1, profile  QSurfaceFormat::OpenGLContextProfile(NoProfile))

我尝试卸载并重新安装了很多东西（例如，nvidia-driver-390所有与 nvidia 相关的东西），最后从 sddm 切换到 lightdm。现在，我可以登录了，但 KDE 也无法正常启动；消息是

Plasma is unable to start as it could not correctly use OpenGL 2. Please check that your graphics drivers are set up correctly.

当我手动启动 plasmashell 和 krunner 时，我开始得到一个可用的桌面，但 KDE 会话非常不稳定，经常闪烁和弹出

Desktop effects were restarted due to a graphics reset

问题：什么可能导致这些消息，我应该如何继续调试它？

以下是一些可能相关的事实，首先是比较可疑的事实：

  • 可能不相关：出于某种原因，我在升级后也遇到了严重的问题，无法让 nvidia-docker 再次工作，但可以通过以下方法解决这个问题：编辑/etc/nvidia-container-runtime/config.toml以适应我的/dev/nvidia0所属组。
  • lightdm 不会在启动时自动启动，但我可以这样做sudo service lightdm restart以获取登录屏幕。
  • 我听说 Ubuntu 从 vt7 上运行 X 改为 vt1，但在我的系统上它仍然在 vt7 上运行。不过，vt1 上没有运行文本模式登录。
  • 我在使用 DBUS 时也遇到了问题；例如，muon 无法通过 DBUS 联系身份验证代理（不过 dbus 守护进程似乎正在运行，因此问题可能再次出在 KDE 服务上）。

我检查了以下事项，发现它们完全没问题：

  • glxgears并且其他一些使用 GL 的程序似乎运行良好。
  • glxinfo似乎证实我正在成功使用 nvidia 驱动程序（现在是来自图形驱动程序 PPA 的 410 版本），并且我的显卡已经被识别。
  • 我测试过的一个非 KDE 应用程序 (MeVisLab) 能够OpenGL的高级使用并报告OpenGL版本4.6.0没有问题。
  • nvidia-settings看上去也很正常。
  • /var/log/Xorg.0.log在我看来很正常。
  • 我可以使用 CUDA 和 GPU 运行要求苛刻的程序，既可以通过 nvidia-docker 运行，也可以不使用 nvidia-docker 运行。
  • 我是不是使用 prime；/usr/share/sddm/scripts/Xsetup确实运行/sbin/prime-offload，这似乎将“抱歉，但您的硬件配置不受支持”写入/var/log/prime-offload.log，并/var/log/prime-supported.log包含“无需卸载。中止”

我认为以下问题可能指的是我遇到的相同问题，但它们都未得到解决，并且描述并不完全匹配（例如，笔记本电脑与台式机）。我宁愿从头开始，并在（希望）解决问题后决定它们是否重复：

答案1

我遇到了类似的错误。我故意禁用了 KDE 中的硬件合成（因为我遇到了 x11vnc 问题）。shell/窗口管理器坏了，这通常不是问题，我尝试重新启动：

kstart5 kwin --replace
killall plasmashell
kstart5 plasmashell

但是，plasmashell 无法正常启动。它弹出“Plasma 无法启动，因为它无法正确使用 OpenGL 2..”以及控制台中的以下内容：

failed to acquire GL context to resolve capabilities, using defaults..

我甚至无法运行systemsettings5（它会立即关闭并出现类似的有关 GL 的错误）。

一个快速的解决方案是使用软件合成（就像我最初打算的那样）：

kquitapp5 plasmashell && QT_QUICK_BACKEND=software kstart5 plasmashell

希望这可以节省某些人的工作量，直到他们可以重新启动并使一切与硬件合成一起工作。请注意，在使用 运行 shell 后QT_QUICK_BACKEND，通过其菜单启动的任何终端也将设置该环境。

答案2

我终于找到了罪魁祸首：问题确实是由/dev/nvidia*文件权限错误！这些文件属于 组vglusers，我是该组的成员。但是，显然有些守护进程（如 colord、sddm 相关进程，可能还有更多）不属于该组，这导致了问题。此外，这些文件没有理由不具有默认权限。

但是，很难找到修复该问题的方法，因为chmod/chgrp显然可以工作（根据ls -l），但是当我使用它们时（例如，重新启动 sddm 时），设备会神奇地恢复其权限。

过去，我曾安装过 virtualgl。卸载它（很久以前）留下了两个配置文件，即/etc/udev/rules.d/99-virtualgl-dri.rules包含

KERNEL=="card[0-9]", MODE="0660", OWNER="root", GROUP="vglusers"

并/etc/modprobe.d/virtualgl.conf包含

options nvidia NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=1005 NVreg_DeviceFileMode=0660

我删除了这两个文件，运行update-initramfs -u以使更改的选项生效，并且确实生效了delgroup vglusers（当然是 1005）。

我希望这能在未来帮助其他人；我花了（太）多时间来调试这个问题！

相关内容