Created attachment 453279 [details]
Our VMCI source package

Created attachment 453282 [details]
Our VSock source package (Requires VMCI symbols)

Created attachment 453286 [details]
Foundation package.  Required by VMCI/VSock RPM packages

I have attached two of our source RPMs that will reproduce this problem along with a necessary binary RPM.  To do so:


Install the vmware-tools-foundation RPM (x86_64... Let me know if you need an i686 version)

rpmbuild --rebuild vmware-tools-vmci-8.5.0.00000-0.src.rpm

Install the resulting RPMs (common and kmod packages...  VSock will not build without these installed)

rpmbuild --rebuild vmware-tools-vsock-8.5.0.00000-0.src.rpm

Attempt to install the VSock RPMs (common will install, kmod will fail)


rpmbuild -qp --provides kmod-vmware-tools-vmci-8.5.0.00000-0.x86_64.rpm
rpmbuild -qp --requires kmod-vmware-tools-vsock-8.5.0.00000-0.x86_64.rpm

You'll see the incompatible VMCI symbols.

Thanks for the bug report. Nice catch on the difference between the "0x" and not "0x" for third party deps. The problem you are having, however is not quite the same. There seems to be a bug somewhere causing a kernel() dep rather than a ksym() dep because the scripts somehow think the kernel is already providing this symbol. Is it a stock Red Hat kernel you are building against?

I will look at this for you. It's not going to be possible to ship this in 6.0 at this stage, however the problem won't affect install-time in any case (it's a build time problem) so we can do an asynchrous package update to solve your problem. I will begin that effort once I get the kernel detail from you.

Jon.

I'm using the stock beta2 kernel, 2.6.32-44.1.el6.x86_64 (SMP)

Thanks for the info. We'll look into it.

Jon, now that RHEL 6 has released with this bug in it, it's a higher priority for us...  We need to build binary modules for the release, but at the moment a few of the generated packages cannot install without --nodeps.

Prioritizing this bug. Thanks. I will work on a fix you can use at build time within a couple of days (easy to modify the RPM macros) and then work out a package update for others - fortunately this is only a build-time bug.

Thank you very much Jon!

Hi Jon,

Haven't seen an update on this in a while. Is this fixed?

Created attachment 483321 [details]
Patch against RHEL 6 Driver Update Program code

Finally approved by legal...  I found three distinct bugs in the code.

1) Incompatible symbols were being generated by find-requires.ksyms and find-provides.ksyms...  They did not match.

2) The checksums being generated by the provides were being truncated of all zeroes while those created in the requires were not, so:

0xe76853ab for example would match, but
0x0a63c7a4 would not.  Provides would cut off the leading zero and call it 0xa63c7a4.

