I recently installed VMware Workstation 4.5.3.19414-r4 and I am having problems getting bridge network, host-only, NAT to work properly. First, I thought it was the two modules, vmnet and vmmon, not being loaded, so I did modprobe -v vmmon and modprobe -v vmnet. It provide a message stating "install /bin/true" which should not come up. I made sure they come up and they did not. Yes I did depmod -a but that did not help to fix the install /bin/true message. I then use insmod to load the modules and it could not find them. I had to do the following. insmod /lib/modules/`uname -r`/misc/vmmon.ko insmod /lib/modules/`uname -r`/misc/vmnet.ko By doing the commands above, it loaded up the modules. I then deleted "not_configured" in /etc/vmware to run the vmware init scripts but again it could not setup bridge and NAT. Host-only saids it is working, but VMware now tells mean that is a wrong vmmon module version. I remove vmmon and did the following. insmod /lib/modules/`uname -r`/misc/vmmon.ko vmversion=11 I trying running a virtual machine in VMware and works, but it could not connect to ethernet even though host-only is working. I also try reconfigure VMware config so just host-only comes up but not bridge and NAT. Still VMware can not connect to ethernet when loading up a virtual machine. Ok, I got vmmon to work, but for vmnet is a pain in ass. I loaded up a virtual terminal and type sudo tail -f -n 30 /var/log/messages. It stated that vmnet is not the correct symbol version. I am using gentoo-sources version 2.6.16-r12 and did not use genkernel to help me configure and compile the kernel. Also I did not select module versioning in the kernel because I know it will give me problems. If this bug can not be fix within a week which is 10/7/2006, I strongly recommend providing previous versions of VMware Workstation 4.5, so I can use the versions that works. I only have a serial key for VMware Workstation 4 and I do not want to use VMware Player and VMware Server.
Hi Jason, There have recently been some changes to the patches applied to vmware-workstation-4.5*, could you please re-emerge it? You should then also find that running vmware-config.pl no longer asks you to build the modules, that's because that's now all done in it's own ebuild... Then also please re-emerge vmware-modules-1.0.0.11 (do *not* use any version of vmware-modules higher than this) ensuring that as the ebuild is compiling it states it's found the correct kernel directory for the kernel you're running? If that completes error free, and you run etc-update, then please reboot the system and try to start up workstation again. If after that you're still having difficulties, please paste in the exact error messages you're receiving so that we can try to figure out where the problem lies...
Created attachment 98563 [details] Commands and logs through the process of starting VMware Lengthy file, but should be good enough to get an idea of my problems. Jason
See attachment.
Thanks for that Jason, but unfortunately it didn't tell me whether you followed the steps I offered in comment 1. There should be no need to insmod any modules and certainly not with unusual options like vmversion. I also doubt your kernel configuration is the issue. Please re-emerge vmware-workstation, and vmware-modules, then reboot (to ensure you're using the right modules). Please then post the output of vmware-config.pl and then run vmware again. If it's still giving you problems, please post the output from the logs in /var/log/vmware. Thanks... 5:)
It does not matter how I do it. It is always the same every time. Yes, I have vmware-modules-1.0.0.11 installed and no other versions. I made sure that vmnet.ko and vmmon.ko is removed after removing vmware-modules. Also I removed the vmware rules from the udev rules directory after removing vmware-modules. I can reboot infinite amount of times and it will always will not work. It will always show the following when using modprobe. $ modprobe -v vmmon install /bin/true $ modprobe -v vmnet install /bin/true $ lsmod | grep vm $ insmod /lib/modules/2.6.16-gentoo-r12/misc/vmnet.ko && insmod /lib/modules/2.6.16-gentoo-r12/misc/vmmon.ko vmversion=11 $ lsmod | grep vm vmmon 169740 0 vmnet 24100 0 $ modinfo vmmon filename: /lib/modules/2.6.16-gentoo-r12/misc/vmmon.ko author: VMware, Inc. description: VMware Virtual Machine Monitor. vermagic: 2.6.16-gentoo-r12 686 4KSTACKS gcc-3.4 depends: srcversion: 489BEC54F20FF3AFE3A5490 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=TOT (int) $ modinfo vmnet filename: /lib/modules/2.6.16-gentoo-r12/misc/vmnet.ko author: VMware, Inc. description: VMware Virtual Networking Driver. vermagic: 2.6.16-gentoo-r12 686 4KSTACKS gcc-3.4 depends: srcversion: E6FE98A76BF6697DAF0C14D The directory /var/log/vmware exists, but its empty. I did not setup a static IP address for system. It is a dynamic IP address. I also have the required device nodes. $ ls -l /dev/vm* crw-rw---- 1 root vmware 10, 165 Oct 1 17:22 /dev/vmmon crw------- 1 root root 119, 0 Sep 30 02:39 /dev/vmnet0 crw------- 1 root root 119, 1 Sep 30 02:39 /dev/vmnet1 crw------- 1 root root 119, 2 Sep 30 02:39 /dev/vmnet2 crw------- 1 root root 119, 3 Sep 30 02:33 /dev/vmnet3 crw------- 1 root root 119, 4 Sep 30 02:33 /dev/vmnet4 crw------- 1 root root 119, 5 Sep 30 02:33 /dev/vmnet5 crw------- 1 root root 119, 6 Sep 30 02:33 /dev/vmnet6 crw------- 1 root root 119, 7 Sep 30 02:33 /dev/vmnet7 crw------- 1 root root 119, 8 Sep 30 02:33 /dev/vmnet8 crw------- 1 root root 119, 9 Sep 30 02:33 /dev/vmnet9 The logs are repetive every time I remove vmware-workstation and vmware-modules. Also it is repetive every time I install vmware-workstation and vmware-modules. Third it is repetive every time I load the modules. Fourth, it is repetive every time I run a virtual machine.
Created attachment 98581 [details] vmware-config.pl output
Ok thanks Jason. Now that we've got that all established, could you please attach the logs from an "emerge --oneshot vmware-modules", just so I can check the build process for errors, and ensure it's using the right build method. Hopefully we'll get to the bottom of this one yet. Thanks... 5:)
Created attachment 98675 [details] emerge -d -oneshot =vmware-modules-1.0.0.11
Ok Jason, The output of the module compilation shows the following lines at the end: * * /usr/src/linux/System.map not found. * You must manually update the kernel module dependencies using depmod. * These suggest that something's up with the way your kernel was built. Since your dependency map isn't correctly built, modprobe is almost certainly going to fail since it relies on the dependency map to figure out how to load up the modules and stuff. I'd suggest ensuring your kernel has been built correctly and features a System.map, and that both modules-update works without error and that the ebuild no longer gives that message when the modules are rebuilt, and then give the modules a modprobe. If you're still having problems after the modules compile without a warning like that, please report it back here... If you're not, please also report it back here, just so we can close the bug off... 5;)
I still get the same problem when using modprobe even though I have System.map in /usr/src/`uname -r` or /usr/src/linux-2.6.16-gentoo-r12. I still have to use insmod and the full path of the modules. I found a perl file named getversion.pl when I ran ebuild /usr/portage/app-emulation/vmware-modules/vmware-modules-1.0.0.11.ebuild unpack. The perl file depends on VMware workstation to be installed. vmware-modules should be installed after vmware-workstation to make sure the require modules are compiled for the correct version. With this information, I removed vmware-modules and re-emerge it, but I still have the same problems. Then I read through vmware-modules-1.0.0.11.ebuild and I found inherit vmware-mod. I used locate to find the file vmware-mod which is at /usr/portage/eclass/vmware-mod.eclass and read through that file. I found the variable VMWARE_VER and change VME_V55 to VME_V452. I un-emerge the vmware-modues-1.0.0.11 and re-emerge it. Ran depmod -a and loaded the modules. Again modprobe does not work for vmmon and vmnet. VMware gave me more information about can not connect to private network or something. I stop the virtual machine from running and ran /etc/init.d/vmware start. It provide an OK for all including bridge and NAT. Yes, networking now works in virtual machines. Both the eclass file that is mention above and how the two modules are compiled needs to be corrected. I do not mind including a line in /etc/make.conf to state the VMware version that I am using.
Jason, just to give you a little more detail into the build system for vmware-modules that you stumbled upon during your investigations. We make use of the vmware-any-any modules which are patched versions of the official modules that are designed to work with just about any vmware installation. They rely on a perl script called getversion.pl that returns a variables called VMWARE_VME, which specifies how the modules will be built. It requires vmware to be installed to decide this. Unfortunately forcing packages to be installed after another program when they're a requirement of that program is pretty ugly (look up PDEPEND if you're interested). So instead, we forced the particular VMWARE_VME numbers, which is why there are several ebuilds for each VME, 1.0.0.11 corresponds to VME_V452. That allows most of the code to go into vmware-mod.eclass. Since it's a bad idea not to initialize variables, we set VMWARE_VME to be VME_V55 by default in the eclass. If you look just a little bit further, you'd see that in each of the vmware module ebuilds we override the default VMWARE_VME with a specific one for that package (otherwise, why on earth would we have four ebuilds for the same thing?). 5:) What this means is that vmware-modules can be built independently of the vmware packages (even before any are installed) as long as the correct vmware-modules package is used (1.0.0.11 in this case). You'll realise that the order the modules are built in wasn't your problem, since you told me you recompiled vmware-modules again, once vmware-workstation was already installed. Also double checking 1.0.0.11 shows that the VMWARE_VER is correctly set to VME_W452... So I can't really see what it is you're asking to be fixed then? It does however sound as though you finally managed to get your kernel sorted out and the modules built properly, so I'm going to mark this as fixed. Please feel free to reopen the bug if you fully understand the build system and still believe there is an error there...
It seems that the value VME_V452 for VMWARE_VME in vmware-modules-1.0.0.11 does not stick when vmware-mod eclass file is called. That is why I edit the vmware-mod eclass file. I made a backup of the original vmware-mod eclass file before editing it. Why is VMWARE_VME is always equal to VME_V55 in vmware-mod eclass file. It should use an if..then command to check if it is "". What needs to be fixed: * Compiling and installing vmmon and vmnet so modprobe can work properly. * Edit vmware-mod.eclass so the variable VMWARE_VME is not always VME_V55.
It probably would be simple enough to do the following: define VMWARE_VME in the ebuilds *before* the inherit [[ -z "${VMWARE_VME}" ]] && VMWARE_VME=VME_V55 in the eclass...
Fair enough, I'll add that into the overlay tonight and give it a test. I'm still not entirely clear why defining it after the inherit it doesn't override the value. Maybe it's designed to add user variables to the end of existing variables?
Ok, this has now been fixed in the vmware overlay for testing for a few days, and should go into the main portage tree sometime over the weekend. It turns out that VMWARE_VER was used in the BUILD_TARGETS variable which is set at inherit time, so then changing VMWARE_VER in the ebuild was having no effect. Thanks for the catch and being stubborn with me Jason... 5:) Chris, can you let me know when you drop vmware-workstation-3, since I'll also drop vmware-modules-1.0.0.8 at the same time. Is it worth making an announcement on -dev to the effect that it's going?
# Chris Gianelloni <wolf31o2@gentoo.org> (02 Oct 2006) # Masked pending removal on Oct 27. ~app-emulation/vmware-workstation-3.2.1.2242 I already announced it to -dev, too. =]
The line from comment #13 works, but I still have a problem with modprobe for both vmmon and vmnet. In order for the /etc/init.d/vmware and /opt/vmware/workstation/bin/vmware-config.pl scripts to work or to finish with an OK status. I need vmmon and vmnet to load. These scripts uses modprobe, but I had to use insmod /lib/modules/2.6.16-gentoo-r12/misc/vmmon.ko && insmod /lib/modules/2.6.16-gentoo-r12/misc/vmnet.ko to load them. I recently had the previous version, VMware Workstation 4.5.2-8848, installed that did not include the vmware-modules ebuild file. The script /opt/vmware/workstation/bin/vmware-config.pl compiled the required modules and installed them. Did this file screw up the way how modprobe work with the two modules for the next VMware Workstation 4.5 version? Does anybody know how can I correct this if it is my problem?
Jason, I just committed the fixes for vmware-modules (which actually fixed another problem we were having too), so thanks for those! 5:) Please wait an hour or two, remove the vmware overlay, and try emerging vmware-modules-1.0.0.11-r1 and test whether modprobe can load these modules properly or not (again ensuring they're not loaded to begin with)...
I tried vmware-modules-1.0.0.11-r1 at 22:00 mountain time. It still gives me "install /bin/true" when doing modprobe -v vmmon && modprobe -v vmnet. These modules were not loaded before removing vmware-modules-1.0.0.11. I do not have an vmware overlay. I still think it is my problem unless someone can provide me with some suggestions on what to fix. BTW, I tried doing a new Gentoo installation in chroot jail, but a certain program could not compile. The reason why I am doing this to find out if my present installation has a screwed loading vmmon and vmnet modules.
Hiya Jason, The only reference to modprobe -v and install /bin/true is: http://lists.debian.org/debian-user/2006/02/msg01395.html That seems to suggest you should check through your /etc/modules.conf and check for vmmon and/or vmnet. It appears that a common way of disabling modules is to alias them to /bin/true. If you do find mention of them in there, then check the files in /etc/modules.d/ to see if you can find the offending definition. If you don't have either of that file or directory, check for /etc/modprobe.d/ and see if that's it...
I found a way to work around my problems. I did a google search using the phrase "modprobe /bin/true" and foud an install syntax that I can place in /etc/modules.conf or /etc/modprobe.conf. I created a file named /etc/modules.d/vmware to contain the following two lines. Then I did modules-update. install vmmon /sbin/modprobe --first-time --ignore-install vmmon install vmnet /sbin/modprobe --first-time --ignore-install vmnet To test with only running modprobe, I typed "modprobe -v vmmon && modprobe -v vmnet" and it printed. install /sbin/modprobe --first-time --ignore-install vmmon insmod /lib/modules/2.6.16-gentoo-r12/misc/vmmon.ko install /sbin/modprobe --first-time --ignore-install vmnet insmod /lib/modules/2.6.16-gentoo-r12/misc/vmnet.ko It is not not the usual print out that the correct installation gets, but it is work around after using older VMware Workstation 4.5 that does not install vmware-modules. Yes, by running "/etc/init.d/vmware start" works with out any problems. I suggest adding another step to vmware-modules-1.0.0.11 installation to create a file named vmware and place it in /etc/modules.d that contains the two lines that I mentioned, but comment them to provide a workaround option. Though I am not sure if future vmware-modules will benefit with this workaround. I am not sure what to sent this bug right now. It could be a WORKSFORME or TEST-REQUEST.
Jason, I'm afraid you appear to be the only reporter of this particular install /bin/true bug, so it's unlikely that the workaround is required for other people. I would suggest your look through your /etc/modprobe.conf, /etc/modprobe.d/* and /etc/modules.d/* files to see if you can locate the problem. For the time being I don't think this issue requires more testing because we simply can't figure out even how to test what's causing your modprobe issue, so I'm going to mark this as WORKSFORME. I'm going to update the summary to better reflect the problem at the moment, and if other people come across it, then I'll be happy to reopen the issue and keep looking further. Thanks again for helping us diagnose that other problem. Glad you've got vmware working again... 5:)
