Horizon View Client Version 2012-8.1, 2103-8.2 hungs in LogOff Screen

[rohrbachger]

We have since a while Vmware Client 2006-8.0 in use, this works in general fine.

We are trying to update now as we want to upgrade the environment to 2012-8.1

On the windows based clients there is no issue with a new client version. We have tested with the actual thinstation version just pulled, with 8.1 and 8.2. When looging off, the blue logoff screen hungs. ps -A we do see vmware-print-re <defunct)

kill vmware-remotemk ends the task

Can someone give a hint, how we can get this solved?

[rohrbachger]

You were right, on 21.04 it works in general. But connecting from home to the view on work I get only a black screen. Strange behaviour, I start vmware-view in the chroot. Can logon to the server( external) and can choose the different pools. But when I open the session I get only black screen. It seems that the x server from 21.04 is involved. on a ubuntu terminal I do see the vmware task, I expect it to run in the chroot.

Maybe the black screen is just from home, I will test at work tomorrow.

[rohrbachger]

At work the same, I´m getting only a black screen as session. I tested several ways, no difference. I will try F35, never used it before.

[rohrbachger]

Fedora 35 now on one physical machine installed. thinstation cloned from github In the chroot I trid to install vmware-view client ( different vesions) Following error message I get Authorization required Unable to Init server Failed to Load GTK libraries

In Fedora in general there seems to be a problem with Vmware View client, I*m not able to install. So I will try again on ubuntu.

[Thinstation]

Might have to login as root on F35 On Sun, Oct 31, 2021 at 5:44 AM rohrbachger @.***> wrote:

Fedora 35 now on one physical machine installed. thinstation cloned from github In the chroot I trid to install vmware-view client ( different vesions) Following error message I get Authorization required Unable to Init server Failed to Load GTK libraries

In Fedora in general there seems to be a problem with Vmware View client, I*m not able to install. So I will try again on ubuntu.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/Thinstation/thinstation/issues/649#issuecomment-955693787, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVW47VMUIJOQ4L3EW423WDUJU22PANCNFSM476DURSQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[rohrbachger]

Yes, login as root, ten it works fine. I also can connect from the chroot to a view session, no black screen. When I logoff from the view session it does not hung like in TS. I will create a new TS build. I doubt there is a difference from he one I create on ubuntu.

[Doncuppjr]

Probably not, but that is good news. It means it’s not the kernel, and it’s not the libs. So it’s configuration or a busy box applet giving unexpected results to some part of view.

[Thinstation]

The next thing to do is remove all the configuration script. Which is pretty much everything in build/extra, build --removeall, remove those files, then make a new build.

[Thinstation]

You can also test a build, much like in chroot, by doing a build --savedir, then afterwards going to /build/tmp-tree and running the cast command. Then try running vmview and see what happens. If it's a busybox applet, you will need to do an strace -f -o /debug the vmview command. Afterwards, grep the log for the open command, do some sort -u stuff untill your list is small, then start replacing applets with full size binaries until you find the culprit.

[rohrbachger]

I did a new build, removed the most files in extra folder. No change. So I will start now with you last comment, This sound like fun. Is there no easy way to just remove busybox and try with all the standard commands? How much memory busy box is saving?

If that will work your proposal is probably the only way to find out. At least we would see some success when testing.

[Thinstation]

You could write a script that would enumerate all the busybox applets, for each applet, cp --remove-destination which applet tmp-tree/bin/. , and also put them in sbin. That's a little simple and messy, but you could do it.

[Thinstation]

for applet in `ls -al --color=never /build/tmp-tree/bin |grep -e "/bin/busybox" |cut -d " " -f14- |cut -d " " -f1`; do cp --remove-destination `which $applet` /build/tmp-tree/bin; done

for applet in `ls -al --color=never /build/tmp-tree/sbin |grep -e "/bin/busybox" |cut -d " " -f14- |cut -d " " -f1`; do cp --remove-destination `which $applet` /build/tmp-tree/sbin; done

cp --remove-destination /usr/bin/which /build/tmp-tree/bin/.

[rohrbachger]

This does not work for me, unexpected token | Is there somethig missing behind --color=never?

