Bug 1295000 - open-vm-tools in EPEL 6 too old
open-vm-tools in EPEL 6 too old
Status: CLOSED ERRATA
Product: Fedora EPEL
Classification: Fedora
Component: open-vm-tools (Show other bugs)
el6
Unspecified Linux
unspecified Severity low
: ---
: ---
Assigned To: Simone Caronni
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-31 12:54 EST by Louis Abel
Modified: 2016-02-18 15:35 EST (History)
4 users (show)

See Also:
Fixed In Version: open-vm-tools-9.10.2-1.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-12 11:54:15 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Louis Abel 2015-12-31 12:54:33 EST
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.
Comment 1 Simone Caronni 2016-01-12 16:42:35 EST
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
Comment 2 Louis Abel 2016-01-12 19:04:51 EST
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.)
Comment 3 Richard W.M. Jones 2016-01-14 09:03:52 EST
(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.
Comment 4 Louis Abel 2016-01-14 10:36:41 EST
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.
Comment 5 Simone Caronni 2016-01-15 04:51:37 EST
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/
Comment 6 Fedora Update System 2016-01-15 04:55:18 EST
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
Comment 7 Fedora Update System 2016-01-16 15:49:38 EST
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
Comment 8 Fedora Update System 2016-02-12 11:54:13 EST
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.
Comment 9 Louis Abel 2016-02-16 15:48:47 EST
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.
Comment 10 Kapetanakis Giannis 2016-02-17 05:19:34 EST
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.
Comment 11 Ravindra Kumar 2016-02-18 15:35:39 EST
(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.

Note You need to log in before you can comment on or make changes to this bug.