Bug 7791

на 340 драйвере графика поднимается, но плимут все равно не работает нормально, грузится в failsafe

[   50.286254] kwin[5377]: segfault at 0 ip   (null) sp bfedbbac error 14 in kwin[8048000+1000]
[   55.719235] rosa-launcher[5702]: segfault at 0 ip   (null) sp bfdf9a5c error 14 in rosa-launcher[8048000+75000]
[   87.672908] rosa-launcher[6155]: segfault at 0 ip   (null) sp bf965c0c error 14 in rosa-launcher[8048000+75000]
[   88.733239] rosa-launcher[6162]: segfault at 0 ip   (null) sp bfa8fe8c error 14 in rosa-launcher[8048000+75000]
[  121.687133] kdialog[6986]: segfault at 0 ip   (null) sp bfd3b9cc error 14 in kdialog[8048000+17000]

Володя, выложи ещё /proc/<PID>/maps для упавших процессов. Какие упали - см. по dmesg.

Ещё хорошо бы взять какое-то из приложений, что стабильно падает, но что можно запустить из консоли. И strace'ом его.

Ещё - попробуй вот эти сборки nvidia375:

(x64) https://abf.io/build_lists/2856603
(x32) https://abf.io/build_lists/2856602

Эти новее, чем то, что сейчас в репозиториях 2016.1.