for applet in ls -al --color=never '/build/tmp-tree/sbin' |grep -e "/bin/busybox" |cut -d " " -f14- |cut -d " " -f1; do cp --remove-destination which $applet /build/tmp-tree/sbin; done

[Thinstation]

This ticks are missing. Github turns them into text highlighting. `

[rohrbachger]

My bash knowledge is too limited..... I put ls -al --color=never in ticks ` but his does helped.

[Thinstation]

for applet in `ls -al --color=never /build/tmp-tree/bin |grep -e "/bin/busybox" |cut -d " " -f14- |cut -d " " -f1`; do cp --remove-destination `which $applet` /build/tmp-tree/bin; done

for applet in `ls -al --color=never /build/tmp-tree/sbin |grep -e "/bin/busybox" |cut -d " " -f14- |cut -d " " -f1`; do cp --remove-destination `which $applet` /build/tmp-tree/sbin; done

cp --remove-destination /usr/bin/which /build/tmp-tree/bin/.

[Thinstation]

Also, send me an strace -f -o /debug vmware-view app

[rohrbachger]

Fighted with the script, it runs but seems not to work. CP: missing destination file operand after 'build/tmp-tree/bin' Try cp --help for more information.

However, how is the step to create from the tmp-tree the iso image?

Iḿ trying to understand how it works with busybox In the build script is a line ./tmp-tree/bin/busybox --install -s This is adding the links.

Tomorrow I will run the strace at work and attach it. I will also run on our existing TS stations. I can also run on a ubuntu, where we have no issues.

[Thinstation]

It's a little noisy, as not all busybox applets have an full size binary that can replace them, but it should get most of them. The point of testing with the tmp-tree is to test the tmp-tree without making an new image. just go into tmp-tree, and run the "cast" command. It should start a new chroot and allow you to test the image without building and booting.

[rohrbachger]

Here the strace from a workstation. At the end I killed the task from vmware-view manually.

debug.zip

[Thinstation]

Try my latest push. If it still does not work, make another strace. Ty for your patience.

[rohrbachger]

Tried two times to build. The TS is not getting an IP address. I double checked, I used my own configuration that I always use. Interface eno1. I assigned in TS manual an IP, but this did not worked. I tested the same at work, same problem.

package networkmanager is disabled, like I ever had.

[rohrbachger]

I looked at the last changes typos? ln -sf /bin/bash /ts/build/packages/bash//bin/sh

[Thinstation]

No. That creates a link to /bin/bash at /bin/sh

I'm not having any issues getting an IP.

[rohrbachger]

Well, tried again, same problem. It worked before with the same steps. I´m not really familiar with git, so it took a while

I have tried now commit f4411d02eead59308c033da5b74bc1bcb83827ba

With that version TS gets an IP. So I will try now commit 7943b872e6cb95837a742f02141abc11d7811035 In newer commit than this one I do see a change for network.

[Thinstation]

Try using the bt cd command from within the chroot to test a build.

[Thinstation]

It has to be run at /

[rohrbachger]

Probably I'm doing something wrong... At work I have only ubuntu , at home F35 and ubuntu

git clone --depth 5 git://github.com/Thinstation/thinstation.git 5 to get the latest 5 commits

changing to thinstation folder git checkout 8883c4acb556aa2ca4f960bf62f6a86ee741757d ( not the latest) setup-chroot to create the environment. Copy my build.conf and thinstation.conf.buildtime build With the 8883 build I create the ISO. This works, I get an IP.

git clone --depth 1 git://github.com/Thinstation/thinstation.git The rest the same steps, but I do not get an IP.

I guess I do much too complicate....

[Thinstation]

Hmmmm. Try making an allmodules build. In packages/vmview/dependencies, I added bash and vmview-test. You could try commenting out each of these and see which one is causing you to lose IP connectivity.

[rohrbachger]

allmodules did not helped. Tomorrow I will comment out the changes and test again. Already late today.. Lets see then if this is really related.

[rohrbachger]

Commeting out did not help. I have the feeling it is related to the changes after 8883c4acb556aa2ca4f960bf62f6a86ee741757d I changed back the settings in wind_cache and unwind_cache. But probably this does not change anything when I already run the setup-chroot before.

