Inconsistent start in VMware 6.5.1 on Fedora 10 64-bit

[Krellan]

Hello. I'm running VMware Workstation 6.5.1 on a Fedora 10 64-bit installation.

I have trouble starting VMware. I made a quick launch icon to run "/usr/bin/vmware", and I have to click on it something like 10 times in order for it to come up. However, it does eventually come up. It seems like a strange race condition to me. Here are error messages I get during failed starts. Has anybody else encountered this?

ldd: exited with unknown exit code (132)

ldd: exited with unknown exit code (139)

/usr/lib/vmware/bin/vmware: error while loading shared libraries: libgnomecanvasmm-2.6.so.1: cannot open shared object file: No such file or directory

/usr/lib/vmware/bin/vmware-modconfig: error while loading shared libraries: libview.so.2: cannot open shared object file: No such file or directory

Sometimes it will be a combination of the above.

All of my modules are correctly compiled and loaded. I get no errors when doing "/etc/init.d/vmware restart". This works perfectly. In the output of lsmod, I see these 4 modules running: vmnet, vmblock, vmci, vmmon. So, I know that's not a problem.

It's strange that I get these loading errors, though. All of the libraries are indeed on the system. The /usr/bin/vmware script is supposed to find those libraries, isn't it?

And FYI, I did follow all of the recommendations I knew to get VMware Workstation installed on Fedora 10. Here's a summary, please let me know if I forgot anything:

1) In /etc/modprobe.conf.d, create a new file. Add 3 lines to that file: "blacklist kvm", "blacklist kvm_intel", "blacklist kvm_amd". Reboot. If you already have these modules loaded, merely unloading them with "rmmod" is not good enough. You must reboot.

2) Remove kvm userspace as well, with "yum erase kvm".

3) Install compatibility library, with "yum install compat-expat1". VMware uses a slightly older version of the libexpat library, and it will fail to load unless you manually install this older version for compatibility.

4) Move the preexisting /usr/lib/vmware/modules/binary directory out of the way. Run "vmware-modconfig --console --install-all". This will recompile your modules. I got no errors at all when doing this. If you get errors, you didn't install enough development features when installing Fedora 10.

5) Fix the keyboard bug, or you won't be able to type your arrow keys reliably on your guest machines. Once you get VMware up and running, close all open VMware windows and edit your $HOME/.vmware/preferences file. Add this line to the bottom: xkeymap.nokeycodeMap = "TRUE"

Thanks!

Josh

[gwiesenekker]

I am having the same problem with VMware 6.5.1 on Fedora Core 10 64-bit. Sometimes it starts, at other times it exits with:

ldd: exited with unknown exit code (139)

/usr/lib/vmware/bin/vmware: error while loading shared libraries: libview.so.2: cannot open shared object file: No such file or directory

And while VMware workstation is running after some time also the message

ldd: exited with unknown exit code (139)

shows up.

Any ideas?

Regards,

Gijsbert

[gwiesenekker]

I reinstalled Fedora Core 10 64-bit from scratch, updated it fully and reinstalled VMware workstation 64-bit (with the prerequisites compat-expat1 and libgnomemm), but again the same problem.

I then reinstalled Fedora Core 10 32-bit from scratch, updated it fully, installed VMware workstation 32-bit: it runs right away. I did not even have to install compat-expat1 and libgnomemm.

So the problem is related to the 64-bit environment. Maybe some 32-bit libraries have to be installed in the 64-bit environment?

Regards,

Gijsbert

[gwiesenekker]

Josh,

I have another server that runs VMware workstation 64-bit fine on Fedora Core 10 (but this server has been updated over time, has seen several workstation versions, and has many 32-bit libraries installed).

As my 64-bit installation that has the problem has been overwriten by the 32-bit installation I wander if you could run the following command in your installation (if you still have it):

strace vmware >vmware.out 2>vmware.err

And post the vmware.out and vmware.err files for a vmware that is failing so that I can compare them to those on my server.

Regards,

Gijsbert

[Krellan]

What's weird is that it sounds like a race condition. I can try, but might not be able to catch it.

Also, I have VMware running a lot of VM's now, and don't want to take it down, because of the risk that it might be difficult to get VMware started again

[gwiesenekker]

I have rebuilt my Fedora Core 10 64-bit with VMware workstation 6.5.1

The first time vmware started, but the second time it did not.

The output of

strace vmware

shows that the second time it could not find libgnomecanvasmm-2.6.so.1, but this directory is in /usr/lib/vmware/lib (and contains libgnomecanvasmm-2.6.so.1).

A comparison with the strace on i386 showed that vmware does not search /usr/lib/vmware/lib in the second case.

I ran strace vmware several times until vmware started again. The strace output showed that it now can find libgnomecanvasmm-2.6.so.1, so it really looks like a race condition.

Any ideas?

Regards,

Gijsbert

[rocketraman]

Same problem here... sometimes vmware starts and sometimes it doesn't. When it doesn't, it always dies after stating that it cannot find a library that is bundled with vmware in/etc/vmware/bootstrap. I seem to have better luck when running from the command line vs. clicking an icon.

Also possibly of interest -- whether it starts or not I tend to get the following message printing out an inconsistent number of times -- sometimes it doesn't print at all, sometimes it prints once, and sometimes three times:

ldd: exited with unknown exit code (139)

Cheers,

Raman

[vanRijn]

Hey guys, sorry to hear you're hitting this issue. =:( I've asked for help internally, so hopefully we'll get some help here. One thing... do you have a full GNOME environment on this machine in question? gtkmm2, glibmm2, libview, etc.?