(In reply to comment #5)
> Ещё - попробуй вот эти сборки nvidia375:
> 
> (x64) https://abf.io/build_lists/2856603
> (x32) https://abf.io/build_lists/2856602
> 
> Эти новее, чем то, что сейчас в репозиториях 2016.1.
попробовал - тот же результат.

Created attachment 4588 [details]
krunner.log

strace krunner

Created attachment 4589 [details]
rosa-launcher.log

падают программы, связанные с плазмой. Переключение движка на OpenGL не помогает, переключение на драйвера 340 ветки - помогает.

(In reply to comment #8)
> Created attachment 4589 [details]
> rosa-launcher.log

А попробуй поставить debug-пакет от него и запустить в gdb. Посмотрим, что выдаст.

Created attachment 4590 [details]
log

(In reply to comment #11)
> Created attachment 4590 [details]
> log

Скажи gdb, чтобы вывел backtrace (команда bt):

Created attachment 4591 [details]
log2

Created attachment 4592 [details]
log3

А на образах с Plasma 5 такая проблема возникает?
http://bugs.rosalinux.ru/show_bug.cgi?id=7798

Ещё надо проверить, не поможет ли обновление epoxy: http://bugs.rosalinux.ru/show_bug.cgi?id=7803

Мне попадались обсуждения, где Gnome 3 сегфолтился с проприетарными драйверами nVidia и обновление libepoxy до 1.4 решало проблему. Возможно, в случае с KDE 4 это и не сыграет роли, но в других DE может пойти на пользу. Как минимум в Plasma 5, где KWin использует libepoxy напрямую.

(In reply to comment #15)
> А на образах с Plasma 5 такая проблема возникает?
> http://bugs.rosalinux.ru/show_bug.cgi?id=7798
Еще хуже. После ввода пароля ругается на kinit и никуда не пускает.

(In reply to comment #17)
> (In reply to comment #15)
> > А на образах с Plasma 5 такая проблема возникает?
> > http://bugs.rosalinux.ru/show_bug.cgi?id=7798
> Еще хуже. После ввода пароля ругается на kinit и никуда не пускает.

Обновление epoxy тоже не помогает?

(In reply to comment #18)
> (In reply to comment #17)
> > (In reply to comment #15)
> > > А на образах с Plasma 5 такая проблема возникает?
> > > http://bugs.rosalinux.ru/show_bug.cgi?id=7798
> > Еще хуже. После ввода пароля ругается на kinit и никуда не пускает.
> 
> Обновление epoxy тоже не помогает?
Не помогает, впрочем, как и обновление нвидиядрайверов.

На всякий случай ещё покажи, что ldd скажет для rosa-launcher

В пакете от Debian есть полтора десятка патчей. В основном для ядер 4.10+, но может что-то полезное есть и для нашего случая.

https://packages.debian.org/sid/nvidia-driver

(In reply to comment #21)
> В пакете от Debian есть полтора десятка патчей. В основном для ядер 4.10+,
> но может что-то полезное есть и для нашего случая.
> 
> https://packages.debian.org/sid/nvidia-driver

Там есть интересное, но, думаю, не для этого случая.

Судя по backtrace, там до ядерного кода вообще дело не доходит, а основные патчи для него там. Если всё валится в glXGetProcAddress() из /usr/lib64/nvidia375/libGLX.so.0, с библиотеками что-то плохо.

ldd (http://bugs.rosalinux.ru/show_bug.cgi?id=7791#c20) нужен, да.

Нужна и проверка на x86_64.

Изменил заголовок, т.к. проблема не имеет отношения к сбоям установки драйверов.

Created attachment 4593 [details]
ld

это как раз с 64x

(In reply to comment #24)
> Created attachment 4593 [details]
> ld
> 
> это как раз с 64x

Надо ldd, а не ld.

Created attachment 4594 [details]
ldd

(In reply to comment #26)
> Created attachment 4594 [details]
> ldd

Тут вроде бы всё ок. А есть возможность другую nVidia-карту в этот комп вставить и проверить, будут ли те же проблемы?

И попробуй ещё тут посмотреть, может даже поспрашивать, вдруг у кого-то были уже аналогичные проблемы?
https://devtalk.nvidia.com/default/board/98/linux/1/

(In reply to comment #27)
> А есть возможность другую nVidia-карту в этот комп
> вставить и проверить, будут ли те же проблемы?
Других нвидиякарт у меня нету. А на твоей воспроизводится?

(In reply to comment #28)
> И попробуй ещё тут посмотреть, может даже поспрашивать, вдруг у кого-то были
> уже аналогичные проблемы?
> https://devtalk.nvidia.com/default/board/98/linux/1/
Да, в сообществе VK жаловались, что проприетарные драйвера не ставятся. 
Вот про плазму
https://vk.com/rosa_linux?w=wall-33847957_165480%2Fall
(со свободными там разобрались)

(In reply to comment #29)
> (In reply to comment #27)
> > А есть возможность другую nVidia-карту в этот комп
> > вставить и проверить, будут ли те же проблемы?
> Других нвидиякарт у меня нету. А на твоей воспроизводится?

Придётся попробовать. Новый винт уже купил, сейчас буду ставить на него систему. Как раз GeForce GTX 750 Ti карта.

Пока что даже устанавливать не рискнул, т.к. в live система с флэшки не загрузилась, после "Starting ACPI Event Daemon..." на экране появилась куча разных артефактов (вплоть до какой-то левой фотки на долю секунды), после чего система ребутнулась. Хотя были разы, когда вместо перезагрузки система просто подвисала (но на кнопку выключения питания реагировала). С nomodeset при этом загрузиться в live можно, хотя plymouth как раз failsafe-тему показывает. В логе иксов при этом видно, что пытается загрузиться и nouveau, и nv (которого нет).

Пробовал 32-битный образ.

Сделал пробу оборудования на x86_64-образе R9, где загрузился в live с nouveau.modeset=0:

https://linux-hardware.org/index.php?probe=e7d55807c9

64-битный образ грузится в live и без nouveau.modeset=0. Проба:
https://linux-hardware.org/index.php?probe=46e85b674e

32-битный R8.1 при этом грузится в live нормально (хотя половины текста не видно в браузере):
https://linux-hardware.org/index.php?probe=df6f312fa3

Видимо, это уже какая-то другая проблема, так что сделал для неё отдельный баг: http://bugs.rosalinux.ru/show_bug.cgi?id=7806

Как выяснилось, иксы сегфолтятся призагрузке 32-битного образа, после чего создаётся куча core dump-ов, которые быстро забивают всё место.

(In reply to comment #32)
> В логе иксов при этом видно, что пытается загрузиться и nouveau,
> и nv (которого нет).

Это нормально, "nv" прописан в соотв. списке в X11-сервере до сих пор. Потом можно будет оттуда вычистить. Но то, что его реально нет, не мешает загрузке и работе остальных драйверов.

(In reply to comment #36)
> Видимо, это уже какая-то другая проблема, так что сделал для неё отдельный
> баг: http://bugs.rosalinux.ru/show_bug.cgi?id=7806
> 
> Как выяснилось, иксы сегфолтятся призагрузке 32-битного образа, после чего
> создаётся куча core dump-ов, которые быстро забивают всё место.

Хм. В Live должно быть отключено как сохранение core dump'ов, так и их передача в systemd, что тоже съедало место.

Я это выключал как раз в R8.1.
https://abf.io/soft/build_kde4_desktop_ee/commit/027392517a10dbf35ee33e7048652e4d694a03f8

(In reply to comment #38)
> Хм. В Live должно быть отключено как сохранение core dump'ов, так и их
> передача в systemd, что тоже съедало место.
> 
> Я это выключал как раз в R8.1.
> https://abf.io/soft/build_kde4_desktop_ee/commit/
> 027392517a10dbf35ee33e7048652e4d694a03f8

Это какие-то другие дампы. У меня в корень диска писались файлы вида Core.XXX или как-то так, точно уже не помню.

Володя, попробуй ещё сохранить список содержимого initrd, когда пропр. драйверы установлены.

Можно попробовать сделать это в single-user mode, если графика неработоспособна.

Можно установить пропр. драйверы, перезагрузить систему, добавив single в список параметров ядра. Ввести рутовый пароль, если потребуется. Когда дойдёт до консоли, сохранить вывод lsinitrd и dmesg заодно.

Вот ещё может быть полезно: http://unix.stackexchange.com/questions/233752/plymouth-falling-back-to-text-boot-animation

И может быть вот это: https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#Disable_framebuffer

"Users who use NVIDIA proprietary driver might wish to disable GRUB's framebuffer as it can cause problems with the binary driver. "

И вот ещё может как-то пригодится:

https://wiki.archlinux.org/index.php/NVIDIA

"nvidia 364.16 adds support for DRM kernel mode setting. To enable this feature, add the nvidia-drm.modeset=1 kernel parameter, and add nvidia, nvidia_modeset, nvidia_uvm and nvidia_drm to your initramfs#MODULES."

Частично воспроизвёл у себя. С plymouth всё ок, так что failsafe-картинка в нём тема отдельная.

А падение некоторых программ на

#0  0x0000000000000000 in ?? ()
#1  0x00007fffe6a89b6d in glXGetProcAddress () from /usr/lib64/nvidia375/libGLX.so.0

тоже наблюдаю с 375-м драйвером. Причём именно некоторых. Скажем, Xonotic вполне себе работает. А не работает то, что связано с Qt/KDE и использует OpenGL. Впрочем, выборка у меня была совсем маленькая. Может падает вообще всё, что использует glXGetProcAddress.

Я 32-битную версию тестировал, кстати. Так что проблема имеет место и на i586, и на x86_64.

Попробовал установить 378-й драйвер, ошибка всё та же. На всякий случай для истории сделал пробу оборудования:

https://linux-hardware.org/index.php?probe=e209ae92d8

Created attachment 4596 [details]
rosa-launcher proc map

(In reply to comment #3)
> Володя, выложи ещё /proc/<PID>/maps для упавших процессов. Какие упали - см.
> по dmesg.

Для rosa-launcher. Но надо иметь в виду, что на этой системе я ставил 378-й драйвер из run-файла, так что библиотеки libGL* он засунул в /usr/lib/, а не в /usr/lib/nvidia.

Установил 378.13-й драйвер вручную с опциями
./nvidia-installer --no-glvnd-egl-client --no-glvnd-glx-client
и сегфолт пропал, теперь всё работает как надо. На 375-м не проверял, но скорее всего там тоже это поможет. Надо теперь собрать пакет соответствующим образом.

(In reply to comment #47)
> Created attachment 4596 [details]
> rosa-launcher proc map

Вот эта строчка оказалась ключевой: /usr/lib/libGL.so.1.0.0

$ cat .manifest
...
libGL.so.378.13 0755 GLX_CLIENT_LIB NATIVE NON_GLVND
libGL.so.1 0000 GLX_CLIENT_SYMLINK NATIVE libGL.so.378.13 NON_GLVND
libGL.so 0000 GLX_CLIENT_SYMLINK NATIVE libGL.so.1 NON_GLVND
libGL.so.1.0.0 0755 GLX_CLIENT_LIB NATIVE GLVND
libGL.so.1 0000 GLX_CLIENT_SYMLINK NATIVE libGL.so.1.0.0 GLVND
libGL.so 0000 GLX_CLIENT_SYMLINK NATIVE libGL.so.1 GLVND

Получается, что в текущем драйвере установились библиотеки для GLVND-режима, т.к. libGL.so.1 - это симлинк на libGL.so.1.0.0, а не на libGL.so.378.13.

Возможно, в rosa2014.1 всё это работает, т.к. в mesa нет поддержки GLVND, а в rosa2016.1 поддержка есть, но кривая.

А в спеке у нас наоборот, прописано "Skip non-GLVND libraries":

----------
        GLX_CLIENT_LIB|EGL_CLIENT_LIB)
                parseparams arch glvnd
                # Skip non-GLVND libraries
                # https://devtalk.nvidia.com/default/topic/915640/unix-graphics-announcements-and-news/multiple-glx-client-libraries-in-the-nvidia-linux-driver-installer-package/
                [ t"${glvnd}" == "tGLVND" ] && install_file nvidia $nvidia_libdir
                ;;
        GLX_CLIENT_SYMLINK|EGL_CLIENT_SYMLINK)
                # Skip non-GLVND libraries
                parseparams arch dest glvnd
                [ t"${glvnd}" == "tGLVND" ] && install_lib_symlink nvidia $nvidia_libdir
                ;;
----------

https://devtalk.nvidia.com/default/topic/915640/multiple-glx-client-libraries-in-the-nvidia-linux-driver-installer-package/

"Packages must install either libGL.so.$VERSION or libGL.so.1.0.0, but never both. libGL.so.1.0.0 requires additional GLVND libraries for proper operation"

Может что-то нужное не установилось, а может наоборот, установилось лишнее. В общем, надо документацию внимательно прочитать по ссылке выше. Она не слишком большая, на пару страниц.

(In reply to comment #50)
> Может что-то нужное не установилось, а может наоборот, установилось лишнее.
Либо какой-то компонент из Qt или KDE слинковался так, что требует именно non-GLVND версию libGL.

> В общем, надо документацию внимательно прочитать по ссылке выше. Она не
> слишком большая, на пару страниц.

Я с ней разбирался как раз, потому у нас и поставляются именно GLVND-библиотеки, но не старые их варианты.

Для работы GLVND-варианта библиотек от NVidia в ROSA, по идее, никакой поддержки GLVND в Mesa не нужно (её и нет, т.к. я не включал, а оно выключено по умолчанию). Просто если такая поддержка была бы, можно было бы обойтись без возни с alternatives и пр. Это отдельная история.

Как временное решение можно было бы, конечно, поставлять non-GLVND-вариант для библиотек NVidia. Но меня беспокоит то, что по умолчанию сейчас как раз GLVND там и всё движется в эту сторону. Т.е. баги в неосновных вариантах установки возможны и чиниться вряд ли будут активно. Плюс, переходить всё равно придётся, хоть и позже, и переход м.б. болезненным.

Возможно, стоит всё же разобраться, почему в rosa2016.1 эти приложения завязаны именно на non-GLVND-вариант, а в 2014.1 нормально работают и с GLVND, и с non-GLVND.

В любом случае, спасибо, что проверил, что проблема как-то связана именно с GLVND.

В общем, разобрались более-менее, осталось починить.

1. Это нормально, что в наших пакетах с nvidia375 и nvidia378, поставляются GLVND-enabled библиотеки. Назад на legacy библиотеки можно не переходить.

2. glXGetProcAddress() падает из-за того, что не инициализирована таблица функций __glvndPthreadFuncs (https://github.com/NVIDIA/libglvnd/blob/master/src/util/glvnd_pthread.h).

glXGetProcAddress() пытается вызвать __glvndPthreadFuncs.rwlock_rdlock(), но там 0 - всё падает.

Все эти беды из-за того, что при загрузке libGLX.so.0 в память не была выполнена инициализация этой библиотеки. Не была вызвана специальная функция-конструктор. При этом сам код этой функции в libGLX.so.0 есть, а вот в таблице символов записи об этой функции нет (strip перестарался что ли?). Причём на x64 в run-пакете с nvidia375 от NVidia уже лежит такая битая libGLX.so.0.

Я ради эксперимента организовал под GDB вызов этой функции-конструктора вручную - и после этого glXGetProcAddress() уже работала как надо.

3. Как указано в [1], можно не брать libGLX.so.0 и ещё несколько библиотек бинарниками из run-пакета NVidia, а собрать их из https://github.com/NVIDIA/libglvnd и использовать.

Я это проделал локально на 64-битной системе, положил собранные библиотеки в /usr/lib64/libglvnd/, прописал в /etc/nvidia375/ld.so.conf первой строкой /usr/lib64/libglvnd/, выполнил ldconfig -X. После этого система заработала нормально: графика есть, приложения запускаются и пр.

4. Разбираемся сейчас как это всё правильно опакетить.

Внешняя libglvnd, кстати, удобна и тем, что когда (в каком-то будущем) 
понадобится включать поддержку GLVND в Mesa, это всё тоже понадобится.


[1] https://devtalk.nvidia.com/default/topic/915640/unix-graphics-announcements-and-news/multiple-glx-client-libraries-in-the-nvidia-linux-driver-installer-package/,

(In reply to comment #52)
> В общем, разобрались более-менее, осталось починить.
> 
> 4. Разбираемся сейчас как это всё правильно опакетить.

Оказалось, надо было просто с _disable_ld_as_needed собирать. Именно -Wl,--as-needed портил пакет. Ниже рабочая сборка. Правда, я только 32-битную проверял, надо 64-битную тоже проверить.

libglvnd:
https://abf.rosalinux.ru/build_lists/2858589
https://abf.rosalinux.ru/build_lists/2858590

Теперь осталось драйвер nvidia собрать с использованием внешней libglvnd. Т.е. убрать из него встроенные libGLdispatch и libOpenGL, дописать libglvnd в ld.so.conf и т.д.

> Теперь осталось драйвер nvidia собрать с использованием внешней libglvnd.
> Т.е. убрать из него встроенные libGLdispatch и libOpenGL, дописать libglvnd
> в ld.so.conf и т.д.
А dkms-ки от этого не будут ли быстрее собираться?

(In reply to comment #54)
> > Теперь осталось драйвер nvidia собрать с использованием внешней libglvnd.
> > Т.е. убрать из него встроенные libGLdispatch и libOpenGL, дописать libglvnd
> > в ld.so.conf и т.д.
> А dkms-ки от этого не будут ли быстрее собираться?

Нет. Это всё дело не касается ядерных драйверов, только библиотек.

(In reply to comment #53)
> Теперь осталось драйвер nvidia собрать с использованием внешней libglvnd.
> Т.е. убрать из него встроенные libGLdispatch и libOpenGL, дописать libglvnd
> в ld.so.conf и т.д.

Именно.

Остаётся такой тонкий момент. 64-битные пакеты с драйверами поставляют как 64-битные, так и 32-битные библиотеки (для Steam и пр.). Можно ли в 64-битном пакете требовать в Requires 32-битный пакет? Или есть варианты получше?

Проверил Steam на 64-битной системе - да, либо ему, либо 64-битному x11-driver-video-nvidia* нужна зависимость от 32-битной libgldispatch0. Иначе - ругается и не стартует.

Возможно, есть и другие 32-битные приложения такого рода.

Да, а игры в Steam на 64-битной системе с nvidia375 не запускаются, если не поставить ещё и 32-битный пакет libglvnd-glx, помимо libgldispatch0.

Т.е. нужна и эта зависимость. И, видимо, пока - для x11-driver-video-nvidia375, т.к. если добавлять её к Steam, м.б. проблемы уже со свободными драйверами, т.к. Mesa на GLVND мы ещё не перевели.

Кстати, этот пакет libglvnd-glx там тоже нетривиально ставить, т.к. lib64glvnd-glx провайдит и libglvnd-glx. Т.е. urpmi libglvnd-glx ставит 64-битный пакет, а не тот, который нужен.

Как грамотнее поступить с этим всем?

(In reply to comment #58)
> Кстати, этот пакет libglvnd-glx там тоже нетривиально ставить, т.к.
> lib64glvnd-glx провайдит и libglvnd-glx. Т.е. urpmi libglvnd-glx ставит
> 64-битный пакет, а не тот, который нужен.
> 
> Как грамотнее поступить с этим всем?

Переделал Provides у пакетов, чтобы провайдились glvnd-glx и т.д., а libglvnd-glx и lib64glvnd-glx были только именами пакетов для 32/64-битных версий. И по имени пакета можно было установить нужный для архитектуры.

(In reply to comment #59)
> Переделал Provides у пакетов, чтобы провайдились glvnd-glx и т.д., а
> libglvnd-glx и lib64glvnd-glx были только именами пакетов для 32/64-битных
> версий. И по имени пакета можно было установить нужный для архитектуры.

libglvnd:
https://abf.rosalinux.ru/build_lists/2858605
https://abf.rosalinux.ru/build_lists/2858606

(In reply to comment #60)
> (In reply to comment #59)
> > Переделал Provides у пакетов, чтобы провайдились glvnd-glx и т.д., а
> > libglvnd-glx и lib64glvnd-glx были только именами пакетов для 32/64-битных
> > версий. И по имени пакета можно было установить нужный для архитектуры.
> 
> libglvnd:
> https://abf.rosalinux.ru/build_lists/2858605
> https://abf.rosalinux.ru/build_lists/2858606

То, что нужно. Я доработал nvidia375 и nvidia-current и пересобрал с этими сборками libglvnd.

Advisory:
GL vendor-neutral dispatch (GLVND) libraries are now available in rosa2016.1. The proprietary graphics drivers nvidia375 and nvidia-current have been updated to make use of these GLVND libraries instead of the pre-built binaries. This fixes crashes of many applications due to the broken pre-built libGLX.so.0 that was provided by NVidia.
Note that Mesa does not use GLVND in rosa2016.1 yet.


Build lists:

libglvnd:
https://abf.rosalinux.ru/build_lists/2858605
https://abf.rosalinux.ru/build_lists/2858606

nvidia375:
https://abf.io/build_lists/2858637
https://abf.io/build_lists/2858638

nvidia-current:
https://abf.io/build_lists/2858639
https://abf.io/build_lists/2858640

Примечания.

1. Тесты для 64-битных пакетов nvidia375 и nvidia-current на ABF не прошли и это ожидаемо. Не прошли, т.к. соотв. 64-битные пакеты теперь требуют по зависимостям не только 64-битные, но и 32-битные GLVND-библиотеки. Это нужно, чтобы 32-битные OpenGL-приложения (напр., Steam) работали "из коробки".

Коряво, но это временно. В будущем, вероятно, поддержку GLVND в Mesa дочинят. Тогда можно будет перевести Mesa на использование GLVND-библиотек, а соотв. зависимости из пакетов с драйверами NVidia убрать.

2. Я проверил эти сборки на 64-битной системе с GeForce GT 720. DE не падало, glxinfo и glxgears отработали, как надо. Steam запустился, benchmark "The Talos Principle" из-под Steam запустился и отработал нормально.

32-битные сборки драйверов NVidia я не проверял.

libglvnd-0.2.999-0.20170309.6
https://abf.rosalinux.ru/build_lists/2858605
https://abf.rosalinux.ru/build_lists/2858606

nvidia375-375.39-2
https://abf.io/build_lists/2858637
https://abf.io/build_lists/2858638

nvidia-current-378.13-2
https://abf.io/build_lists/2858639
https://abf.io/build_lists/2858640
************************ Advisory *************************
GL vendor-neutral dispatch (GLVND) libraries are now available in rosa2016.1. The proprietary graphics drivers nvidia375 and nvidia-current have been updated to make use of these GLVND libraries instead of the pre-built binaries. This fixes crashes of many applications due to the broken pre-built libGLX.so.0 that was provided by NVidia.
***********************************************************
QA Verified

Ещё VirtualBox падает при запуске, если используются текущие проприетарные драйверы nVidia + libglvnd. 

#0  0x00000000 in ?? ()
#1  0xb32a8784 in __glXGetCachedProcAddress (procName=0xb49b779b "glXChooseFBConfig") at libglx.c:1707
#2  glXGetProcAddress (procName=0xb49b779b "glXChooseFBConfig") at libglx.c:1761
#3  0xb32a9318 in __glXGLLoadGLXFunction (name=0xb49b779b "glXChooseFBConfig", ptr=0xb49d99b8 <__real_glXChooseFBConfig>, mutex=0x0)
    at libglx.c:1792
#4  0xb49a8834 in __glXWrapperInit () at g_libglglxwrapper.c:1657
#5  0xb49a5e22 in __libGLInit () at libgl.c:58
#6  0xb77a1243 in call_init.part () from /lib/ld-linux.so.2
#7  0xb77a1368 in _dl_init () from /lib/ld-linux.so.2
#8  0xb77a603b in dl_open_worker () from /lib/ld-linux.so.2
#9  0xb77a10d7 in _dl_catch_error () from /lib/ld-linux.so.2
#10 0xb77a52b2 in _dl_open () from /lib/ld-linux.so.2
#11 0xb7749c1d in ?? () from /lib/libdl.so.2
#12 0xb77a10d7 in _dl_catch_error () from /lib/ld-linux.so.2
#13 0xb774a3bb in ?? () from /lib/libdl.so.2
#14 0xb7749cd1 in dlopen () from /lib/libdl.so.2
#15 0x08049d15 in ?? ()
#16 0x0804a4b5 in ?? ()
#17 0x08048df3 in ?? ()
#18 0xb75760dd in __libc_start_main () from /lib/i686/libc.so.6
#19 0x08048e3f in ?? ()

(In reply to comment #65)
> Ещё VirtualBox падает при запуске, если используются текущие проприетарные
> драйверы nVidia + libglvnd. 
> 
> #0  0x00000000 in ?? ()
> #1  0xb32a8784 in __glXGetCachedProcAddress (procName=0xb49b779b
> "glXChooseFBConfig") at libglx.c:1707

Тот же баг, что и раньше. Проверь, какие библиотеки используются и есть ли в libGLX.so.0 функция __glXInit.

(In reply to comment #66)
> Тот же баг, что и раньше. Проверь, какие библиотеки используются и есть ли в
> libGLX.so.0 функция __glXInit.

Проблема в libglvnd или в glibc. Точнее, в порядке вызова конструкторов библиотек.

В конструкторе библиотеки libGL.so.1 из libglvnd (т.е. в __libGLInit(), которая должна автоматически вызываться при загрузке libGL.so.1 в память) вызываются функции из libGLX.so.0. Чтобы эти функции работали, надо, чтобы перед этим вызвался и конструктор библиотеки libGLX.so.0 (функция __glXInit()).

Для большинства программ так и происходит, но в случае с VirtualBox glibc почему-то сначала вызывает конструктор для libGL.so.1, а уже после этого - для libGLX.so.0 (я проверил это путём "чёрной магии" GDB). Непорядок, т.к. __libGLInit при этом пытается дёргать libGLX.so.0, когда та ещё

(In reply to comment #67)
... к этому не готова. В результате всё падает при обращении к тем же неинициализированным указателям на функции.

Что делать?

Самое простое, что я пока придумал: явно указать в коде libGL.so.1, что к такому-то моменту libGLX.so.0 уже должна быть загружена и работоспособна.

В GL/libgl.c в функции __libGLInit() перед вызовом __glXWrapperInit() поставить:

dlopen("libGLX.so.0", RTLD_NOW);

Всё.

Пока проверил локально - помогло.
Дальше сделаем патч и пересоберём libglvnd с ним.

(In reply to comment #68)
> Проблема в libglvnd или в glibc. Точнее, в порядке вызова конструкторов
> библиотек.

Можно попробовать вот эту сборку glibc:

https://abf.rosalinux.ru/build_lists/2864427
https://abf.rosalinux.ru/build_lists/2864428

Я отключил патч, который был из этого бага (причём у нас был самый первый его вариант): https://bugzilla.redhat.com/show_bug.cgi?id=1162810

(In reply to comment #69)
> Можно попробовать вот эту сборку glibc:
> 
> https://abf.rosalinux.ru/build_lists/2864427
> https://abf.rosalinux.ru/build_lists/2864428

На 64-битной системе помогло: теперь VirtualBox стартует нормально.
32-битную не проверял.

проверил обе, все работает.

Попробуем фианальный вариает:

Advisory: "Use fixed dso_deps patch in glibc (it greatly improves performance of dynamic loader for deeply nested DSO dependencies)"

https://abf.rosalinux.ru/build_lists/2864446
https://abf.rosalinux.ru/build_lists/2864447

glibc-2.24-8
https://abf.rosalinux.ru/build_lists/2864446
https://abf.rosalinux.ru/build_lists/2864447
*********************** Advisory **************************
se fixed dso_deps patch in glibc (it greatly improves performance of dynamic loader for deeply nested DSO dependencies)
***********************************************************
QA Verified