Description of problem: The open-vm-tools package available in EPEL 6 is much older than what's currently in RHEL 7's base. 9.4.6 (EPEL6) vs 9.10.2 (EL7) Version-Release number of selected component (if applicable): 9.4.6 How reproducible: Always, part of EPEL repository. Steps to Reproduce: 1. Deploy RHEL 6 or derivative 2. Install EPEL repo 3. yum install open-vm-tools Actual results: # yum install open-vm-tools Loaded plugins: product-id, rhnplugin, security, subscription-manager, : versionlock This system is receiving updates from RHN Classic or RHN Satellite. Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package open-vm-tools.x86_64 0:9.4.6-1.el6 will be installed . . . --> Running transaction check ---> Package libdnet.x86_64 0:1.12-6.el6 will be installed ---> Package libicu.x86_64 0:4.2.1-12.el6 will be installed --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: open-vm-tools x86_64 9.4.6-1.el6 epel 402 k . . . Expected results: At least version 9.10.2 Additional info: I was able to successfully rebuild to 9.10.2 by making the following changes. * Removed all patches listed in the RPM * Added to BuildRequires BuildRequires: libmspack-devel BuildRequires: openssl-devel BuildRequires: procps-devel BuildRequires: xerces-c-devel * Added to obsoletes, because deploypkg is compiled with 9.10.2 in EL7 Obsoletes: open-vm-tools-deploypkg * Changed the %configure section %configure \ --without-kernel-modules \ --disable-static \ --enable-deploypkg \ --without-xmlsecurity * Added to preun section if [ "$1" = "0" -a \ -e %{_bindir}/vmware-checkvm -a \ -e %{_bindir}/vmware-rpctool ] && \ %{_bindir}/vmware-checkvm &> /dev/null; then %{_bindir}/vmware-rpctool 'tools.set.version 0' &> /dev/null || /bin/true fi * Added to postun section if [ "$1" = "0" ]; then \ rm -rf %{_sysconfdir}/vmware-tools/GuestProxyData &> /dev/null || /bin/true fi ** Warning messages in /var/log/messages after installing to a VM ** Dec 31 17:47:43 app1 vmsvc[19498]: [ warning] [vmsvc] SOCKET failed to create socket, error 97: Address family not supported by protocol Dec 31 17:47:43 app1 vmsvc[19498]: [ warning] [vmsvc] SimpleSock: Couldn't get VMCI socket family info. The RPM does update on a RHEL 6 machine successfully and does report to VMware that the tools are running (guest managed). However, I would like to note that even though I made this build work, I do not want to push it out to production until others have successfully made a rebase and it has been in QA and passed. I have not attempted to rebase to version 10 which is in Fedora 23, as I attempted to keep EL6 and EL7 aligned as close as possible. If there is another bugzilla that involves rebasing, please close as necessary.
The last time I tried, new versions of the tools would not build on RHEL 6; but this one works as you pointed out. I've made a new build, rebasing onto the RHEL 7 package and removing all the conditionals for the other distributions, pretty much like the RHEL 7 pacakge: http://koji.fedoraproject.org/koji/buildinfo?buildID=710770 Can you check that everything is ok for you before I push it to the testing updates? (In reply to Louis Abel from comment #0) > * Added to obsoletes, because deploypkg is compiled with 9.10.2 in EL7 > Obsoletes: open-vm-tools-deploypkg I'm not sure I got this point, can you explain? For the moment I've not added it, but I can trigger another rebuild with any required change before pushing the update. Thanks. --Simone
Hello! When Red Hat released an updated open-vm-tools on RHEL 7's base, it refused to update because of open-vm-tools-deploypkg. There were conflicts, basically. This is because they added --enable-deploypkg to the configure options (which is what I did for my build, and your scratch build above does). That's the reason why, for my own sake/testing, I added that it obsoletes the deploypkg package because it has the same functionality now. It's no longer separate packages. The deploypkg package is primarily for letting VMWare automation tools to work with templates. They are guest image customization tools. (I personally believe Red Hat should have had an obsoletes for their EL7 package, because it caused a decent amount of headache to track down the issue.)
(In reply to Louis Abel from comment #2) > When Red Hat released an updated open-vm-tools on RHEL 7's base, it refused > to update because of open-vm-tools-deploypkg.[...] Please don't post comments which are not relevant to the current bug. The deploypkg issue is being tracked already in bug 1291894.
Richard, The question was in regard to why I had put an obsoletes line for deploypkg in my internal test builds. I was never aware that there was a separate bug for that particular issue for EL7.
Thanks for all the information. There does not seem to be a deploypkg package for RHEL 6 [1]. I can only see the closed source tools for RHEL 6 and previous [2]: So I'm leaving the obsolete away for now. [1] http://packages.vmware.com/packages/ [2] http://packages.vmware.com/tools/releases/latest/
open-vm-tools-9.10.2-1.el6 has been submitted as an update to Fedora EPEL 6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-6c12e8a733
open-vm-tools-9.10.2-1.el6 has been pushed to the Fedora EPEL 6 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-6c12e8a733
open-vm-tools-9.10.2-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
During my initial testing, I was not receiving non-fatal errors during an installation or update of open-vm-tools. I have some VM's that give me an error that doesn't seem to affect the overall working of the package. It operates as expected. error reading information on service vgauthd: No such file or directory Running Transaction Installing : libicu-4.2.1-12.el6.x86_64 Installing : libdnet-1.12-6.el6.x86_64 Installing : libmspack-0.5-0.1.alpha.el6.x86_64 Installing : open-vm-tools-9.10.2-1.el6.x86_64 error reading information on service vgauthd: No such file or directory warning: %post(open-vm-tools-9.10.2-1.el6.x86_64) scriptlet failed, exit status 1 on-fatal POSTIN scriptlet failure in rpm package open-vm-tools-9.10.2-1.el6.x86_64 If this requires another bugzilla, please let me know and I will file a separate bug report.
I have this errors after upgrading to open-vm-tools-9.10.2-1.el6 Feb 17 11:34:05 vmsvc[1944]: [ warning] [vmsvc] SOCKET failed to create socket, error 97: Address family not supported by protocol Feb 17 11:34:05 vmsvc[1944]: [ warning] [vmsvc] SimpleSock: Couldn't get VMCI socket family info.
(In reply to Kapetanakis Giannis from comment #10) > I have this errors after upgrading to open-vm-tools-9.10.2-1.el6 > > Feb 17 11:34:05 vmsvc[1944]: [ warning] [vmsvc] SOCKET failed to create > socket, error 97: Address family not supported by protocol > Feb 17 11:34:05 vmsvc[1944]: [ warning] [vmsvc] SimpleSock: Couldn't get > VMCI socket family info. That's normal because vmtoolsd will prefer to use VMCI socket whenever it can. It should be just once when service starts or when there is a channel reset because of a VM snapshot/VMotion operation. If it is not bothering you, you can ignore it.