Can't perform "Sanity Check"
Hans Peter
xauth merge /etc/opt/VirtualGL/vgl_xauth_key
I get the error "No such file". Quite reasonable, as there is no such file.
I guess that the script
/opt/VirtualGL/bin/vglgenkey
xdpyinfo -display :0
/opt/VirtualGL/bin/glxinfo -display :0 -c
results in
unable to open display ":0".
Any suggestions on how to proceed is appreciated!
Best,
Hans Peter Verne
System Administrator, Dept. of Geosciences, University of Oslo.
DRC
Can anybody please help me out here?
I installed VirtualGL 2.6.3 on a RHEL8 box, by adding the yum repo (https://virtualgl.org/Downloads/YUM)&& yum install virtualgl
(I don't have physical access to the machine right now, because I'm working from home,as do everybody else, but I have access with ssh).
Install Nvidia drivers for the Quadro 2000, as according to
https://access.redhat.com/solutions/4134381 (login needed), looks OK.
Configured VirtualGL according to the UG at https://cdn.rawgit.com/VirtualGL/virtualgl/2.6.3/doc/index.html .
Chose "Restrict 3D X server access" and "Restrict framebuffer" to vglusers group, addedmyself and root to the group.
BTW, the configuration threw the error
rmmod: ERROR: Module nvidia is in use by: nvidia_modesetso I did
rmmod nvidia_drm nvidia_modeset rmmod nvidia; modprobe nvidia nvidia_drm nvidia_modesetbefore I restarted gdm (init 5), but I guess this is unrelated to my problems, described below.
It isn't necessary to do that. That error message generally just
means that another process (the display manager) is using the
driver. That shouldn't be the case in run level 3, but apparently
you aren't the only one who observed that problem (refer to the
earlier post on this same group.) Perhaps the issue occurs when
using the Red Hat distribution of the nVidia driver, which would
explain why I've never seen it (I only use nVidia's distribution.)
Logout, and proceeds with section 6.2.1 in the UG: "Sanity Check"
"log back into the server using SSH"
The guide doesn't specify if I should log in as root, or as myself. Nor does itsay if I should use ssh -X or not.
Because it doesn't matter. The UG will specify on a command-by-command basis if a command needs to be executed as root, so you can use sudo or su to run those commands. Using 'ssh -X' is never necessary when using a supported VirtualGL workflow (if you use vglconnect, it runs 'ssh -X' behind the scenes.) You don't ever need to SSH into the server as root (and many servers do not support that anyhow.)
But whatever I try, when I runxauth merge /etc/opt/VirtualGL/vgl_xauth_key I get the error "No such file". Quite reasonable, as there is no such file. I guess that the script /opt/VirtualGL/bin/vglgenkeyshould generate this key, but running it gets me nowhere, as it seems to
depend on me having a $DISPLAY. The only $DISPLAY I can manage is
whatever I get with ssh -X, and I'm pretty sure that is not what is intended here.
If /etc/opt/VirtualGL/vgl_xauth_key does not exist, that means that /opt/VirtualGL/bin/vglgenkey was not executed. vglgenkey is executed within the display manager startup. It isn't meant to be executed manually.
Have you tried rebooting the machine? If that doesn't work, then I can only suggest editing /opt/VirtualGL/bin/vglgenkey as follows:
--- a/vglgenkey
+++ b/vglgenkey
@@ -12,6 +12,6 @@ fi
if [ -f /etc/opt/VirtualGL/vgl_xauth_key ]; then
rm /etc/opt/VirtualGL/vgl_xauth_key
fi
-$XAUTH -f /etc/opt/VirtualGL/vgl_xauth_key generate $DISPLAY .
trusted timeout 0 ||
- $XAUTH -f /etc/opt/VirtualGL/vgl_xauth_key add $DISPLAY .
`$XAUTH list | awk '{print $3}' | uniq`
+$XAUTH -f /etc/opt/VirtualGL/vgl_xauth_key generate $DISPLAY .
trusted timeout 0 >>/tmp/out 2>&1 ||
+ $XAUTH -f /etc/opt/VirtualGL/vgl_xauth_key add $DISPLAY .
`$XAUTH list | awk '{print $3}' | uniq` >>tmp/out
2>&1
chmod 644 /etc/opt/VirtualGL/vgl_xauth_key
After doing that, restart the display manager and see if /tmp/out contains any error messages. If /tmp/out doesn't exist, then vglgenkey is not being executed by the display manager for some reason.
Hans Peter
On Friday, 27 March 2020 22:01:17 UTC+1, DRC wrote:
On 3/27/20 3:32 PM, Hans Peter wrote:
It probably is not related to the issue, but be sure to log out and back in after adding yourself to the vglusers group, so that the new group permissions can take effect.Chose "Restrict 3D X server access" and "Restrict framebuffer" to vglusers group, addedmyself and root to the group.
BTW, the configuration threw the error
rmmod: ERROR: Module nvidia is in use by: nvidia_modesetso I did
rmmod nvidia_drm nvidia_modeset rmmod nvidia; modprobe nvidia nvidia_drm nvidia_modesetbefore I restarted gdm (init 5), but I guess this is unrelated to my problems, described below.
It isn't necessary to do that. That error message generally just means that another process (the display manager) is using the driver. That shouldn't be the case in run level 3, but apparently you aren't the only one who observed that problem (refer to the earlier post on this same group.) Perhaps the issue occurs when using the Red Hat distribution of the nVidia driver, which would explain why I've never seen it (I only use nVidia's distribution.)
Logout, and proceeds with section 6.2.1 in the UG: "Sanity Check"
"log back into the server using SSH"
The guide doesn't specify if I should log in as root, or as myself. Nor does itsay if I should use ssh -X or not.Because it doesn't matter. The UG will specify on a command-by-command basis if a command needs to be executed as root, so you can use sudo or su to run those commands. Using 'ssh -X' is never necessary when using a supported VirtualGL workflow (if you use vglconnect, it runs 'ssh -X' behind the scenes.) You don't ever need to SSH into the server as root (and many servers do not support that anyhow.)
But whatever I try, when I runxauth merge /etc/opt/VirtualGL/vgl_xauth_key I get the error "No such file". Quite reasonable, as there is no such file. I guess that the script /opt/VirtualGL/bin/vglgenkeyshould generate this key, but running it gets me nowhere, as it seems to
depend on me having a $DISPLAY. The only $DISPLAY I can manage is
whatever I get with ssh -X, and I'm pretty sure that is not what is intended here.
If /etc/opt/VirtualGL/vgl_xauth_key does not exist, that means that /opt/VirtualGL/bin/vglgenkey was not executed. vglgenkey is executed within the display manager startup. It isn't meant to be executed manually.
Have you tried rebooting the machine? If that doesn't work, then I can only suggest editing /opt/VirtualGL/bin/vglgenkey as follows:
--- a/vglgenkey
+++ b/vglgenkey
@@ -12,6 +12,6 @@ fi
if [ -f /etc/opt/VirtualGL/vgl_xauth_key ]; then
rm /etc/opt/VirtualGL/vgl_xauth_key
fi
-$XAUTH -f /etc/opt/VirtualGL/vgl_xauth_key generate $DISPLAY . trusted timeout 0 ||
- $XAUTH -f /etc/opt/VirtualGL/vgl_xauth_key add $DISPLAY . `$XAUTH list | awk '{print $3}' | uniq`
+$XAUTH -f /etc/opt/VirtualGL/vgl_xauth_key generate $DISPLAY . trusted timeout 0 >>/tmp/out 2>&1 ||
+ $XAUTH -f /etc/opt/VirtualGL/vgl_xauth_key add $DISPLAY . `$XAUTH list | awk '{print $3}' | uniq` >>tmp/out 2>&1
chmod 644 /etc/opt/VirtualGL/vgl_xauth_key
After doing that, restart the display manager and see if /tmp/out contains any error messages. If /tmp/out doesn't exist, then vglgenkey is not being executed by the display manager for some reason.
DRC
> I see. The problem then is that vglgenkey is indeed not being
> executed, as neither vgl_xauth_key or /tmp/out exists after a reboot
> (with the modifications to vglgenkey in place).
>
> The problem seems to be that /etc/gdm/Init/Default is not executed,
> and googling that I see that this has indeed been a problem with gdm:
> https://gitlab.gnome.org/GNOME/gdm/issues/317
> Your (I take it you are the same DRC as in that thread) latest comment
> from 2019-02-12 indicated the problem was solved, but I guess it has
> reappeared in RHEL8.
>
> If switching to LightDM is likely to solve the problem, I see no
> reason not to try that.
>
> Thanks for the swift reply! I'll keep you updated.
but VirtualGL 2.6.2 and later works around that known issue by using a
GDM greeter autostart file (specifically,
/usr/share/gdm/greeter/autostart/virtualgl.desktop). So the real
question is why the autostart file isn't being executed.
Hans Peter Verne
>
> > If switching to LightDM is likely to solve the problem, I see no
> > reason not to try that.
(I tried reporting it as a bug, but the report was closed as this
was apparently expected behavior. Go figure.
https://bugzilla.redhat.com/show_bug.cgi?id=1818777 )
> /etc/gdm/Init/Default will not be executed on Wayland-enabled systems,
> but VirtualGL 2.6.2 and later works around that known issue by using a
> GDM greeter autostart file (specifically,
> /usr/share/gdm/greeter/autostart/virtualgl.desktop). So the real
> question is why the autostart file isn't being executed.
with RHEL7. I can now get VGL to work, but I must admit I am not
impressed, so far. Running glxgears is slow and jerky, it is much
smoother to run it simply with ssh -X.
Running
vglrun glxinfo | egrep '(vendor|version) string'
I can see both VirtualGL (1.4) and NVIDIA (390.116) being mentioned, so I
guess both the correct hardware and software is involved somehow.
I use vglconnect -s to the server. I'll see if I can get better response if
I can get this VNC proxy thingy to work.
Thanks again for your replies.
Regards,
--
Hans Peter Verne
There are three things I have learned never to discuss with people... religion,
politics and The Great Pumpkin! -- Linus van Pelt
DRC
> We'll never know, as I gave up on RHEL8 and reinstalled the system
> with RHEL7. I can now get VGL to work, but I must admit I am not
> impressed, so far. Running glxgears is slow and jerky, it is much
> smoother to run it simply with ssh -X.
happy to keep working with you to diagnose and fix the issue, as long as
you were willing to work with me.
GLXgears is not a valid comparison. The window size and geometry of
that benchmark are so small that it barely even involves the GPU. Try
running
/opt/VirtualGL/bin/glxspheres64 -m -p 1000000
both with and without VirtualGL if you really want to see the advantage
of VirtualGL. Also please understand that, irrespective of performance,
a lot of modern OpenGL functionality will simply not be available in an
indirect OpenGL environment (running OpenGL applications with ssh -X
uses indirect OpenGL.)