#139 Issue `closed`: ISO image on VMware guest (with VMware-Tools installed) is 140MB¶

Labels: cleanup, discuss / RFC

dagwieers opened issue at 2012-07-30 10:35:¶

An image created on a VMware guest with VMware-Tools installed, creates a 140MB ISO image. The breakdown of the big diskspace consumers are:

15M     /bin/
66M     /lib/
11M     /lib64/
292M    /usr/

breaking this further down to the most detailed/relevant view:

28M     /lib/firmware/
37M     /lib/modules/
23M     /usr/lib/vmware-tools/lib32/
27M     /usr/lib/vmware-tools/lib64/
215M    /usr/lib/vmware-tools/modules/

So I guess instead of including the complete /usr/lib/vmware-tools/, we need to look at being a bit more smart about it. I think we can exclude /usr/Lib/vmware-tools/modules/ completely. An RPM based installation of VMware-Tools might also be better than the example manual installation :-/

dagwieers commented at 2012-07-30 10:48:¶

The inclusion of the complete /usr/lib/vmware-tools/ directory inflates the rescue image greatly. I want to understand the goals of including this complete directory:

prep/GNU/Linux/28_include_vmware_tools.sh:

#  $Id$
# 
#  recent vmware tools (or maybe it is just open-vm-tools on SUSE) keep their modules
#  outside the /lib/modules path. To cope with that we add the vmware-tools if vmxnet
#  is loaded but modinfo cannot find it.

if lsmod | grep -q vmxnet ; then
        if ! modinfo vmxnet >&8 2>&1; then
                COPY_AS_IS=( "${COPY_AS_IS[@]}" /usr/lib*/vmware-tools )
                Log "Including '/usr/lib*/vmware-tools'"
        fi
fi

As I don't see a good reason to include the complete VMware-Tools, but also don't want to add the complete VMware-Tools modules directory (containing modules for all sorts of kernels for all sorts of distributions) is there not a better solution for this situation ?

Either move the modules (and dependencies) directly into /lib/modules/... or something even better ?

PS On RHEL6 the VMware modules are part of the kernel shipped by Red Hat. So I doubt we even need this directory at all.

gdha commented at 2012-07-30 11:34:¶

I think this was added by Schlomo? We better wait until he is back...to understand the background of it.

dagwieers commented at 2012-07-30 11:52:¶

The reason why it fails on RHEL6 is because the VMware network module is called vmxnet3, and so the first match works, but the second fails (as if the module is not in the normal modules directory). But even if I correct this for RHEL6, the reported problem still exists for those distributions using vmxnet as part of VMwareTools.

gdha commented at 2012-10-12 12:13:¶

@dagwieers can this issue be closed? Or are we still waiting on feedback?

dagwieers commented at 2012-10-12 12:31:¶

This is something we should improve IMO. It makes no sense to include everything under the sun, if we only need to have the modules for our specific kernel. So I would keep this issue open until this improvement is implemented.

I moved it to the "Rear future" milestone since it's not blocking us, but if someone interested in fixing this he can find the cause and understands the what and the why. I could implement what I think is required, but have no means to test it myself, so I prefer to not do it myself.

Reiner030 commented at 2014-10-16 23:42:¶

On my testsystem it looks good - so the task can "finally" closed ? ;)

root@rear-test ~ # uname -a
Linux rear-test 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux
root@rear-test ~ # vmware-checkvm
VMware software version 6 (good)
root@rear-test ~ # rear -V
Relax-and-Recover 1.16.1 / Git
root@rear-test ~ # ls -lh /var/lib/rear/output/
total 70M
-rw------- 1 root root 70M Oct 15 01:06 rear-rear-test.iso

gdha commented at 2014-10-17 08:19:¶

+1: we also have no impact of the vmware-tools

[Export of Github issue for rear/rear.]

#139 Issue closed: ISO image on VMware guest (with VMware-Tools installed) is 140MB¶