Драйвер Nvidia ломает vncserver на CentOS 7.4, есть ли обходной путь?

TurboVNC + VirtualGL - хорошая альтернатива.

Плюсы:

• Хорошая производительность.
• Работает с рабочими средами, требующими 3D-ускорения ( например, Gnome3), с-3dwm,
• Удаленный 3D-рендеринг работает даже с безголовыми графическими процессорами.

Минусы в том, что это может быть сложно настроить. Я только что закончил установку на CentOS 7 и NVidia K80. Я сомневаюсь, что мой конфиг идеален, но вот несколько моментов, которые я хотел бы выделить:

1. Официальные руководства ( 1, 2, 3, 4) могут показаться слишком длинными и пугающими на первый взгляд, но за ними довольно легко следовать. Они действительно пропускают некоторые важные фрагменты информации ( 1, 2, 3, 4).

2. Я использовал драйверы kmod-nvidia от elrepo, занесенные в черный списокnouveau с двумя строчкамиecho -e "blacklist nouveau\noptions nouveau modeset=0" > /etc/modprobe.d/disable-nouveau.confне с одной строкой, как предложено во многих других руководствах ( 1, 2).

3. Проверка следующих журналов является хорошей отправной точкой, когда что-то идет не так: /var/log/messages,/var/log/Xorg.0.log,~/.vnc/*.log, Большинство сообщений об ошибках, с которыми я столкнулся, уже обсуждены и довольно просты для Google.

4. Обратите внимание наxdpyinfo -display :0проверка работоспособности там. Если это не работает, попробуйте ответитьn / n / nвvglserver_configи отключение selinux. Также лично я в итоге заменилgdmсlightdm,

5. Хотя в целом Gnome3 работает нормально, время от времени случаются некоторые странные ошибки (например, Firefox работает, но открытие загруженного архива с помощью встроенного менеджера архивации завершается неудачно с такой ошибкой). Итак, я закончил установку плазмы KDE, так что -3dwm больше не нужен. (Но я все еще люблю сервер TurboVNC, потому что он быстрый).

Насколько я понимаю, основная причина в том, что NVIDIA устанавливает свои собственные библиотеки GL, которые нарушают другие X-среды.

$ ldd /usr/bin/Xvnc | egrep GL
libGL.so.1 => /lib64/libGL.so.1 (0x00007f7ed8f5b000)

Обман - перемычка NVIDIA libGL.so путем направления vncserver в /usr/lib64 ДО /usr/lib64/nvidia:

$ diff -cbtw /usr/bin/vncserver*
*** /usr/bin/vncserver  2018-12-08 11:07:14.871180204 -0500
--- /usr/bin/vncserver.rhel71   2014-03-10 12:17:32.000000000 -0400
***************
*** 216,223 ****

  # Now start the X VNC Server

! $cmd = "export LD_LIBRARY_PATH=/usr/lib64:$LD_LIBRARY_PATH ; ";
! $cmd .= $exedir."Xvnc :$displayNumber";
  $cmd .= " -desktop " . &quotedString($desktopName);
  $cmd .= " -httpd $vncJavaFiles" if ($vncJavaFiles);
  $cmd .= " -auth $xauthorityFile";
--- 216,222 ----

  # Now start the X VNC Server

! $cmd = $exedir."Xvnc :$displayNumber";
  $cmd .= " -desktop " . &quotedString($desktopName);
  $cmd .= " -httpd $vncJavaFiles" if ($vncJavaFiles);
  $cmd .= " -auth $xauthorityFile";
[merc_user@pair-1-host ~]$

Это работает для меня с Red Hat 7.1 и CUDA 9-2.

Чтобы продолжить работу над проблемой NVIDIA и нативной графики с проблемой NVIDIA libGL, я сделал следующие читы:

$ mv /usr/sbin/gdm /usr/sbin/gdm.bin
$ mv /usr/bin/Xorg /usr/bin/Xorg.bin
$ # make edits - show results 
$ cat /usr/sbin/gdm
#!/bin/sh
#
# workaround for libGL issue
#

LD_LIBRARY_PATH=/usr/lib64:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH

exec /usr/sbin/gdm.bin "$@"
$ cat /usr/bin/Xorg
#!/bin/sh
#
# workaround libGL issue
#

LD_LIBRARY_PATH=/usr/lib64:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH

exec /usr/bin/Xorg.bin "$@"

Вот мое решение для машины Fedora 29. Я считаю, что это не зависит от дистрибутива.
Переместите или скопируйте дистрибутивные версии libGL в /usr/local/vnclib:

$ ls -l /usr/local/vnclib
total 596
lrwxrwxrwx 1 root root     14 Feb 14 07:11 libGL.so -> libGL.so.1.7.0
lrwxrwxrwx 1 root root     14 Feb 14 07:11 libGL.so.1 -> libGL.so.1.7.0
-rwxr-xr-x 1 root root 610208 Feb 14 07:11 libGL.so.1.7.0
$

make a /usr/local/bin/vncserver:

$ cat /usr/local/bin/vncserver
#!/bin/bash
# added because nvidia driver overwrites these
export LD_LIBRARY_PATH=/usr/local/vnclib:$LD_LIBRARY_PATH
/usr/bin/vncserver $*