32187 2016-06-13 21:08:40 +0300 python2: Couldn't find current GLX or EGL context 2016-07-26 11:55:24 +0300 1 1 4 Development Sisyphus libspice-gtk unstable all Linux CLOSED FIXED P3 normal --- 1 stalker zerg shaba shrek slchess zerg qa-sisyphus oldest_to_newest 157294 0 stalker 2016-06-13 21:08:40 +0300 Кажется сломался с новыми nvidia_glx_361.45.11 на соседней станции с intel не воспроизводится Откат на glxgears-11.1.2-alt1.x86_64.rpm glxinfo-11.1.2-alt1.x86_64.rpm i586-libGL-11.1.2-alt1.i586.rpm libEGL-11.1.2-alt1.x86_64.rpm libGL-11.1.2-alt1.x86_64.rpm libGLES-11.1.2-alt1.x86_64.rpm libgbm-11.1.2-alt1.x86_64.rpm libofx-0.9.10-alt1.2.x86_64.rpm libwayland-egl-11.1.2-alt1.x86_64.rpm xorg-dri-swrast-11.1.2-alt1.x86_64.rpm xorg-server-1.18.2-alt1.x86_64.rpm xorg-server-common-1.18.2-alt1.x86_64.rpm не помогает (virt-manager:3478): GSpice-CRITICAL **: egl init failed: cannot create EGL context [Пн, 13 июн 2016 19:40:56 virt-manager 3478] DEBUG (viewers:598) Requesting fd for channel: <SpiceClientGLib.DisplayChannel object at 0x7fd08a064190 (SpiceDisplayChannel at 0x18a7b40)> [Пн, 13 июн 2016 19:40:56 virt-manager 3478] DEBUG (sshtunnels:286) Generated tunnel fd=32 for viewer [Пн, 13 июн 2016 19:40:56 virt-manager 3478] DEBUG (viewers:598) Requesting fd for channel: <SpiceClientGLib.CursorChannel object at 0x7fd0815477d0 (SpiceCursorChannel at 0x1717330)> [Пн, 13 июн 2016 19:40:56 virt-manager 3478] DEBUG (sshtunnels:286) Generated tunnel fd=34 for viewer python2: Couldn't find current GLX or EGL context. 157295 1 stalker 2016-06-13 21:21:10 +0300 Помогает откат rpm -Uvh --force libspice-gtk3-0.30-alt1.x86_64.rpm python-module-spice-gtk-0.30-alt1.x86_64.rpm libspice-gtk-0.30-alt1.x86_64.rpm libspice-glib-gir-0.30-alt1.x86_64.rpm libspice-glib-0.30-alt1.x86_64.rpm libspice-glib-0.30-alt1.x86_64.rpm libspice-gtk3-gir-0.30-alt1.x86_64.rpm 157327 2 shaba 2016-06-15 20:54:00 +0300 А у вас включен gl для виртуалки? http://www.spice-space.org/spice-user-manual.html#_gl_acceleration_virgl есть такие настройки? <video> <model type='virtio' heads='1'> <acceleration accel3d='yes'/> </model> </video> <graphics type='spice' autoport='no'> <gl enable='yes'/> </graphics> Попробуйте выключить 3D. 157329 3 stalker 2016-06-15 22:41:26 +0300 Оно падает на любых картах и похоже только если на хоcте, где запускаю virt-manager nvidia Конфиг гостей по части видео <video> <model type='qxl' ram='65536' vram='65536' heads='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> 157340 4 shaba 2016-06-16 18:46:59 +0300 У апстрима есть такой баг: https://bugs.freedesktop.org/show_bug.cgi?id=95254 157361 5 stalker 2016-06-17 15:31:40 +0300 Да этот баг я видел но на мой не похоже. У меня гости находятся в другом датацентре и коннект virt-manager over ssh virt-manager схлопывается на моей рабочей станции на NVIDIA GLX Module 361.45.11 А вот на соседний рабочей станции с === [ 14.174] (II) LoadModule: "intel" [ 14.281] (II) Loading /usr/lib64/X11/modules/drivers/intel_drv.so [ 14.362] (II) Module intel: vendor="X.Org Foundation" [ 14.362] compiled for 1.18.0, module version = 2.99.917 [ 14.362] Module class: X.Org Video Driver [ 14.362] ABI class: X.Org Video Driver, version 20.0 [ 14.362] (II) LoadModule: "modesetting" === не падает. На проблемной станции помог только откат libspice 157707 6 slchess 2016-07-21 10:39:24 +0300 Такая же ошибка. (remote-viewer:19870): GSpice-WARNING **: Warning no automount-inhibiting implementation available (remote-viewer:19870): GSpice-CRITICAL **: egl init failed: cannot create EGL context remote-viewer: Couldn't find current GLX or EGL context. libspice-glib-0.32-alt1 libspice-glib-gir-0.32-alt1 libspice-gtk3-0.32-alt1 libspice-gtk3-gir-0.32-alt1 libspice-server-0.12.7-alt1 libspiro-20071029-alt2.qa2 libvirt-2.0.0-alt1 libvirt-client-2.0.0-alt1 libvirt-daemon-2.0.0-alt1 libvirt-daemon-config-network-2.0.0-alt1 libvirt-daemon-config-nwfilter-2.0.0-alt1 libvirt-daemon-driver-interface-2.0.0-alt1 libvirt-daemon-driver-network-2.0.0-alt1 libvirt-daemon-driver-nodedev-2.0.0-alt1 libvirt-daemon-driver-nwfilter-2.0.0-alt1 libvirt-daemon-driver-qemu-2.0.0-alt1 libvirt-daemon-driver-secret-2.0.0-alt1 libvirt-daemon-driver-storage-2.0.0-alt1 libvirt-glib-0.2.3-alt1 libvirt-glib-gir-0.2.3-alt1 libvirt-qemu-common-2.0.0-alt1 python-module-libvirt-2.0.0-alt1 kernel-modules-nvidia-std-def-367.35-alt1.263182.1 nvidia_glx_367.35-367.35-alt156 nvidia_glx_common-367.35-alt166 nvidia-settings-367.35-alt1 nvidia-xconfig-367.35-alt1 157708 7 slchess 2016-07-21 11:21:41 +0300 Решилась проблема выковыриванием из NVIDIA-Linux-x86_64-367.35-no-compat32.run файла libGLESv1_CM_nvidia.so.367.35 и расположением его в /usr/lib64 затем ldconfig и все заработало, почему в пакете nvidia_glx_367.35-367.35-alt156 его не оказалась ? когда в федоре nvidia-driver-libs-364.19-2.fc24.x86_64.rpm он есть 157749 8 zerg 2016-07-25 11:44:12 +0300 Я в курсе; собирался сделать. Пока другие пляски были с nvidia. P.S. 2 Shrek: По хорошему бы и в Mesa запаковать libGLESv1_CM.so.1 . Для красоты, .т.к. для решения конкретной проблемы это параллельно. Я запакую свой libGLESv1_CM.so.1, который буду переключать. 157752 9 shrek 2016-07-25 12:00:20 +0300 Для Mesa libGLESv1_CM.so.1 не нужен, т.ч. собирать и паковать его не к чему 157753 10 zerg 2016-07-25 12:36:44 +0300 (В ответ на комментарий №9) > Для Mesa libGLESv1_CM.so.1 не нужен Да, вот, мне тоже не совсем понятно, зачем он libspice-gtk-у. В код не смотрел, но, подозреваю, ему тоже можно оторвать. 157774 11 zerg 2016-07-25 18:07:05 +0300 В общем, решил запаковать, т.к. сам nvidia умеет форсировать GLESv1. Завтра обновятся всякие *nvidia*. 157786 12 zerg 2016-07-26 11:55:24 +0300 (В ответ на комментарий №11) > В общем, решил запаковать, т.к. сам nvidia умеет форсировать GLESv1. > Завтра обновятся всякие *nvidia*. Забыл еще nvidia_glx_common 367.35-alt168 . Отправил сейчас на сборку.