Upgrading Debian Etch to Lenny
I’m upgrading my Debian Linux VM’s to their testing release, called Lenny. The upgrade itself is fairly easy and fool-proof, but installing the VMware Tools (110271) is a harder thing to do.
Upgrading Etch to Lenny (source):
- edit /etc/apt/sources.list. Replace all occurences of ‘etch’ with ‘lenny’
- Run apt-get update
- Run apt-get dist-upgrade (twice!)
- Reboot
- Install the kernel headers for your new kernel.
VMware Tools failed to build vmmemtcl module
When running vmware-configure.pl, I first got an error stating that the kernel was built using gcc 4.1.3, but the system was configured to use gcc 4.3.2. I needed to execute the following command to resolve that problem: ‘export CC=/usr/bin/gcc-4.1’. After that, the perl script did executed normally. On building the kernel modules, the vmmemctl module couldn’t be built correctly, exiting with an error about get_info. After a lot of Googling, I discovered that the error I was getting (see screenshot) wasn’t related to the VMware Tools at all, but was caused by the 2.6.26 kernel I was using.
The get_info method has been removed in the 2.6.26 kernel. Hence, the VMware Tools (at least the vmmemctl module) cannot be installed. Other modules in the VMware Tools did not have any problem being compiled.
I started a thread on the VMware Forum to ask for help. Gagravarr pointed out that the VMware Tools (116503) packaged with VMware Server 2 would install fine. I’ve downloaded the linux .tar.gz package, as it is the simplest way to extract the needed linux.iso file.The file can be found at vmware-server-distrib/lib/isoimages/linux.iso. Extract the file, and mount it inside your VM as you would do with usual ISO’s.Do not use ‘Install/Upgrade VMware Tools’, as this will mount the original version.
Following the usual installation steps, everything installed as expected. I now have Debian Lenny with kernel 2.6.26 (and thus paravirtualization!) and the VMware Tools running fine!
Yo !
I got the same problem with VMware Server 2.0.0 build-122956, its got a simple solution, install gcc 4.1 and change your symbolic link
# apt-get install gcc-4.1
# rm /usr/bin/gcc
# ln -s /usr/bin/gcc-4.1 /usr/bin/gcc
according to my opinion, using vmware tools v2 on vmware 3guest is not good idea because of performance.
how about it?
can you see any difference?
dont to the simlink…..
vmware installer honours the environment variable – CC
so
export CC=/usr/bin/gcc-4.1
./vmware-intsall.pl or vmware-config-tools.pl
justinas: the vmware tools are actually the same across all latest released versions of ESX, Workstation, Server and Fusion. There shouldn’t be a great difference in performance.
Terry,
I’m not making any symlinks in the article. Running ‘export CC=etc’ should do the trick, as I already posted in this blogpost.
export CC=/usr/bin/gcc-4.1 didnt work for me. It still complained about using gcc 4.3.2
So i tried the symlink solution instead, and that worked fine
@John: if vmware-config-tools.pl is still complaining after exporting CC, you’ve done something wrong.
Yes, i was doing it in 2 different sessons, my bad
try deleting the symlink gcc pointing gcc-4.3 and create one pointing gcc-4.1
in /usr/bin
# rm gcc
# ln -s gcc-4.1 gcc
It worked for me
Shoop,
Deleting files from /usr/bin manually is never a good idea. Those files are usually managed by you package manager. Deleting GCC is a really, really bad idea, because it is one of the core programs on a Linux machine.
It’s just a symlink to gcc-4.1 not the real directory on /usr/bin so if there’s a problem once you did that you can always delete the symlink again and re-create it pointing at gcc-4.3 …
Sounds like a lot of you are using sudo when trying to install vmware-tools which on the face of it is a good thing. Sudo’s default option of ‘env_reset’ strips the running of the command down to just PATH, HOME, TERM, SHELL, LOGNAME, USER and USERNAME which means that CC is also stripped. There are ways to set sudo to include certain variables, check the man pages for more details.
To quickly install vmware tools either negate the ‘env_reset’ option in your sudoers file ‘!env_reset’ or su/sudo -s to root, set the variable and then run the install script without using sudo.
The other method discussed of moving the symlink to gcc-4.1 and then back again when you’re done installing works as well but it not a long term fix and not really the root issue, sudo’s default behaviour is. Learn how sudo works.
This might not fix Joep’s kernel problem, hopefully others can learn from it though.
Guest OS: Debian Lenny 2.6.26-2-amd64
Vmware 6.5 Wks – VMTools-7.8.5-156735