WS 7.1.4 Ubuntu Natty w/ 2.6.38-8 no longer working--now vmdk's possibly corrupted

[rwsmith61]

Hi,

Here is my setup:

Ubuntu Natty 11.04 fully updated

Kernel 2.6.38-8-generic-pae

Intel Sandybridge i7-2600K (stock)

8GB RAM

Xorg 1.10.1

I was running WS 7.1.4 fine without any issues. I have Fedora guests and WinXP guests that were running fine and at the same time. I just got around to upgrade my Radeon graphics card last night and had to reboot. Prior to this the system had upgraded and installed kernel 2.6.38-10-generic-pae. When I sat down to start work this morning WS 7.1.4 would start up but none of the guests would start. They would either hang with a blank console (not even get to the VMware BIOS screen) or occassionally I would get a 'unexpected signal 11'.

So I spent the entire day reading Vmware and Ubuntu forums and trying all of the suggestions and patches that were out there--to no avail. I tried the latest 7.1.4 patch for kernel 2.6.38-2; I tried Weltall's patch for 2.6.39 which according to him should have worked on 2.6.38-10; I installed the latest release candidate kernel 2.6.39 for Natty and Weltall's patch. I tried all of the glib tricks; checked libgtkmm--I have the latest libgtkmm. Nothing. Nada. Nista!

So, I attempted to create a new fedora VM using kernel 2.6.38-10-generic-pae and I get a (somewhat) working VM. It will start if I restart the vmware services but it will not shutdown cleanly--I'm still stuck with a black screen. So, I was able to mount my older fedora VM disk and run fsck on them as I was not sure what state they would be in with all of the hard crashes on the VM I had to do. They seemed to be OK.

However, and here is the rub, it appears that somehow the older VMs (fedora and WinXP) are now corrupted. Just to check I went back to the older kernel 2.6.38-8-generic-pae and the stock, unpatched Vmware modules. The new fedora VM does still boot but again does not shutdown fully. Unfortunately I can not get my older VMs (fedora and WinXP) to start (mostly they hang with a black console prior to the vmware bios).

Based on the fact the I can start the new fedora VM but not the older fedora VM appears that something in the older VMs have gotten corrupted. I have gone into the VM's directories and have remove all of the lock directories, the VMEM file, the NVRAM file and all of the log files. The VMs still hang. As the old fedora VM and the new fedora VM are essentially identical (other than UUIDs and a few others) I made the old fedora vmx file to be as close to the new fedora vmx file. Still nothing.

Does anybody have any idea what si going on? Is there any known to check the sanity of a VM (to test for incompatibles or corruption)? I really, really, really need my VMs to do my work. Is WS 7.1.4 known to work with Natty and kernel 2.6.38-8 or higher (include kernel 2.6.39-rc4)?

Any help is greatly appreciated. Attached is the latest log file for the original fedora VM.

Down to the knuckles,

BobS

--bs

[rwsmith61]

For starters today I copied the old fedora VM to a fedora 15 server (kernel 2.6.38.8-32.fc15.i686) with WS 7.1.4 loaded. I was able to start the fedora VM, log in and validate that the VM was NOT corrupted. I then copied the VM back to my Ubuntu Natty workstation. As suggested by many posts I ran vmware from the command line from my account and got the following output:

$ vmware
Logging to /tmp/vmware-rwsmith/setup-26948.log
filename:       /lib/modules/2.6.38-8-generic-pae/misc/vmmon.ko
supported:      external
license:        GPL v2
description:    VMware Virtual Machine Monitor.
author:         VMware, Inc.
srcversion:     E3E1CF871CA4C3D90799510
depends:       
vermagic:       2.6.38-8-generic-pae SMP mod_unload modversions 686
filename:       /lib/modules/2.6.38-8-generic-pae/misc/vmnet.ko
supported:      external
license:        GPL v2
description:    VMware Virtual Networking Driver.
author:         VMware, Inc.
srcversion:     D36A7ECC85CB55BAAA00790
depends:       
vermagic:       2.6.38-8-generic-pae SMP mod_unload modversions 686
filename:       /lib/modules/2.6.38-8-generic-pae/misc/vmblock.ko
supported:      external
version:        1.1.2.0
license:        GPL v2
description:    VMware Blocking File System
author:         VMware, Inc.
srcversion:     400149ED038D22A87322D56
depends:       
vermagic:       2.6.38-8-generic-pae SMP mod_unload modversions 686
parm:           root:The directory the file system redirects to. (charp)
filename:       /lib/modules/2.6.38-8-generic-pae/misc/vmci.ko
supported:      external
license:        GPL v2
description:    VMware Virtual Machine Communication Interface (VMCI).
author:         VMware, Inc.
srcversion:     A332EC5BECB386E33233230
depends:       
vermagic:       2.6.38-8-generic-pae SMP mod_unload modversions 686
filename:       /lib/modules/2.6.38-8-generic-pae/misc/vsock.ko
supported:      external
license:        GPL v2
version:        1.0.0.0
description:    VMware Virtual Socket Family
author:         VMware, Inc.
srcversion:     30E957C8B85A577264B0300
depends:        vmci
vermagic:       2.6.38-8-generic-pae SMP mod_unload modversions 686
filename:       /lib/modules/2.6.38-8-generic-pae/misc/vmmon.ko
supported:      external
license:        GPL v2
description:    VMware Virtual Machine Monitor.
author:         VMware, Inc.
srcversion:     E3E1CF871CA4C3D90799510
depends:       
vermagic:       2.6.38-8-generic-pae SMP mod_unload modversions 686

