What's your preferred method to reach you to discuss paid support options?
On Thursday, May 6, 2021 at 6:17:11 PM UTC-4 southern.cross wrote:
> Understood.
>
> No systemctl support was a Microsoft decision. Google it... you'll see a
> decent amount of chatter on it.
>
> The non-standard DISPLAY is also related to Microsoft decisions. That's
> the display that I have to use when doing X11forwarding. I can switch it
> back to :1 for the sake of trying VGL but it won't display anything. Again,
> a Microsoft decision.
>
> On Thursday, May 6, 2021 at 6:12:23 PM UTC-4 DRC wrote:
>
>> If systemctl doesn't exist, then that's not exactly a standard Ubuntu
>> configuration, and it doesn't surprise me that multiple things are broken
>> from VirtualGL's point of view. I'm also suspicious of your DISPLAY
>> environment variable. It's uncommon in this day and age for X servers to
>> allow TCP communications, so your DISPLAY should be something like :0.0
>> rather than <IP_address>:0.0. I'm happy to investigate this further on
>> a paid support basis, but since I don't personally use WSL, there
>> unfortunately isn't anything else I can do within the context of community
>> support unless I can reproduce the issue using a standard Ubuntu 20.04
>> installation (which I can't.)
>>
>> DRC
>> On 5/6/21 3:56 PM, southern.cross wrote:
>>
>> (1) systemd does not exist so I can't use systemctl to enable but not
>> start. So, I've been using 'service gdm3 start/stop'. So, I stopped gdm3
>> and proceeded to (2)
>> (2) ran as expected
>> (3) /usr/share/gdm/greeter/autostart/virtualgl.desktop gets generated
>> with correct contents
>> (4) made the changes. To verify, here is the output of "cat
>> /opt/VirtualGL/bin/vglgenkey"
>>
>> <snip>
>> root@SEDACS29L:/tmp# cat /opt/VirtualGL/bin/vglgenkey
>> #!/bin/sh
>> XAUTH=xauth
>> if [ -x /usr/X11R6/bin/xauth ]; then
>> XAUTH=/usr/X11R6/bin/xauth
>> 2>&1 echo "X11R6" > /tmp/out4
>> fi
>> if [ -x /usr/openwin/bin/xauth ]; then
>> XAUTH=/usr/openwin/bin/xauth
>> 2>&1 echo "openwin" /tmp/out5
>> fi
>> if [ ! -d /etc/opt/VirtualGL ]; then
>> mkdir -p /etc/opt/VirtualGL
>> 2>&1 echo "mkdir" > /tmp/out6
>> fi
>> if [ -f /etc/opt/VirtualGL/vgl_xauth_key ]; then
>> rm /etc/opt/VirtualGL/vgl_xauth_key
>> 2>&1 echo "rm" > /tmp/out7
>> fi
>> $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/out2 2>&1 echo Success >/tmp/out3
>> chmod 644 /etc/opt/VirtualGL/vgl_xauth_key
>> </snip>
>>
>> (5) I used "service gdm3 start"
>>
>> No "out*" files were created in /tmp
>>
>> So, my understanding of how to enable, start and stop services in WSL2
>> seems to be lacking.
>>
>> If I run gdm directly by running "/usr/sbin/gdm3" I still get no
>> /tmp/out* files
>>
>> Running: echo "$(cat /opt/VirtualGL/bin/vglgenkey)"
>>
>> produced two /tmp/out* files:
>>
>> /tmp/out ==> "xauth: file /etc/opt/VirtualGL/vgl_xauth_key does not
>> exist"
>> /tmp/out7 ==> ""
>>
>> # echo $DISPLAY
>> <my IP>:0.0
>>
>> thoughts?
>>
>> On Thursday, May 6, 2021 at 1:22:14 PM UTC-4 DRC wrote:
>>
>>> It definitely should work with Ubuntu 20.04. I assume that you're using
>>> our official DEB packages for VirtualGL 2.6.5 and not packages from any
>>> other provider. I would suggest the following diagnostic procedure:
>>>
>>> 1. Re-enable GDM but don't start it yet.
>>>
>>> 2. Re-run vglserver_config.
>>>
>>> 3. Verify that /usr/share/gdm/greeter/autostart/virtualgl.desktop exists
>>> with the following contents:
>>>
>>> [Desktop Entry]
>>> Type=Application
>>> Exec=/opt/VirtualGL/bin/vglgenkey
>>>
>>> 4. Edit /opt/VirtualGL/bin/vglgenkey and change the $XAUTH command lines
>>> as follows:
>>>
>>> $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/out2 2>&1
>>> echo Success >/tmp/out3
>>>
>>> 5. Start GDM and check the contents of /tmp/out*. /tmp/out should say
>>>
>>> xauth: file /etc/opt/VirtualGL/vgl_xauth_key does not exist
>>>
>>> and /tmp/out3 should say
>>>
>>> Success
>>>
>>> If /tmp/out2 exists, then post its contents.
>>>
>>> On 5/6/21 11:56 AM, southern.cross wrote:
>>> > Thanks for the response.
>>> >
>>> > I've tried on two different machines:
>>> > (1) Windows 10 Pro 20H2 Build 19042.928, with WSL2 Ubuntu 20.04.
>>> > (2) Windows 10 Home insider program Build
>>> 21370.co_release.210424-1611,
>>> > insider Developer program Nvidia Driver 470.25 (the combination of
>>> > these two give GPU pass through abilities), with WSL2 Ubuntu 20.04.
>>> >
>>> > They both have the same behavior
>>> where /etc/opt/VirtualGL/vgl_xauth_key
>>> > is never generated.
>>> >
>>> > I'm hoping to get this to work as our team is looking to standardize
>>> on
>>> > VGL for our development process. Each team member has a different
>>> > computer setup (some linux, some Mac, some Windows/WSL2, some local,
>>> > some remote). Hopefully we can get it working on WSL2...
>>> >
>>> > Thanks again.
>>> >
>>> > On Thursday, May 6, 2021 at 12:17:35 PM UTC-4 DRC wrote:
>>> >
>>> > Using WSL as a VirtualGL server platform isn't officially supported,
>>> > because it doesn't make sense in production VirtualGL environments
>>> > to use a Windows workstation as a virtual Linux server. However,
>>> > there is no technical reason why it shouldn't work.
>>> >
>>> > Issue #65 (the necessity to use LightDM on Ubuntu 16.04 and later)
>>> > was worked around in VirtualGL 2.6.2, so that issue is no longer
>>> > relevant in the latest releases of VirtualGL.
>>> >
>>> > I need to reproduce the issue before we can proceed, so please
>>> > specify the version of Ubuntu you are using. Also, please make sure
>>> > you are using the latest release of VirtualGL.
>>> >
>>> >
>>> > On 5/6/21 11:02 AM, southern.cross wrote:
>>> >> Has anyone had success in getting VGL to work on any version of
>>> >> WSL2 Ubuntu?
>>> >>
>>> >> The VGL installation is not making /etc/opt/VirtualGL/vgl_xauth_key
>>> >>
>>> >> The following told me to use lightdm:
>>> >> https://github.com/VirtualGL/virtualgl/issues/65
>>> >> <https://github.com/VirtualGL/virtualgl/issues/65>
>>> >>
>>> >> I successfully completed:
>>> >>
>>> >> sudo systemctl disable gdm3
>>> >> sudo apt install lightdm
>>> >>
>>> >> But not,
>>> >> sudo systemctl enable lightdm
>>> >>
>>> >> I get:
>>> >>
>>> >> root@SEDACS29L:~# systemctl enable lightdm
>>> >> Synchronizing state of lightdm.service with SysV service script
>>> >> with /lib/systemd/systemd-sysv-install.
>>> >> Executing: /lib/systemd/systemd-sysv-install enable lightdm
>>> >> The unit files have no installation config (WantedBy=,
>>> >> RequiredBy=, Also=,
>>> >> Alias= settings in the [Install] section, and DefaultInstance= for
>>> >> template
>>> >> units). This means they are not meant to be enabled using systemctl.
>>> >>
>>> >> Possible reasons for having this kind of units are:
>>> >> • A unit may be statically enabled by being symlinked from another
>>> >> unit's
>>> >> .wants/ or .requires/ directory.
>>> >> • A unit's purpose may be to act as a helper for some other unit
>>> >> which has
>>> >> a requirement dependency on it.
>>> >> • A unit may be started when needed via activation (socket, path,
>>> >> timer,
>>> >> D-Bus, udev, scripted systemctl call, ...).
>>> >> • In case of template units, the unit is meant to be enabled with
>>> some
>>> >> instance name specified.
>>> >>
>>> >> If I proceed and try to run,
>>> >>
>>> >> /opt/VirtualGL/bin/vglserver_config -config -s
>>> >>
>>> >> even after a wsl --shutdown and relaunch I cannot get
>>> >> /etc/opt/VirtualGL/vgl_xauth_key to be created.
>>> >>
>>> >> Google searches have not shown any results of VGL being used with
>>> >> WLS2 Ubuntu... Is this not a supported use case?
>>> >>
>>> >> Thanks in advance.
>>> >> --
>>> >> 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/34f961d5-dcad-4a07-9624-1c36512faf88n%40googlegroups.com
>>>
>>> >> <
>>> https://groups.google.com/d/msgid/virtualgl-users/34f961d5-dcad-4a07-9624-1c36512faf88n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>>
>>>
>>> >
>>> > --
>>> > 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]
>>> > <mailto:[email protected]>.
>>> > To view this discussion on the web visit
>>> >
>>> https://groups.google.com/d/msgid/virtualgl-users/437080c3-c011-492b-ba07-90ceb62f2ccdn%40googlegroups.com
>>>
>>> > <
>>> https://groups.google.com/d/msgid/virtualgl-users/437080c3-c011-492b-ba07-90ceb62f2ccdn%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>>
>>>
>>>
>> --
>> 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/acd857f4-1af3-4ed2-9b71-41aa4ac57d60n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/virtualgl-users/acd857f4-1af3-4ed2-9b71-41aa4ac57d60n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
--
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/c7fd341e-f0b6-46db-88f7-466196c60ab1n%40googlegroups.com.
