title: VMware 2 and RHEL 5.4 link: https://onemoretech.wordpress.com/2009/12/27/vmware-2-and-rhel-54/ author: lembobro description: post_id: 206 created: 2009/12/27 21:14:19 created_gmt: 2009/12/27 21:14:19 comment_status: open post_name: vmware-2-and-rhel-54 status: publish post_type: post

VMware 2 and RHEL 5.4

A while back I ran into some difficulty with recompiling VMware for the latest kernel then available for RHEL/CentOS 5.3, being 2.6.18-164.

After getting around it by using a patched version of the vmnet.tar source file, things worked normally enough until I upgraded to CentOS 5.4, whereupon the VMware admin server became flaky.

After some research, I found that this problem cropped up as a result of the upgrade of the glibc package from 2.5-34 to 2.5-42 that occurs in the move up to RHEL/CentOS 5.4. VMware, it appears, is built using the /lib/libc-2.5 file linked to /lib/libc.so.6 (the link existing for backward compatibility with legacy apps). The big problem is that this upgrade results cascades through the entire gcc toolchain, and is not easily worked around.

The problem and some suggested solutions are related in a CentOS bug report. One suggestion for getting around this was to exclude glibc on all updates. Of course doing that can’t be very good for either system stability or security, since that toolchain is one of the chief contributors to those kinds of issues.

A less compromising solution is to take advantage of VMware’s ability to make use of its own, non-system, libraries and supply it with the old libc that it needs. This can be done by:

1. Getting a copy of the “old” glibc-2.5-34 rpm package from the CentOS archives:

wget -c "http://ftp.linux.ncsu.edu/pub/CentOS/5.3/updates/i386/RPMS/glibc-2.5-34.el5_3.1.i686.rpm"

and extracting libc-2.5.so from it:

rpm2cpio glibc-2.5-34.i386.rpm | cpio -ivd
;

2. Shutting down vmware: /etc/init.d/vmware stop;

3. Creating a directory called /usr/lib/vmware/lib/libc.so.6.old to hold this file, copying the file to the directory and then making a link from the file to libc.so.6. Thus:

mkdir /usr/lib/vmware/lib/libc.so.6.old
cp /tmp/libc-2.5.so /usr/lib/vmware/lib/libc.so.6.old
cd /usr/lib/vmware/lib/libc.so.6.old
ln -s libc-2.5.so libc.so.6;

4. Editing /usr/sbin/vmware-hostd to add a line at the bottom, right before the final eval statement:

export LD_LIBRARY_PATH=/usr/lib/vmware/lib/libc.so.6.old

5. Starting vmware back up /etc/init.d/vmware start.

Of course just because a messy workaround is available, doesn’t mean that some people are going to jump through hoops every time there’s a new security or bug fix update. The fact that VMware can’t use the latest secure and bug fixed code means that VMware itself is now insecure and/or buggy as compared to the rest of the system.

And that’s not good. Not good at all.

Copyright 2004-2019 Phil Lembo