app-emulation/vmware-server's init.d script ( /etc/vmware/init.d/vmware ) passes the -f flag to modprobe. This flag is unsupported on my copy of modprobe. Working through the script it executes: miranda ~ # modprobe -s -f vmmon modprobe: invalid option -- f modprobe 2.4.27 Load/Unload modules with dependencies Load module(s): modprobe [-a -n -v ] [-C config ] [ -t type ] pattern OR module1 module2 ... List modules: modprobe [-l ] [-C config ] [ -t type ] pattern note: wildcard patterns should be escaped Show configuration: modprobe [-C config ] -c Remove module(s) or autoclean: modprobe [-C config ] -r [ module ...] options: -a, --all Load _all_ matching modules -c, --showconfig Show current configuration -d, --debug Print debugging information -h, --help Print this message -k, --autoclean Set 'autoclean' on loaded modules -l, --list List matching modules -n, --show Don't actually perform the action -q, --quiet Quiet operation -r, --remove Remove module (stacks) or do autoclean -s, --syslog Use syslog to report -t, --type moduletype Only look for modules of this type -v, --verbose Print all commands -V, --version Show version -C, --config configfile Use instead of /etc/modules.conf miranda ~ # echo $? 255 This fails and thus vmware fails to start. The issue is at line 578 of the script. Altering the line to issue "insmod" instead of modprobe -s -f works and allows vmware to start. This is with the latest version of modutils: == miranda ~ # emerge modutils -ptv These are the packages that would be merged, in reverse order: Calculating dependencies ... done! [ebuild R ] sys-apps/modutils-2.4.27-r1 0 kB == == miranda ~ # emerge --info Portage 2.1.1-r2 (hardened/x86, gcc-3.3.6, glibc-2.3.6-r5, 2.4.32-hardened-r6 i686) ================================================================= System uname: 2.4.32-hardened-r6 i686 Pentium III (Katmai) Gentoo Base System version 1.12.6 Last Sync: Thu, 21 Dec 2006 03:00:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: [Not Present] dev-lang/python: 2.3.5-r2, 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.4.26-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium3 -pipe -mcpu=i686 -fomit-frame-pointer -fforce-addr" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=pentium3 -pipe -mcpu=i686 -fomit-frame-pointer -fforce-addr" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--nospinner" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo/" MAKEOPTS="-j1" PKGDIR="/usr/portage//packages/x86/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage/" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="alsa_pcm_plugins_adpcm alsa_pcm_plugins_alaw alsa_pcm_plugins_asym alsa_pcm_plugins_copy alsa_pcm_plugins_dmix alsa_pcm_plugins_dshare alsa_pcm_plugins_dsnoop alsa_pcm_plugins_empty alsa_pcm_plugins_extplug alsa_pcm_plugins_file alsa_pcm_plugins_hooks alsa_pcm_plugins_iec958 alsa_pcm_plugins_ioplug alsa_pcm_plugins_ladspa alsa_pcm_plugins_lfloat alsa_pcm_plugins_linear alsa_pcm_plugins_meter alsa_pcm_plugins_mulaw alsa_pcm_plugins_multi alsa_pcm_plugins_null alsa_pcm_plugins_plug alsa_pcm_plugins_rate alsa_pcm_plugins_route alsa_pcm_plugins_share alsa_pcm_plugins_shm alsa_pcm_plugins_softvol apache2 bash-completion berkdb bzip2 calendar clamav cli crypt cscope ctype curl dlloader elibc_glibc fontconfig gd gdbm gmp hardened hardenedphp hash imap input_devices_keyboard input_devices_mouse jpeg kernel_linux mhash ming mysql nls pam pcre perl php pic png python readline session spamassassin spell sqlite ssl tcpd truetype userland_GNU userlocales x86 xml2 xorg xpm xsl zip zlib" Unset: CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS ==
I have tried this with the modprobe from both sys-apps/modutils and sys-apps/module-init-tools with the same result; until I modified the script to call ismod instead (see previous post). It looks like it should call insmod with the -s and -f switches: == miranda ~ # rmmod vmmon miranda ~ # insmod -s -f vmmon miranda ~ # echo $? 0 == rather than modprobe. FYI: This change needs to be checked against module-init-tools which is for the 2.6 kernel.
Sorry, you're quite right, I simply modified the old insmod command into a modprobe command, and assumed they worked the same way. Look at the modprobe manpage however, module-init-tools-3.2.2(-r2) does not complain about the -f option and the man page suggests it supports it. If you're having difficulty with that version of module-init-tools, please double check your results as they may be caused by another problem. Either way however it might be best *not* to try forcing the module, since this is probably to ease compatibility with the binary pre-built modules, rather than those compiled from source. Once you get back to me about the latest module-init-tools accepting the flag, I'll alter the patch not to include the -f option...
I'm running a 2.4 kernel. With sys-apps/modutils, modprobe is symlinked to insmod == miranda ~ # ls -l `which modprobe` lrwxrwxrwx 1 root root 6 Dec 22 16:12 /sbin/modprobe -> insmod == Unmerging sys-apps/modutils and emerging sys-apps/module-init-tools; modprobe is it's own executable, but still does not support the -f argument: == miranda ~ # ls -l `which modprobe` -rwxr-xr-x 1 root root 34952 Dec 23 17:43 /sbin/modprobe miranda ~ # modprobe -s -f vmmon modprobe: invalid option -- f modprobe 2.4.27 Load/Unload modules with dependencies Load module(s): modprobe [-a -n -v ] [-C config ] [ -t type ] pattern OR module1 module2 ... List modules: modprobe [-l ] [-C config ] [ -t type ] pattern note: wildcard patterns should be escaped Show configuration: modprobe [-C config ] -c Remove module(s) or autoclean: modprobe [-C config ] -r [ module ...] options: -a, --all Load _all_ matching modules -c, --showconfig Show current configuration -d, --debug Print debugging information -h, --help Print this message -k, --autoclean Set 'autoclean' on loaded modules -l, --list List matching modules -n, --show Don't actually perform the action -q, --quiet Quiet operation -r, --remove Remove module (stacks) or do autoclean -s, --syslog Use syslog to report -t, --type moduletype Only look for modules of this type -v, --verbose Print all commands -V, --version Show version -C, --config configfile Use instead of /etc/modules.conf == I suspect that the difference in behaviour of modprobe /may/ be due to kernel version differences. As I said at the top of this post I'm running 2.4 and even though I know sys-apps/module-init-tools is for the 2.6 kernel, it also works with 2.4 . On my system I know that modprobe won't take the -f argument. == miranda ~ # emerge module-init-tools Calculating dependencies ... done! >>> Emerging (1 of 1) sys-apps/module-init-tools-3.2.2-r1 to / ... ==
Hmmm, insmod should certainly accept -f (since that what vmware originally had). I'm using the 2.6 kernel and on my version of modprobe -h and --help don't work, but -f does and doesn't return an error. I can't tell whether to mark this as INVALID/WONTFIX since it's a mismatch of the tools and the kernel causing the problem, or just to fix it, since the force flag is probably a bit of overkill. What I don't want to do is adversely affect a lot of people's startup of vmware because I removed it. Chris, what's your take on this please?
As you said: I simply modified the old insmod command into a modprobe command, and assumed they worked the same way. Is there anything wrong in reverting back to insmod rather than modprobe? After all, it does what is required and works on the 2.4 Kernel with sys-apps/modutils and sys-apps/module-init-tools.
Yes, insmod returns an error code if the module is already loaded, which then causes the vmware script to bomb out, and create a not_configured file, meaning that next time you try to start the service you have to go through the whole configuration process all over again (or delete the not_configured flag). Modprobe is compatible with both 2.4 and 2.6 and is much more intelligent about adding modules than insmod. I'm still a bit confused as to why the symlinked modprobe (which you reported is what comes with modutils) doesn't work, since it's just running insmod, which should accept the -f argument... Anyway, not to worry, what I'll do is change it in the overlay (if you need instructions on how to test out packages in the overlay, let me know and I'll add them here) and leave it there for a bit of testing by others. If it's all good, I'll push the patches out to the main tree with the next server release... 5:) Please note, this also probably affects the patches for workstation and quite possibly player too...
Please provide instructions for testing packages in overlay (and just this package please) As for: I'm still a bit confused as to why the symlinked modprobe (which you reported is what comes with modutils) doesn't work, since it's just running insmod, which should accept the -f argument... I guess insmod emulates modprobe far too well :-( An alternative solution may be to grep the output of lsmod. i.e. lsmod | grep -q vmmon will return 0 if found, 1 if not. A roundabout way nevertheless.
Philip, you're in luck, I just this minute had to update the ebuilds and removed -f from the modprobe patch on the main tree. I haven't bumped the revision since it's a fairly minor issue and you appear to be the only name subscribed to this bug, but the fix should be in the tree. Please give the servers a couple of hours to get up to date and then resync portage, and recompile the vmware-server package. If you're still suffering problems after this, feel free to reopen this bug... 5:)
