vmware-workstation-8848-r1 compiles fine the modules and load them correctly: Starting VMware services: Virtual machine monitor done Virtual ethernet done Bridged networking on /dev/vmnet0 done vmware-workstation-8848-r2 compiles fine the modules but a module always fail to load: Starting VMware services: Virtual machine monitor done Virtual ethernet done Bridged networking on /dev/vmnet0 failed Reproducible: Always Steps to Reproduce: 1. 2. 3. Portage 2.0.51-r3 (default-linux/x86/2004.0, gcc-3.4.2, glibc-2.3.4.20041021-r0, 2.6.9 i686) ================================================================= System uname: 2.6.9 i686 mobile AMD Athlon(tm) XP-M 2000+ Gentoo Base System version 1.6.5 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.92.0.2-r1 Headers: sys-kernel/linux26-headers-2.6.8.1-r1 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -mtune=athlon-xp -O3 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -mtune=athlon-xp -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distlocks fixpackages sandbox sfperms" GENTOO_MIRRORS="http://ftp.snt.utwente.nl/pub/os/linux/gentoo http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow GAPING_SECURITY_HOLE X acl acpi acpi4linux alsa apache2 avi berkdb bitmap-fonts cdr crypt cscope curl dba dga divx4linux dvd esd f77 fbcon gd gif gpm gtk gtk2 idea imagemagick imap imlib innodb irda java jpeg ldap libwww mbox mmx mozcalendar mozdomi moznoirc mozp3p mpeg mysql ncurses nls nptl nptlonly ntlm oggvorbis opengl oss pam pcmcia pdflib png pnp quicktime readline samba serial session slang snmp socks5 spell sse ssl svga tcpd tetex tiff truetype usb userlocales v4l v4l2 wavelan wifi x86 xv zlib"
I'll look into it. Are you using devfs or udev?
udev bye
Same thing here, running udev exclusively. Portage 2.0.51-r2 (default-linux/x86/2004.2, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.9-gentoo-r1 i686) ================================================================= System uname: 2.6.9-gentoo-r1 i686 AMD Athlon(TM) XP 1700+ Gentoo Base System version 1.4.16 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.14.90.0.8-r1 Headers: sys-kernel/linux-headers-2.4.21-r1 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs candy ccache distlocks sandbox sfperms" GENTOO_MIRRORS="http://mirrors.tds.net/gentoo ftp://mirrors.tds.net/gentoo ftp://ftp.ussg.iu.edu/pub/linux/gentoo http://gentoo.ccccom.com" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="3dfx X aalib alsa apm arts artswrappersuid avi berkdb bitmap-fonts cddb cdr crypt cups divx4linux encode esd f77 fam ffmpeg flac foomaticdb freetype gdbm ggi gif gimp gimpprint gphoto2 gpm gtk2 imagemagick imlib java jpeg junit kde libg++ libwww mad mikmod motif mozsvg mpeg mpeg4 nas ncurses nls oggvorbis opengl oss pam pda pdflib perl php plotutils png ppds python qt quicktime readline ruby sdl slang spell ssl svga tcpd tetex tiff truetype voodoo3 x86 xine xml2 xmms xosd xprint xv xvid zlib"
Apparently the "udev support" in the latest patches is less than ideal. I'll look into it and see what I can come up with.
You might want to (re)consider the patch I posted on http://bugs.gentoo.org/show_bug.cgi?id=68735 ,IMHO this is the best/most simple way to make vmware play nice on a udev only system, until vmware makes the drivers sysfs aware.
I have no intentions on adding any hacks to get around vmware's lack of pure udev support since *THERE ALREADY IS ONE IN GENTOO* in the RC_TARBALL. I see no point in trying to work around something simply because you do not wish to use the RC_TARBALL. Now, that problem has *nothing* to do with this one. This problem is caused by the latest patch not functioning as it is supposed to. In fact, the title is misleading because the module loads fine. You seem to assume that with the new patch, the device nodes are not created, but I can assure you that they are. # ls -aCF /dev/vm* /dev/vmmon /dev/vmnet144 /dev/vmnet191 /dev/vmnet238 /dev/vmnet55 /dev/vmnet0 /dev/vmnet145 /dev/vmnet192 /dev/vmnet239 /dev/vmnet56 /dev/vmnet1 /dev/vmnet146 /dev/vmnet193 /dev/vmnet24 /dev/vmnet57 /dev/vmnet10 /dev/vmnet147 /dev/vmnet194 /dev/vmnet240 /dev/vmnet58 /dev/vmnet100 /dev/vmnet148 /dev/vmnet195 /dev/vmnet241 /dev/vmnet59 /dev/vmnet101 /dev/vmnet149 /dev/vmnet196 /dev/vmnet242 /dev/vmnet6 /dev/vmnet102 /dev/vmnet15 /dev/vmnet197 /dev/vmnet243 /dev/vmnet60 /dev/vmnet103 /dev/vmnet150 /dev/vmnet198 /dev/vmnet244 /dev/vmnet61 /dev/vmnet104 /dev/vmnet151 /dev/vmnet199 /dev/vmnet245 /dev/vmnet62 /dev/vmnet105 /dev/vmnet152 /dev/vmnet2 /dev/vmnet246 /dev/vmnet63 /dev/vmnet106 /dev/vmnet153 /dev/vmnet20 /dev/vmnet247 /dev/vmnet64 /dev/vmnet107 /dev/vmnet154 /dev/vmnet200 /dev/vmnet248 /dev/vmnet65 /dev/vmnet108 /dev/vmnet155 /dev/vmnet201 /dev/vmnet249 /dev/vmnet66 /dev/vmnet109 /dev/vmnet156 /dev/vmnet202 /dev/vmnet25 /dev/vmnet67 /dev/vmnet11 /dev/vmnet157 /dev/vmnet203 /dev/vmnet250 /dev/vmnet68 /dev/vmnet110 /dev/vmnet158 /dev/vmnet204 /dev/vmnet251 /dev/vmnet69 /dev/vmnet111 /dev/vmnet159 /dev/vmnet205 /dev/vmnet252 /dev/vmnet7 /dev/vmnet112 /dev/vmnet16 /dev/vmnet206 /dev/vmnet253 /dev/vmnet70 /dev/vmnet113 /dev/vmnet160 /dev/vmnet207 /dev/vmnet254 /dev/vmnet71 /dev/vmnet114 /dev/vmnet161 /dev/vmnet208 /dev/vmnet255 /dev/vmnet72 /dev/vmnet115 /dev/vmnet162 /dev/vmnet209 /dev/vmnet26 /dev/vmnet73 /dev/vmnet116 /dev/vmnet163 /dev/vmnet21 /dev/vmnet27 /dev/vmnet74 /dev/vmnet117 /dev/vmnet164 /dev/vmnet210 /dev/vmnet28 /dev/vmnet75 /dev/vmnet118 /dev/vmnet165 /dev/vmnet211 /dev/vmnet29 /dev/vmnet76 /dev/vmnet119 /dev/vmnet166 /dev/vmnet212 /dev/vmnet3 /dev/vmnet77 /dev/vmnet12 /dev/vmnet167 /dev/vmnet213 /dev/vmnet30 /dev/vmnet78 /dev/vmnet120 /dev/vmnet168 /dev/vmnet214 /dev/vmnet31 /dev/vmnet79 /dev/vmnet121 /dev/vmnet169 /dev/vmnet215 /dev/vmnet32 /dev/vmnet8 /dev/vmnet122 /dev/vmnet17 /dev/vmnet216 /dev/vmnet33 /dev/vmnet80 /dev/vmnet123 /dev/vmnet170 /dev/vmnet217 /dev/vmnet34 /dev/vmnet81 /dev/vmnet124 /dev/vmnet171 /dev/vmnet218 /dev/vmnet35 /dev/vmnet82 /dev/vmnet125 /dev/vmnet172 /dev/vmnet219 /dev/vmnet36 /dev/vmnet83 /dev/vmnet126 /dev/vmnet173 /dev/vmnet22 /dev/vmnet37 /dev/vmnet84 /dev/vmnet127 /dev/vmnet174 /dev/vmnet220 /dev/vmnet38 /dev/vmnet85 /dev/vmnet128 /dev/vmnet175 /dev/vmnet221 /dev/vmnet39 /dev/vmnet86 /dev/vmnet129 /dev/vmnet176 /dev/vmnet222 /dev/vmnet4 /dev/vmnet87 /dev/vmnet13 /dev/vmnet177 /dev/vmnet223 /dev/vmnet40 /dev/vmnet88 /dev/vmnet130 /dev/vmnet178 /dev/vmnet224 /dev/vmnet41 /dev/vmnet89 /dev/vmnet131 /dev/vmnet179 /dev/vmnet225 /dev/vmnet42 /dev/vmnet9 /dev/vmnet132 /dev/vmnet18 /dev/vmnet226 /dev/vmnet43 /dev/vmnet90 /dev/vmnet133 /dev/vmnet180 /dev/vmnet227 /dev/vmnet44 /dev/vmnet91 /dev/vmnet134 /dev/vmnet181 /dev/vmnet228 /dev/vmnet45 /dev/vmnet92 /dev/vmnet135 /dev/vmnet182 /dev/vmnet229 /dev/vmnet46 /dev/vmnet93 /dev/vmnet136 /dev/vmnet183 /dev/vmnet23 /dev/vmnet47 /dev/vmnet94 /dev/vmnet137 /dev/vmnet184 /dev/vmnet230 /dev/vmnet48 /dev/vmnet95 /dev/vmnet138 /dev/vmnet185 /dev/vmnet231 /dev/vmnet49 /dev/vmnet96 /dev/vmnet139 /dev/vmnet186 /dev/vmnet232 /dev/vmnet5 /dev/vmnet97 /dev/vmnet14 /dev/vmnet187 /dev/vmnet233 /dev/vmnet50 /dev/vmnet98 /dev/vmnet140 /dev/vmnet188 /dev/vmnet234 /dev/vmnet51 /dev/vmnet99 /dev/vmnet141 /dev/vmnet189 /dev/vmnet235 /dev/vmnet52 /dev/vmnet142 /dev/vmnet19 /dev/vmnet236 /dev/vmnet53 /dev/vmnet143 /dev/vmnet190 /dev/vmnet237 /dev/vmnet54
ok, I'm sorry, I misunderstood the problem.
No problem... it happens to us all... =]
"In fact, the title is misleading because the module loads fine. You seem to assume that with the new patch, the device nodes are not created, but I can assure you that they are." The devices nodes are created, but the modules certainly does not load fine here. I have the same problem and lsmod only shows vmmon but not vmnet. So, the title is not misleading and the new patch does not work perfectly for every machine. Anyway, the patch by Michiel works for me.
Perhaps the device nodes are not being created fast enough? Are you using the RC_TARBALL hack?
Perhaps, that could explain why Michiel's patch works. I am not using the RC_TARBALL hack.
Well, my answer is going to be this: Use the tarball... that is what we made it for... That is at leats until VMware get off their butts and add in proper sysfs support.
so. what is the solution ? I have the device in /dev/ > ls -la /dev/vm* crw-rw-rw- 1 root root 10, 165 Nov 9 20:49 /dev/vmmon crw------- 1 root root 119, 0 Nov 9 20:49 /dev/vmnet0 crw------- 1 root root 119, 1 Nov 9 20:49 /dev/vmnet1 crw------- 1 root root 119, 8 Nov 9 20:49 /dev/vmnet8 but when I run vmware-config.pl the problem persist... > lsmod Module Size Used by vmnet 31644 0 vmmon 162604 0 the module is loaded but the bridging can't be completed succesfully... what do I have to do in order to resolve this ?
Try downgrading to -r1... if that works, then I'm going to mask -r2 until I can find a solution for it or until vmware releases a non-broken version.
-r1 works fine as long as I do a "chmod a+r /usr/bin/vmware", so the permission problem should be fixed in -r1 bye
The "permissions problem" is a result of FEATURES="sfperm", which is now a default. The problem is that it automatically removes the +r from any suid binary. You can find out more by checking out bug #59632, which is still open. The simple solution is to add FEATURES="-sfperms" to make.conf if you're running VMware. The "problem" is that sfperm doesn't differentiate between shell scripts and compiled binaries. Shell scripts have to be readable, but compiled applications only need to be executable.
Just a followup to comment 9, the problem is gone with udev-046.
Sweet... In that case, I will unmask -r2 back to ~arch.
Since this was still in ~arch, and udev is ~arch, I would say that this is now RESOLVED-FIXED.
*** Bug 71788 has been marked as a duplicate of this bug. ***
rizzo: is this still happening with udev 049 and vmware-workstation-4.5.2.8848-r2?
Chris I don't see udev-049 in portage tree at all. Latest is 046.
Just to test I re-installed udev-046 this morning, ran udevstart, and vmware-workstation -r2 and it still failed. The modules loads, just fails to bridge.
I forgot to mention that I am using kernel 2.6.10-rc2 and everything loads fine with udev-046. I just booted back to 2.6.9 for testing and bridge networking still doesn't load with udev-046. I am not sure if it is related, but the ChangeLog for udev-046 contains a line that says: "don't wait for sysfs if the kernel(2.6.10-rc2) tells us what not to expect" From my observation, at the end of /etc/init.d/vmware start in 2.6.9, output of ps aux will show hundreds of "wait for sysfs" processes (/etc/hotplug.d/default/05-wait_for_sysfs.hotplug vmnet). In 2.6.10-rc2, there will only be a single vmnet-bridge process.
Donnie, you wanted me to apply a patch to our kernel from this bug. Can you please point me at the patch you want applied?
Daniel, The patch looks to be in 2.6.10-rc2 and not 2.6.9, as comment #24 suggests. I bet Greg KH has a good idea of what exactly it would entail, since it looks like the change to udev reflects the kernel-side change. Unfortunately, I don't have an exact patch. Thanks for checking into this.
Try applying these two patches to 2.6.9 : http://linux.bkbits.net:8080/linux-2.6/cset@1.2026.64.3 http://linux.bkbits.net:8080/linux-2.6/cset@1.2055.13.5 I am not sure what effect it will have. I suspect that udev probably will only listen for these "shortcuts" if it detects a kernel version string of 2.6.10 or newer.
I have no idea what changed, but it's working now with 2.6.9-gentoo-r8. I updated everything on the system a couple of days ago.
Strange... I'm still going to keep this open until there's a vmware-any-any-update that we can attribute to fixing it, or we can find the culprit that kept the module from working in the first place.
This still fails with me with 2.6.9-gentoo-r9
It's really weird for me. When I run vmware-config.pl, everything loads and I can run vmware fine. But on successive restarts, it won't load so I need to rerun vmware-config.pl.
This is fixed if you use gentoo-dev-sources >= 2.6.10 and udev 050. I have not tested previous versions or other kernels.
I confirm this, although I get the permission denied when I try launch the executable now. :p Thanks Chris.
execute /opt/vmware/lib/bin/vmware directly and not the suid script (suid script? arent those doomed to fail?) in the path (/usr/bin/vmware) works for me(tm)
rizzo: blame bug #59632 for that one... I need to get some people testing possible solutions over there.
