[Vmware-package-maintainers] Bug#438739: vmware-any-any-patch-113

Robert Edmonds edmonds at debian.org
Fri Aug 31 03:51:52 UTC 2007


reopen 438739
retitle 438739 vmware-package: configure any-any vmversion parameter correctly
severity 438739 normal
clone 438739 -1
retitle -1 vmware-package: missing debconf prompts
forcemerge -1 433880

Daniel Knabl wrote:
> Aug 29 20:01:00: vmx| POST(no connection): Version mismatch with vmmon module: expecting 138.0, got 161.0.
> Aug 29 20:01:00: vmx| You have an incorrect version of the `vmmon' kernel module.
> 
> I have recognized the two lines containing [msg.vmmonPosix.badVersion]
> [msg.vmmonPosix.badDriver] but I do not know, what to do, to fix it.
> All the *.deb files were built with the vmware-any-any-update113.tgz
> from the website mentioned in the README.Debian within the
> vmware-package. Kernel-headers fit the running kernel, also the
> make-vmpkg had no output containing errors.
> 
> When I install vmware-server and the any-any-113 patch by hand, not
> the Debian way, everything works fine.

the problem is that the freestanding any-any modules source package
currently builds modules that default to compatibility with vmware
workstation 6.0 / player 2.0.  ideally workstation / player / server
could all use the same set of modules.

you can override the version at module load time with the vmversion
module paramater:

edmonds at chase{0}:~$ modinfo vmmon | grep parm
parm:           vmversion:VMware version you use: 1=VMware 2, 2=GSX 1, 3=VMware 3, 4=VMware 3.2, 5=GSX 2, 6=GSX 2.5, 7=VMware 4, 8=VMware 3.2.1, 9=GSX 2.5.1, 10=VMware 4.5, 11=VMware 4.5.2, 12=GSX 3.2, 13=VMware 5.0, 14=VMware 5.5, 15=Server 1.0, 16=VMware 6.0, 17=TOT (int)

I would suggest creating a file /etc/modprobe.d/vmware with this line:

options vmmon vmversion=17

and then /etc/init.d/vmware-server stop; /etc/init.d/vmware-server
start.  if that doesn't work, try setting vmversion=15.

> Another problem is, that the vmware-server Debian package seems not to
> provide multiple bridged interfaces, no multiple NAT-interfaces, and
> something very annoying, it does NOT provide a way to set the data-dir
> to something other than /srv/vmware. This should be possible with the
> debconf interface in an easy way.  Also, the mui-package can have a
> different port than 902 when running vmware-config-mui.pl, which is
> not available in the Debian package. Why are those vmware-config*.pl
> files no longer available? Is there an important issue to remove them
> from the sources? What about providing the same functionality through
> debconf? This would really be very important, if you want your package
> to be useable in production environment.

the vmware-*.pl install/configure scripts have been removed because they
interact poorly with the .deb packaging, and because they're shipped as
huge, monolithic scripts (that do stupid things like storing both
configuration and primitive package management data in
/etc/vmware/locations) that would be extremely difficult to extract
needed or excise unwanted functionality from.  even if these scripts
could be successfully modified, the modified versions could not be
distributed in vmware-package.

vmware-package is a work in progress; it will take a considerable amount
of scripting to be able to replace vmware-config.pl's flexibility in
setting up arbitrary vmnet interfaces.  by all means, use the
vmware-provided tarball+perl distributions if you feel more comfortable
with them.

I have split this bug into two parts: the any-any compatibility problem
and the lack of a good debconf interface.  the latter bug has been
merged into a similar bug that complains of the same thing.

-- 
Robert Edmonds
edmonds at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/vmware-package-maintainers/attachments/20070830/9da1401d/attachment.pgp 


More information about the Vmware-package-maintainers mailing list