[Krellan]

Hi! Yes, it's a full GNOME installation (and KDE too, however my default desktop is set to GNOME). I'm glad you're looking into the problem.

[rocketraman]

I run KDE, but I do run several gtk-based apps so I have a lot of the gnome libraries installed. Here are some queries on the libs you mentioned:

1. rpm -qa | grep -E "(gtkmm2|glibmm2|libview)"

glibmm24-2.18.1-1.fc10@x86_64

gtkmm24-2.14.3-1.fc10@x86_64

1. locate libview

/usr/lib/vmware/lib/libview.so.2

/usr/lib/vmware/lib/libview.so.2/libview.so.2

1. ldd vmware | grep "not found"

libview.so.2 => not found

libsexymm.so.2 => not found

libvmwarebase.so.0 => not found

libvmwareui.so.0 => not found

libgvmomi.so.0 => not found

1. for x in $(ldd vmware | grep "not found" | sed -e "s/^[ ]\(.\) =>.*$/\1/g"); do locate $x; done;

/usr/lib/vmware/lib/libview.so.2

/usr/lib/vmware/lib/libview.so.2/libview.so.2

/usr/lib/vmware/lib/libsexymm.so.2

/usr/lib/vmware/lib/libsexymm.so.2/libsexymm.so.2

/usr/lib/vmware/lib/libvmwarebase.so.0

/usr/lib/vmware/lib/libvmwarebase.so.0/libvmwarebase.so.0

/usr/lib/vmware/lib/libvmwareui.so.0

/usr/lib/vmware/lib/libvmwareui.so.0/libvmwareui.so.0

/usr/lib/vmware/lib/libgvmomi.so.0

/usr/lib/vmware/lib/libgvmomi.so.0/libgvmomi.so.0

/usr/lib/vmware-vix/VIServer-2.0.0/64bit/libgvmomi.so.0

/usr/lib/vmware-vix/Workstation-6.5.0/64bit/libgvmomi.so.0

(NOTE: when I was running the above commands I did receive the following sometimes which may also indicate why vmware is also failing sometimes:

ldd: exited with unknown exit code (139)

I don't know why that is happening -- looks like it might be a Fedora problem.

[rocketraman]

This Fedora bug might be related:

https://bugzilla.redhat.com/show_bug.cgi?id=488449

[rocketraman · Accepted solution]

At least on my machine, the problem is indeed due to Fedora bug 488449.

There is a work-around given in comment #15:

https://bugzilla.redhat.com/show_bug.cgi?id=488449#c15

When I modify my /usr/bin/ldd script to use the workaround, vmware starts consistently. Hope that helps!

[vanRijn]

> # for x in $(ldd vmware | grep "not found" | sed -e "s/^[ ]\(.\) =>.*$/\1/g"); do locate $x; done;

> /usr/lib/vmware/lib/libview.so.2

> /usr/lib/vmware/lib/libview.so.2/libview.so.2

> /usr/lib/vmware/lib/libsexymm.so.2

> /usr/lib/vmware/lib/libsexymm.so.2/libsexymm.so.2

> /usr/lib/vmware/lib/libvmwarebase.so.0

> /usr/lib/vmware/lib/libvmwarebase.so.0/libvmwarebase.so.0

> /usr/lib/vmware/lib/libvmwareui.so.0

> /usr/lib/vmware/lib/libvmwareui.so.0/libvmwareui.so.0

> /usr/lib/vmware/lib/libgvmomi.so.0

> /usr/lib/vmware/lib/libgvmomi.so.0/libgvmomi.so.0

> /usr/lib/vmware-vix/VIServer-2.0.0/64bit/libgvmomi.so.0

> /usr/lib/vmware-vix/Workstation-6.5.0/64bit/libgvmomi.so.0

Okay, so wow, seriously, nice shell-fu! =:)

> (NOTE: when I was running the above commands I did receive the following sometimes which may also indicate why vmware is also failing sometimes:

>

> ldd: exited with unknown exit code (139)

>

> I don't know why that is happening -- looks like it might be a Fedora problem.

Ahhh, okay, yes, that makes more sense now.

[vanRijn]

At least on my machine, the problem is indeed due to Fedora bug 488449.

There is a work-around given in comment #15:

https://bugzilla.redhat.com/show_bug.cgi?id=488449#c15

When I modify my /usr/bin/ldd script to use the workaround, vmware starts consistently. Hope that helps!

Okay, so it definitely does sound like a Fedora 10 bug, I agree. Glad to hear there's a workaround! =:)

[Krellan]

Wow, thanks for the tip.

https://bugzilla.redhat.com/show_bug.cgi?id=488449#c17

I modified my /etc/cron.daily/prelink script, according to the instructions given in comment 17 of that bug.

I then deleted my /etc/prelink.cache file, to force a full rebuild of the prelinking, then ran the /etc/cron.daily/prelink script again, as root.

Interestingly, it still gave some errors about not being able to find the dependencies for many of the vmware executables in /usr/lib/vmware/bin. I have no idea why VMware puts each library in its own directory, in /usr/lib/vmware/lib, which makes it very hard to just add the path to ld.so.conf or something convenient like that.

I haven't been able to reproduce the bug in a while on my own, though. For the last few times I've had to fully start VMware, it has always came up for me.

Nevertheless, this is a big step forward in solving my problem, so I'll mark the question as answered. Thanks for your help!

Josh