I have found a bug in the generic linux (e.g. non os-specific) vmware tools upgrade logic. I don't know where to report bugs, so I'm starting a communities thread. Perhaps somebody can take action, or point me in the right direction.
Automatically upgrading vmware tools on a 64-bit Debian 6.0 guest fails because /bin/sh is a symlink to /bin/dash.
To reproduce:
- Have a 64-bit Debian 6.0 guest os running, with an out-of-date vmware tools installed (for example, after moving the vm from 5.0 to a 5.1 host)
- From vSphere Client, initiate "Install/Upgrade VMware Tools" for that vm
- Select "Automatic Tools Upgrade" without any "Advanced Options"
- Observe that the upgrade will eventually timeout and fail.
The problem is that the run_upgrader.sh script that executes inside the guest uses the following logic to select an upgrader..
# Check userland bitness.
if LANG=C file -- "$SHELL" | grep 64-bit >& /dev/null;
then
UPGRADER=$UPGRADER64;
else
UPGRADER=$UPGRADER32;
fi
In this particular case, $SHELL is /bin/sh, which is a symlink to /bin/dash.
So, when LANG=C file -- "$SHELL" is executed, the following is output...
/bin/sh: symbolic link to `dash'
And since that output does not contain "64-bit", the 32-bit upgrader is selected. This is incorrect.
Subsequently, when the 32-bit upgrader is executed, the following shows in /var/log/vmware-tools-upgrader.log...
Wed Apr 24 13:27:56 PDT 2013
Executing "/tmp/vmware-root/vmware-tools-upgrader-32 "
/tmp/vmware-root/run_upgrader.sh: line 64: /tmp/vmware-root/vmware-tools-upgrader-32: No such file or directory
/tmp/vmware-root/run_upgrader.sh: line 64: /tmp/vmware-root/vmware-tools-upgrader-32: Success
There are a few solutions to this:
- Use "file -L" instead of "file" (so that symlinks are resolved)
- Don't use $SHELL, but instead use a file that is known to not be a symlink
- Use some other mechanism to determine the architecture, such as uname -m