(vmware-unity-helper:27119): GLib-WARNING **: /build/buildd/glib2.0-2.28.6/./glib/goption.c:2132: ignoring no-arg, optional-arg or filename flags (8) on option of type 0

(vmware-unity-helper:27119): GLib-WARNING **: /build/buildd/glib2.0-2.28.6/./glib/goption.c:2132: ignoring no-arg, optional-arg or filename flags (8) on option of type 0

(vmware-unity-helper:27197): GLib-WARNING **: /build/buildd/glib2.0-2.28.6/./glib/goption.c:2132: ignoring no-arg, optional-arg or filename flags (8) on option of type 0

(vmware-unity-helper:27197): GLib-WARNING **: /build/buildd/glib2.0-2.28.6/./glib/goption.c:2132: ignoring no-arg, optional-arg or filename flags (8) on option of type 0

(vmware-unity-helper:27200): GLib-WARNING **: /build/buildd/glib2.0-2.28.6/./glib/goption.c:2132: ignoring no-arg, optional-arg or filename flags (8) on option of type 0

(vmware-unity-helper:27200): GLib-WARNING **: /build/buildd/glib2.0-2.28.6/./glib/goption.c:2132: ignoring no-arg, optional-arg or filename flags (8) on option of type 0
*** glibc detected *** /usr/lib/vmware/bin/vmware-vmx: corrupted double-linked list: 0x08d1a5d0 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x6b961)[0xb74b6961]
/lib/i386-linux-gnu/libc.so.6(+0x6e99c)[0xb74b999c]
/lib/i386-linux-gnu/libc.so.6(__libc_malloc+0x63)[0xb74baf53]
/usr/lib/vmware/bin/vmware-vmx[0x80b3be0]
/usr/lib/vmware/bin/vmware-vmx[0x8406723]
/usr/lib/vmware/bin/vmware-vmx[0x82a07f8]
/usr/lib/vmware/bin/vmware-vmx[0x82aa950]
/usr/lib/vmware/bin/vmware-vmx[0x8493875]
/usr/lib/vmware/bin/vmware-vmx[0x83fa3b4]
/usr/lib/vmware/bin/vmware-vmx[0x840838b]
/usr/lib/vmware/bin/vmware-vmx[0x829d9d3]
/usr/lib/vmware/bin/vmware-vmx[0x807bd05]
/usr/lib/vmware/bin/vmware-vmx[0x824ee68]
/usr/lib/vmware/bin/vmware-vmx[0x811ed19]
/usr/lib/vmware/bin/vmware-vmx[0x811f48d]
/usr/lib/vmware/bin/vmware-vmx[0x8290769]
/usr/lib/vmware/bin/vmware-vmx[0x829d89e]
/usr/lib/vmware/bin/vmware-vmx[0x80ca258]
/lib/i386-linux-gnu/libpthread.so.0(+0x5e99)[0xb7718e99]
/lib/i386-linux-gnu/libc.so.6(clone+0x5e)[0xb751b73e]

Look at the backtrace. Has anybody seen this before and have a magic bullet to fix?

Any help or advise is appreciated!

BobS

--bs

[rwsmith61]

Partially SOLVED for WS 7.1.4 and VMPlayer 3.1.4

From the articles and posts that I was reading yesterday I decided to follow up on the glibc issue. There several posts about adding the following to the top the vmplayer and vmware scripts:

#!/usr/bin/env bash
#
# Copyright 2005-2008 VMware, Inc.  All rights reserved.
#
# Wrapper for the real ‘vmplayer’ binary. Ensure that the
# binary will find all the shared libraries it needs. If a shared
# library is not available from any of the standard system-wide
# locations, we provide it from the location where the VMware software
# is installed.
#
export LD_PRELOAD=/usr/lib/vmware/lib/libglib-2.0.so.0/libglib-2.0.so.0
set -e

Well, this only led to additional output and errors so I started appending additional vmware libs. This only took me so far until they both completely broke.

I noticed that there was one script in the /usr/lib/vmware/lib directory called wrapper-gtk24.sh. There is a similar script in /usr/lib/vmware/bin called launcher.sh. Reviewing these scripts there were comments about 3/4 the way down:

#
# When environment variable VMWARE_USE_SHIPPED_GTK is set to "force", we
# forcefully use the GTK+ runtime environment (libraries + their
# configuration files) that we ship.
#
# When environment variable VMWARE_USE_SHIPPED_GTK is set to "yes", we
# thoughtfully use the GTK+ runtime environment (libraries + their
# configuration files) that we ship.  This works for all but the most broken
# environments, so if we're guessing we try this.
#
# When environment variable VMWARE_USE_SHIPPED_GTK is set to "no", we use
# the system's GTK+ runtime environment.
#
# When environment variable VMWARE_USE_SHIPPED_GTK is not set (the default), we
# try to make an educated guess.
#

