web-dev-qa-db-ja.com

18.04にアップグレードした後、sddm / plasmaでOpenGLに問題が発生する

Kubuntuシステム(Nvidia GPUを備えたデスクトップワークステーション)を複数回アップグレードしましたが、nvidiaバイナリドライバーを使用しています。最近、18.04(バイオニック)にアップグレードした後、起動後にマウスカーソルで黒い画面に直面していました。どうやら、私は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

Question:これらのメッセージの原因は何ですか。また、デバッグを続行するにはどうすればよいですか

ここでは、より疑わしいものから始めて、関連する可能性のあるいくつかの事実を示します。

  • おそらく無関係:何らかの理由で、アップグレード後にnvidia-dockerを再び動作させるのに深刻な問題がありましたが、 /etc/nvidia-container-runtime/config.tomlを編集して/dev/nvidia0- owningグループに適応させることで修正できました
  • 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は私には正常に見えます。
  • Nvidia-dockerを使用しても使用しなくても、CUDAとGPUを使用して要求の厳しいプログラムを実行できます。
  • 私はプライムを使用していないnot; /usr/share/sddm/scripts/Xsetup/sbin/prime-offloadを実行します。これは/var/log/prime-offload.logに "Sorry but your hardware configuration are not supported"と書き込み、/var/log/prime-supported.logには "No offloading required。Abort"が含まれます

次の質問は私が抱えている同じ問題を指しているのではないかと思いますが、それらはすべて未解決であり、説明は完全に一致しませんでした(たとえば、ノートブックとデスクトップ)。私はゼロから始めて、問題が重複しているかどうかを(できれば)解決した後に決定することを好みました。

2
hans_meine

私はついに犯人を見つけました:問題は確かに/dev/nvidia*ファイルに対する誤った許可!によって引き起こされました!これらのファイルは、私が所属していたグループvglusersに属していました。ただし、明らかに、そのグループに含まれていないデーモン(色付き、sddm関連など)がいくつかあり、それが問題を引き起こしました。さらに、これらのファイルにデフォルトのアクセス許可を与えない理由はありません。

ただし、chmod/chgrpは明らかに動作するので(ls -lに従って)、修正する方法を見つけるのは非常に困難でしたが、デバイスはそれらを使用しました(sddmを再起動するときなど)。

過去のある時点で、virtualglをインストールしました。 (かなり前に)アンインストールすると、2つの構成ファイル、つまり/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)を実行しました。

これが将来、他の人々に役立つことを願っています。これをデバッグするには何時間も費やします!

0
hans_meine