On Friday, 27 March 2020 22:01:17 UTC+1, DRC wrote:
>
> On 3/27/20 3:32 PM, Hans Peter wrote:
>
> Chose "Restrict 3D X server access" and "Restrict framebuffer" to vglusers
> group, added
> myself and root to the group.
>
> 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.
>
I know, and I did. :-)
BTW, the configuration threw the error
> rmmod: ERROR: Module nvidia is in use by: nvidia_modeset
> so I did
> rmmod nvidia_drm nvidia_modeset rmmod nvidia; modprobe nvidia nvidia_drm
> nvidia_modeset
> before 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.)
>
I did use the nvidia distribution (downloaded from nvidia.com), but
installed it according to the directions on the RH webpage (basically make
sure all the prerequisites are OK).
> 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 it
> say 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.)
>
Thanks for clarifying that.
But whatever I try, when I run
>
> 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
>
> should 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.
>
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.
Regards,
Hans Peter
--
You received this message because you are subscribed to the Google Groups
"VirtualGL User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/virtualgl-users/7e9ebb59-629a-44ca-a339-4b2d26b7922e%40googlegroups.com.
