web-dev-qa-db-fra.com

sddm / plasma rencontre des problèmes avec OpenGL après la mise à niveau vers 18.04

J'ai mis à niveau mon système Kubuntu (station de travail de bureau avec GPU Nvidia) plusieurs fois et j'utilise le pilote binaire nvidia. Récemment, après la mise à niveau vers 18.04 (bionique), je faisais face à un écran noir avec un curseur de souris après le démarrage. Apparemment, j'utilisais sddm et, en déboguant, j'ai trouvé /var/log/sddm.log contenu

GREETER: Could not initialize GLX

J'ai également trouvé le message suivant plus détaillé utilisant 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))

J'ai essayé de désinstaller et de réinstaller de nombreuses choses (par exemple, nvidia-driver-390 et tout ce qui concerne nvidia), puis je suis passé de sddm à lightdm. Maintenant, je pourrais me connecter, mais KDE ne démarrerait pas non plus correctement; le message est

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

Lorsque je lance manuellement Plasmashell et Krrner, je commence à obtenir un bureau utilisable, mais une session KDE très instable avec un clignotement fréquent et une fenêtre contextuelle.

Desktop effects were restarted due to a graphics reset

Question: Quelle peut être la cause de ces messages et comment dois-je continuer à en déboguer?

Voici quelques faits pertinents, à commencer par les plus suspects:

  • Probablement sans lien: Pour une raison quelconque, j'ai également eu de gros problèmes pour que nvidia-docker fonctionne à nouveau après la mise à niveau, mais je pouvais résoudre ce problème en en modifiant /etc/nvidia-container-runtime/config.toml pour l'adapter à mon groupe propriétaire /dev/nvidia0- .
  • lightdm ne démarre pas automatiquement au démarrage, mais je peux utiliser Sudo service lightdm restart pour obtenir un écran de connexion.
  • J'ai entendu dire qu'Ubuntu ne fonctionnait plus sous vt7 sur vt7, mais sur mon système, il fonctionnait toujours sur vt7. Aucune connexion en mode texte n'est en cours d'exécution sur vt1.
  • J'ai aussi des problèmes avec DBUS; Par exemple, muon ne peut pas contacter un agent d'authentification via DBUS (les démons dbus semblent en cours d'exécution, alors le problème concerne peut-être à nouveau les services KDE).

Les choses suivantes que j’ai vérifiées me paraissaient parfaitement bien:

  • glxgears et certains autres programmes utilisant GL semblent fonctionner correctement.
  • glxinfo semble confirmer que j'utilise correctement le pilote nvidia (maintenant la version 410 du pilote graphique PPA) et que ma carte graphique est reconnue.
  • Une application non-KDE que j'ai testée (MeVisLab) est capable de faire une utilisation avancée d'OpenGL et de signaler OpenGL version 4.6.0 sans problème.
  • nvidia-settings semble également normal.
  • /var/log/Xorg.0.log me semble normal.
  • Je peux exécuter des programmes exigeants avec CUDA et mon GPU, via nvidia-docker et sans.
  • Je suis pas en utilisant prime; /usr/share/sddm/scripts/Xsetup exécute /sbin/prime-offload, qui semble écrire "Désolé, mais votre configuration matérielle n'est pas prise en charge" dans /var/log/prime-offload.log, et /var/log/prime-supported.log contient "Pas de déchargement requis. Abandonner"

Je pense que les questions suivantes concernent peut-être le même problème que moi, mais elles sont toutes non résolues et les descriptions ne correspondent pas parfaitement (cahier à ordinateur de bureau, par exemple). J'ai préféré commencer à partir de zéro et décider après (espérons-le) résoudre le problème s'il s'agit de doublons:

nvidia18.04kubuntuopengl
2
hans_meine

J'ai finalement trouvé le coupable: Les problèmes ont bien été causés par permissions erronées sur les fichiers /dev/nvidia*! Ces fichiers appartenaient au groupe vglusers dont je faisais partie. Cependant, apparemment, certains démons (comme colord, liés à sddm, probablement plus) ne faisaient pas partie de ce groupe et cela a posé problème. De plus, il n’ya aucune raison pour que ces fichiers ne disposent pas des autorisations par défaut.

Cependant, il était assez difficile de trouver une solution à ce problème, car chmod/chgrp fonctionnerait apparemment (selon ls -l), mais les autorisations de ces périphériques seraient modifiées comme par magie lorsque Je les ai utilisés (par exemple lors du redémarrage de sddm).

A un moment dans le passé, j'avais virtualgl installé. La désinstallation qui (jadis) laissait deux fichiers de configuration, à savoir /etc/udev/rules.d/99-virtualgl-dri.rules qui contenait

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

et /etc/modprobe.d/virtualgl.conf contenu

options nvidia NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=1005 NVreg_DeviceFileMode=0660

J'ai enlevé les deux fichiers, lancé update-initramfs -u afin de permettre aux options modifiées de prendre effet et ai fait delgroup vglusers (qui était 1005, bien sûr).

J'espère que cela aidera d'autres personnes à l'avenir; Je passe (trop) de nombreuses heures à déboguer ça!

0
hans_meine