sddm / плазма имеют проблемы с OpenGL после обновления до 18,04
Я обновил свою систему 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
Вопрос: Что может вызвать эти сообщения, и как я должен продолжить отлаживать это?
Вот некоторые факты, которые могут быть релевантными, начиная с более подозрительных:
- Вероятно, не связанный: По некоторым причинам я также имел серьезные проблемы, заставляя докера Nvidia работать снова после обновления, но мог зафиксировать это путем редактирования
/etc/nvidia-container-runtime/config.tomlадаптироваться к моему/dev/nvidia0- владеющая группа. - lightdm не запускается автоматически на начальной загрузке, но я могу сделать
sudo service lightdm restartдля получения экрана входа в систему. - Я услышал, что Ubuntu изменилась от выполнения X на vt7 к vt1, но в моей системе это все еще работает на vt7. Никакой вход в систему текстового режима не работает на vt1, все же.
- У меня также есть проблемы с DBUS; например, мюон не может связаться с агентом аутентификации через DBUS (dbus, демоны, кажется, работают, тем не менее, поэтому, возможно, проблемой являются снова сервисы KDE).
Следующие вещи, которые я проверил, выглядели превосходными мне:
glxgearsи некоторые другие использующие GL программы, кажется, хорошо работают.glxinfoкажется, подтверждает, что я использую драйвер Nvidia (теперь, версия 410 от графических драйверов PPA) успешно, и что моя видеокарта распознана.- non-KDE приложение, которое я протестировал (MeVisLab), может сделать усовершенствованное использование OpenGL и сообщает о версии 4.6.0 OpenGL без проблем.
nvidia-settingsтакже нормальные взгляды./var/log/Xorg.0.logвыглядит нормальным мне.- Я могу запустить требовательные программы с помощью CUDA и моего GPU, и через докера Nvidia и без.
- Я не использую главный;
/usr/share/sddm/scripts/Xsetupдействительно работает/sbin/prime-offload, который, кажется, пишет "Извините, но Ваша аппаратная конфигурация не поддерживается" в/var/log/prime-offload.log, и/var/log/prime-supported.logне содержит "Требуемой разгрузки. Аварийное прекращение работы"
Я думаю, что следующие вопросы могут относиться к той же проблеме, которую я имею, но они все не разрешены, и описания не соответствовали отлично (ноутбук по сравнению с рабочим столом, например). Я предпочел запускаться с нуля и решать после (надо надеяться), разрешения проблемы, являются ли они дубликатами:
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).
У меня была похожая ошибка. Я намеренно отключил аппаратный композитинг в KDE (поскольку у меня были проблемы с x11vnc). Оболочка/менеджер окон сломались, что обычно не является такой проблемой, и я попытался перезапустить:
kstart5 kwin --replace
killall plasmashell
kstart5 plasmashell
Однако плазменная оболочка не запустилась должным образом. Это дало всплывающее окно «Plasma не может запуститься, так как не может правильно использовать OpenGL 2..», а также следующее в консоли:
не удалось получить контекст GL для разрешения возможностей, используя значения по умолчанию..
I даже не мог запустить systemsettings5 (он сразу закрывался с аналогичной ошибкой про GL).
Быстрое решение состояло в том, чтобы начать с программного композитинга (как я и планировал изначально):
kquitapp5 plasmashell && QT_QUICK_BACKEND=software kstart5 plasmashell
Надеюсь, это сэкономит кому-то работу, пока они не перезагрузятся и не заставят все работать с аппаратным композитингом. Обратите внимание, что после запуска оболочки с помощью QT_QUICK_BACKEND любые терминалы, запущенные через ее меню, также будут иметь эту среду.