I googled VMWARE_USER_SHIPPED_GTK and found older posts (back in 2007) that stated (indirectly) that the correct place to set this environment variable was in /etc/vmware/bootstrap. Or if you want to test in on the command line then you can do this:

$ VMWARE_USER_SHIPPED_GTK="force" vmware

This did allow me to start my older fedora VM and get it booted to where I can login. However when I shutdown I still get the unexpected caught signal 11 message. However, when I try to start my WinXP VM it will load WinXP but as soon as I get to the "hit ctl-alt-del to login" window it too catches the signal 11 and crashes.

So, it looks like I can hobble around for the day and get some work done. Because I have to revert to the Vmware libs and can not shutdown cleanly or yet get my WinXP to run I am going to leave this issue UNSOLVED for now. I am attaching the vmware.log from the fedora VM when it crashed during shutdown if any one is interested in reviewing it.

Any feedback is appreciated.

BobS

--bs

[betor3]

Hey Bob:

Same problem here (and same errors). And I think the problem is related to the Radeon card.

I'm currently using Natty with gnome3 installed. Only way I can use vmware is in fallback mode (install the Radeon propietary drivers, then try to log in, gnome 3 will crash and go to Vesa/Fallback mode. There, VM workstation works.. although it sucks 'cause the video is quite slow).

I've been looking for an answer for quite some time now.. Good to know there's someone else with the same problem. If you get to know something let me know!

Hopefully somebody else found a solution.

cheers,

beto

[rwsmith61]

Hi, beto,

As I mentioned in my first post I was in fact upgrading from an HD 4550 (no fan) card to a HD 5670 (with fan) card. Things were working fine just prior to the upgrade and I was just too busy with work at the time to really pay attention to the upgrades that were applied before I started the to replace the cards (I was also adding a second HD monitor as I needed the real estate for some of my projects). The radeon driver did not change as I confirmed in the Xorg.0.log file with each card.

I did go back and attempt to return the system to the state prior to the upgrade including putting the HD 4550 card back in and booting back into the 2.6.38-8-generic-pae kernel. I have no idea (but suspect) that the glibc libraries were updated as well--it wasn't until the second day that I decided to pursue that route and manage to get as far as I did. However, that did not resolve the issues either and I decided to continue with the new HD 5670 card and kernel 2.6.38-10-generic-pae kernel.

I did manage to run the original fedora VM for the past two days but tonight I risked a reboot of the VM and it is giving me fits--although this time it gets to the login screen but seems to hang there--can't go forward and can't go back. If I force a power-off of the VM it agains gives me a caught signal 11. (OK, it just took about 4 minutes to log in--this doesn't bode well for the 75GB+ upload that I need to do tonight )

I'm all open to ideas and suggestions and possibly hoping that someone in VMWare is watching and listening. I'm not real happy with Natty and definitely don't like Unity so I will probably remain with Natty and not upgrade to Oncelot (or whatever is is named).

Suggestions are welcome but solutions would be best 😉

BobS

--bs

[betor3]

Hey Bob:

I'm not happy with Natty either.. actually I like gnome 3 way more, so I installed it over Unity,  but that's when I started having problems, although it seems that's no the root cause of the problem.

I wish I could give you solutions, but I guess we're both in the same boat. What is strange is the fact of running X in fallback (VESA) mode completely removes this problem to me (maybe it would be worth for you to try it.. at least you'll be able to work), that's why I thought it had to do with something related to the Radeon driver.

I keep googling every day to see if somebody finds a solution for this. Will let you know if I find something.. please you do the same!

kind regards,

beto

[rwsmith61]

Hi, Beto,

I got around to trying to get my WinXP VM up and running (I need it to run Quicken and pay bills...unfortunately I am not the U.S. and can't ignore my debts 😉

I think the problem is somewhere with the Glib libraries and dependencies and specific to a particular video card (of course that is still to be seen). It may have to do with some underlying changes to Compiz which is needed to support the Natty Unity interface and some of those changes are in the Gnome Classic libaries as well.

I was able to get my WinXP VM running by changing the following in the /etc/vmware/bootstrap file:

VMWARE_USE_SHIPPED_GTK="yes"

This seems to try and make some intelligent decisions as to which libraries should be pulled in. I will note that setting this variable on the command line did not seem to work as expected which is why I suggest setting in the above file.

I may try to reboot later tonight or sometime tomorrow if I get a chance and try to login in using the Compiz-less Gnome window settings/manager..that should be close to equivalent as the safe mode setting you mentioned below.

Regards,

BobS

--bs

[betor3]

Hey Bob:

Sorry for the delay.. I was out traveling...

I tried your suggestion but Im still having the same problem. I agree this, in theory it has to do with the video card and glibc. Cant believe we're the only ones having this problem.

Good for that you manage to solve it for yourself.

If you get to know any other news about this please let me know.

Thanks!

beto