So when I git clone --depth 5 git://github.com/Thinstation/thinstation.git git checkout 8883c4a ( not the latest) setup-chroot build git checkout 252f1ce5e1f40bae88195c35a6a019b9e97d85eb build I do get an IP. Still the same problem with view session hungs.

What is ist wind_cache and unwind_cache doing?

[Thinstation]

It is creating a link to bash for sh. Try removing the the link /build/packages/bash/bin/sh

[rohrbachger]

debug.zip

Here the latest strace, the changes from 12 minutes ago not included.

[Thinstation]

Are you using the cast command, or booting images still?

[rohrbachger]

Still booting images, at work I have a ubuntu 20.04 VM server without X. On that machine Iḿ doing the build. At home I do have a 21.04 ubuntu desktop and now a f35. Is there a benefit for testing with cast?

[Doncuppjr]

It's a middling step. Another way of bisecting configuration. It's faster than booting, and more flexible. You can tweak individual builds without rebuilding and booting. Just have to remember what you did to make something work.

[rohrbachger]

So with latest commit Iḿ getting an IP address when I build iso. Still the view issue with hung logoff. On my F35 , logged in as root I tried he cast setup-choot cast Message: moun: /sys: none already mounted on(sys

What I have to do to get the cast working? Do I need to build with --savedir first?

[Thinstation]

yes, build with --savedir, then go to /build/tmp-tree and run cast

[Thinstation]

could try removing packages/base/bin/lsb_release

[rohrbachger]

I have tested on F3 the cast, but DNS seems not to work Using IP of our view server does not work, but that's normal. So I switched back to ISO. I rename lsb_release, View session hungs completly, I can not get back to TS. So somehow a difference, after several minutes the view session has ended, and I get back the TS. This effect I had also before sometimes, I'm usually not waiting 4 minutes....

I will try now again to replace the busybox commands.

[rohrbachger]

I replaced all the busybox sbin bin commands and replaced with the sbin bin commands from chroot if there was a binary. No difference, view session hungs.

[Thinstation]

before running cast, cp /etc/resolv.conf /build/tmp-tree/etc/.

[rohrbachger]

This works in f35 with cast now, so view connection is working.( but still hungs on disconnection) Shall I send another strace?

[Thinstation]

Do you have fastboot enabled?

[rohrbachger]

no fastboot is not enabled, never used it.

[Thinstation]

In the chroot, install the view client and strace it. I want to look at an strace of something that works.

[rohrbachger]

tsdebug.zip I build a new TS today, attached the strace. To compare strace from a working ubuntu what works fine.

Today on TS I noticed a new message, when I started with strace. glibcxx.3.4.26 not found. This is new, I never noticed before.

I read both files to a database, that`s probably more easy to analyse. Which information I have to look at?

The openat seems to be the interesting one. In strace ts I have 344200 lines with openat..... In strace ubuntu 15422 lines with openat.

[rohrbachger]

View client is right I think in /usr/lib/vmware/gcc/libstdc++.so.6 , the latest is GLIBCXX_3.4.22 Vmware client seems to need 3.4.26

But this seems to be new, never read this before.

[Thinstation]

Hmmm. The ubuntu test is not using the /usr/lib/vmware/gcc/libstdc++.so.6, but rather the system wide one at /lib/x86_64-linux-gnu/libstdc++.so.6. Maybe try deleting /build/packages/vmview/lib/vmware/gcc

[Thinstation]

Is this fixed?

[rohrbachger]

No, with all testing and changes I did not get a better result.

This week we will test actual TS with View client 2008 8.0.0 During my test with this old client we had no issues with loging of problem.

Also I added this in thinstation.conf.buildtime. We had some other issues, when users left the workplace for a time. When they came back, one screen stays black. For me it seems to be an issue with power saving. SCREEN_STANDBY_TIME=0 SCREEN_SUSPEND_TIME=0 SCREEN_OFF_TIME=0

We had some other issues, when users left the workplace for a time. When they came back, one screen stays black. For me it seems to be an issue with power saving.

But I will try again to get the actual view client working. There is another client version as tar archive available.

One fact is also, that on ubuntu 20.04 the newest client is working fine, on 21.04 we have the same issue like in TS.