3) Sorts were not occurring consistently, which would mess up the joins...  Two lists with the same sort would not end up in quite the same order.  Though this may have happened because I was using a different sort program than RHEL 6.0 (We're building our packages from other systems).  Regardless, I recommend leaving in the fix as it makes the sorting absolutely explicit.


To fix these:
#1 and #2: I made find-provides.ksyms use the same logic as find-requires.ksyms to generate the symbols.  This will impact backwards compatibility with RHEL 6.0 GA, but since it was broken anyway, it's probably not an issue.  

I changed the fields that were being generated and joined to make it a little more consistent, changing the awks and seds.  The old code looked like it was adapted from RHEL 5 and wasn't actually producing the right results.  Luckily, the side effect of this is that it generated the right requires, but it turns out it wasn't actually doing it properly... The joins were failing, but the fallback mode worked out if you were building an isolated module.  In the case where two modules need to interact (VMCI/VSock and VMCI/VMHGFS in our case), it brought up the error.


#3: sort now ALWAYS sorts on a specific key range.  sort -k2 did not get the same results as sort -k 2,2.  sort -k2 would give differing sorts for different lists, so that a join would not happen properly.  Sorting specifically on the second field via 2,2 ALWAYS sorts consistently.

I separated out the call to uniq...  Feel free to fold it back in with sort -u, but separating it made debugging easier.

Since RHEL 6.1 External Beta has begun, and this bug remains 
unresolved, it has been rejected as it is not proposed as an 
exception or blocker.

Red Hat invites you to ask your support representative to 
propose this request, if appropriate and relevant, in the 
next release of Red Hat Enterprise Linux.

We will look into this for an async update prior to RHEL6.2. I will update this bug shortly.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

(In reply to Comment #4)

> I have attached two of our source RPMs that will reproduce this problem along
> with a necessary binary RPM.  To do so:
>
>
> Install the vmware-tools-foundation RPM (x86_64... Let me know if you need an
> i686 version)
>
> rpmbuild --rebuild vmware-tools-vmci-8.5.0.00000-0.src.rpm

I'm failing to build it: 

# rpm -q vmware-tools-foundation
vmware-tools-foundation-8.5.0.00000-0.x86_64
# rpmbuild --rebuild vmware-tools-vmci-8.5.0.00000-0.src.rpm > /dev/null
warning: InstallSourcePackage at: psm.c:244: Header V3 RSA/SHA1 Signature, key ID 530c79e6: NOKEY
+ umask 022
+ cd /root/rpmbuild/BUILD
+ LANG=C
+ export LANG
+ unset DISPLAY
+ cd /root/rpmbuild/BUILD
+ rm -rf vmci-only
+ /bin/tar -xvvf /root/rpmbuild/SOURCES/vmci.tar
+ cd vmci-only
+ /bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ exit 0
+ umask 022
+ cd /root/rpmbuild/BUILD
+ cd vmci-only
+ LANG=C
+ export LANG
+ unset DISPLAY
+ for flavor in default
+ VMCI_SYMVERS_FILE=/etc/vmware-tools/symvers/vmci-8.5.0.00000-2.6.32-209.el6-default
+ make clean
Using standalone build system.
Makefile:163: Makefile.normal: No such file or directory
make: *** No rule to make target `Makefile.normal'.  Stop.
error: Bad exit status from /var/tmp/rpm-tmp.jgxFR8 (%build)
    InstallSourcePackage at: psm.c:244: Header V3 RSA/SHA1 Signature, key ID 530c79e6: NOKEY
    Bad exit status from /var/tmp/rpm-tmp.jgxFR8 (%build)

---------------------

Makefile contains conditional include $(SRCROOT)/Makefile.normal. But no Makefile.normal is present there. Only Makefile.kernel is available at that location. What's wrong?

>
> Install the resulting RPMs (common and kmod packages...  VSock will not build
> without these installed)
>
> rpmbuild --rebuild vmware-tools-vsock-8.5.0.00000-0.src.rpm
>
> Attempt to install the VSock RPMs (common will install, kmod will fail)
>
>
> rpmbuild -qp --provides kmod-vmware-tools-vmci-8.5.0.00000-0.x86_64.rpm
> rpmbuild -qp --requires kmod-vmware-tools-vsock-8.5.0.00000-0.x86_64.rpm
>
> You'll see the incompatible VMCI symbols.

Martin, thank you for taking a look at this.  From that error, it looks like you will need to install the kernel-devel package and I believe the kernel-source package for your currently running kernel.  This module needs the headers for the currently running kernel, the kernel build system, and the symvers files available.

Once built, install vmware-tools-foundation (which I see you've done), and the newly built common and kmod packages for VMCI, then you'll be able to build VSock with the correct VMCI symbols.  Installation of vmware-tools-vsock-common will succeed, but the vsock kmod package will have mismatched requires (The VMCI package is generated with the wrong Provides)

See comment 27 for a list of bugs I found in the DUP code while fixing the code to work in our build system, there was a bit more going on under this mismatch.

Thank you, Timothy, so I can confirm the fix is effective:

# uname -r
2.6.32-209.el6.x86_64
# rpm -qa | egrep '(vmware|kernel)' | sort
abrt-addon-kerneloops-2.0.4-10.el6.x86_64
dracut-kernel-004-242.el6.noarch
kernel-2.6.32-201.el6.x86_64
kernel-2.6.32-206.el6.x86_64
kernel-2.6.32-209.el6.x86_64
kernel-devel-2.6.32-201.el6.x86_64
kernel-devel-2.6.32-206.el6.x86_64
kernel-devel-2.6.32-209.el6.x86_64
kernel-firmware-2.6.32-209.el6.noarch
kernel-headers-2.6.32-206.el6.x86_64
kmod-vmware-tools-vmci-8.5.0.00000-0.x86_64
libreport-plugin-kerneloops-2.0.5-9.el6.x86_64
vmware-tools-foundation-8.5.0.00000-0.x86_64
vmware-tools-vmci-common-8.5.0.00000-0.x86_64
vmware-tools-vmci-debuginfo-8.5.0.00000-0.x86_64
xorg-x11-drv-vmware-11.0.3-1.el6.x86_64
# rpm -qp --provides kmod-vmware-tools-vmci-8.5.0.00000-0.x86_64.rpm | grep VMCIContext_GetPrivFlags
ksym(VMCIContext_GetPrivFlags) = 0x635e43cb
# rpm -qp --requires kmod-vmware-tools-vsock-8.5.0.00000-0.x86_64.rpm | grep VMCIContext_GetPrivFlags
ksym(VMCIContext_GetPrivFlags) = 0x635e43cb
#

Rechecked it in .211 build. It is fixed.


# uname -r
2.6.32-211.el6.x86_64

# rpm -qa | egrep '(vmware|kernel)' | sort
abrt-addon-kerneloops-2.0.4-6.el6.x86_64
dracut-kernel-004-231.el6.noarch
kernel-2.6.32-211.el6.x86_64
kernel-debug-2.6.32-211.el6.x86_64
kernel-devel-2.6.32-211.el6.x86_64
kernel-firmware-2.6.32-211.el6.noarch
kernel-headers-2.6.32-211.el6.x86_64
kmod-vmware-tools-vmci-8.5.0.00000-0.x86_64
kmod-vmware-tools-vsock-8.5.0.00000-0.x86_64
libreport-plugin-kerneloops-2.0.5-6.el6.x86_64
vmware-tools-foundation-8.5.0.00000-0.x86_64
vmware-tools-vmci-common-8.5.0.00000-0.x86_64
vmware-tools-vsock-common-8.5.0.00000-0.x86_64
xorg-x11-drv-vmware-11.0.3-1.el6.x86_64

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1748.html