Kernel_upgrade Exec[vmware_config_tools] runs every time on Ubuntu 12.04 LTS
whiteadam opened this issue · 23 comments
Hey Craig,
First off, awesome script, thanks!
I'm having an issue on Ubuntu where this outputs every time the script is run. This does not happen on Cent or RHEL:
Notice: /Stage[main]/Vmwaretools::Kernel_upgrade/Exec[vmware_config_tools]/returns: executed successfully
It's probably something I've done. Any ideas?
Thanks,
-Adam
Hi Adam, sorry for the delay in replying to this! Are you running 32bit or 64bit Ubuntu?
Hey Craig, no worries. It's 64-bit, here's a uname -a just in case:
3.2.0-45-generic #70-Ubuntu SMP Wed May 29 20:12:06 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
This happens with Ubuntu 13.04 as well:
3.8.0-23-generic #34-Ubuntu SMP Wed May 29 20:22:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
I've tried serveral reboots to see if it's something to do with the new modules not yet loaded because the new kernel isn't live (or some other wacky sync problem with old kernel, old modules, new kernel and new modules) but this fails to resolve the issue.
Could you both search for the location of the vmci.ko module file on your systems? The exec will always run unless that file is present (on my 12.04 installs it's in /lib/modules).
vmci.ko isn't present on my system at all.
vmci.ko is not present on my system either.
Ok, looking at line https://github.com/craigwatson/puppet-vmwaretools/blob/master/manifests/kernel_upgrade.pp#L28
The whole /lib/modules/${::kernelrelease}/misc directory is missing
[root@gold:/lib/modules] # ls
3.8.0-19-generic 3.8.0-22-generic 3.8.0-23-generic
[root@gold:/lib/modules] # cd 3.8.0-23-generic/
[root@gold:/lib/ ⦠/modules/3.8.0-23-generic] # ls
build modules.alias.bin modules.dep.bin modules.symbols
initrd modules.builtin modules.devname modules.symbols.bin
kernel modules.builtin.bin modules.order
modules.alias modules.dep modules.softdepI've just checked, vCentre reports that the VMWare Tools are installed and the correct version.
Perhaps -d doesn't install VMCI on this distro by default?
I figured it out. It's because build-essential isn't installed.
So I did this on 12.04.2:
- Uninstall VMware Tools
- Re-Install VMware Tools with -d
- Confirmed vmci.ko was still not present
- sudo apt-get install build-essential
- Re-Install VMware Tools with -d
- Confirmed vmci.ko was present (/lib/modules/3.2.0-45-generic/misc/vmci.ko)
- Uninstalled VMware Tools again
- Added the include to the node definition
- Ran puppet agent --test and confirmed installation
- Ran puppet agent --test again and confirmed error was gone
So, I guess to fix this we just need to add an install for build-essential. I'm new to puppet, but if I get a spare minute I'll fork it and try to toss it in.
-Adam
Strange, build-essential should be installed by the module as it stands. Can you try pulling the master from GitHub (Aaron submitted #11 last night to fix an issue with build-essential)?
Pulled newest master, uninstalled VMware Tools, gcc, and build-essential.
Ran puppet agent --test (twice)
Confirmed Working.
Yay! Thanks guys.
Hmm, this is not resolved for me. build-essential is properly installed, and there are many vm based .ko drivers in /lib/modules/${::kernelrelease}/kernel/drivers but no vmci.ko
I might the same uninstall and purge provess as described by @whiteadam and see if vmci.ko appears with a manual install.
Give it a whirl. It works for me without error now. Just run vmware-uninstall.pl (or something like that)
I've found that checking for vmci.ko to determine if vmware tools is already installed isn't really reliable. On Ubuntu 12.04 64bit I don't get a vmci.ko regardless of the presence of build-essential and the kernel headers. Also, http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1025260 suggests vmci.ko isn't necessary (and even useless if VMCI is disabled, which seems to be the default). I switched the check in kernel_upgrade.pp to 'creates => "/lib/modules/${::kernelrelease}/kernel/drivers/scsi/vmw_pvscsi.ko",', but maybe there's another, better candidate as well.
This is also a problem on RHEL/CentOS 5.9 (x86_64). The updated check for vmw_pvscsi isn't reliable:
[root@webinf-centos5-puppetclient ~]# locate vmci.ko
/lib/modules/2.6.18-348.6.1.el5/misc/vmci.ko
[root@webinf-centos5-puppetclient ~]# uname -a
Linux webinf-centos5-puppetclient 2.6.18-348.6.1.el5 #1 SMP Tue May 21 15:29:55 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux
[root@webinf-centos5-puppetclient ~]# puppet agent --confdir /etc/puppet --onetime --no-daemonize --verbose
Info: Retrieving plugin
8<-- snip --8<
Info: Caching catalog for webinf-centos5-puppetclient.dhcp.mathworks.com
Info: Applying configuration version '1371504607'
Notice: /Stage[main]/Vmwaretools::Kernel_upgrade/Exec[vmware_config_tools]/returns: executed successfully
Notice: Finished catalog run in -7.71 seconds
[root@webinf-centos5-puppetclient ~]# locate vmw_pvscsi
[root@webinf-centos5-puppetclient ~]#
I can't seem to find a module that is reliably built cross-platform, so this may require a case statement or something to assign a target to validate based on platform? Just spit-balling here.
It looks like 'vmxnet3.ko' exists across every platform I have available:
CentOS 6
[root@webinf-centos6-puppetclient ~]# lsb_release -sd
"CentOS release 6.4 (Final)"
[root@webinf-centos6-puppetclient ~]# find /lib/modules/$(uname -r) -name "vmxnet3.ko"
/lib/modules/2.6.32-358.11.1.el6.x86_64/kernel/drivers/net/vmxnet3/vmxnet3.ko
CentOS 5
[root@webinf-centos5-puppetclient ~]# lsb_release -sd
"CentOS release 5.9 (Final)"
[root@webinf-centos5-puppetclient ~]# find /lib/modules/$(uname -r) -name "vmxnet3.ko"
/lib/modules/2.6.18-348.6.1.el5/misc/vmxnet3.ko
Ubuntu 12.10
root@webinf-ubuntu1210-puppetclient:~# lsb_release -sd
Ubuntu 12.10
root@webinf-ubuntu1210-puppetclient:~# find /lib/modules/$(uname -r) -name "vmxnet3.ko"
/lib/modules/3.5.0-25-generic/kernel/drivers/net/vmxnet3/vmxnet3.ko
Ubuntu 12.04.02
root@webinf-ubuntu1204-puppetclient:~# lsb_release -sd
Ubuntu 12.04.2 LTS
root@webinf-ubuntu1204-puppetclient:~# find /lib/modules/$(uname -r) -name "vmxnet3.ko"
/lib/modules/3.2.0-45-generic/kernel/drivers/net/vmxnet3/vmxnet3.ko
I'm working on a quick case statement that will set the appropriate path based on which OS is being run. I should hopefully have a pull request this afternoon.
Pull request submitted! Tests welcome!
Thanks for the pull request Ryan!
One thing, however - can you confirm that vmxne3.ko doesn't appear in any of those distros out-of-the-box without VMware Tools installed - I think I remember reading somewhere that the vmxnet drivers are included in the kernel?
Ah crap. You're right. This is a physical box:
redrobot ~ # find /lib/modules/$(uname -r) -name "vmxnet3.ko"
/lib/modules/3.8.0-25-generic/kernel/drivers/net/vmxnet3/vmxnet3.ko
Drawing board... time to go back to it.
I'm closing this request for now as it hasn't seen any recent activity. If anyone is still seeing this bug, please either comment or submit a new ticket.
I stil have this issue on Ubuntu 12.04 systems. vmwaretools is installed and working however
vmci.ko does not exist on the system.
OK, if I update to the latest version of vmwaretools, its fine. sorry about that.