Red Hat Bugzilla – Bug 428143
rtnetlink userland API change mid-release; 2.6.18-52 -> 2.6.18-59
Last modified: 2008-05-21 11:06:01 EDT
Description of problem: See attached.
diff is for /usr/include/linux/rtnetlink.h between 2.6.18-52.el5 and 2.6.18-63.el5
The changes (removing the address/interface information structures) breaks
various components of clustering, and prevents us from building for 5.2.
Created attachment 291165 [details]
APIs that were removed from .52 -> .63
Doing some research, these definitions were moved to if_addr.h (2.6.19-ish
timeframe?), which also isn't installed as part of the kernel-headers package.
(Userspace apps shouldn't be made to change #includes mid-lifecycle anyway.)
This bugzilla has Keywords: Regression.
Since no regressions are allowed between releases,
it is also being proposed as a blocker for this release.
Please resolve ASAP.
This patch needs to be reverted in our kernel as far as I can tell:
(or at least the part removing the bits from rtnetlink.h)
Alternatively, provide #ifaddr.h in the kernel-headers RPM and possibly:
Lon, IIRC if_addr.h is already included in the kernel-headers rpm. You should
be able to add the code from comment 9 to rtnetlink.h and restore the missing
function. If you can confirm that fixes your abi break, I'll post that solution
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
Hi Neil, it's not in -65:
[lhh@ayanami magma]$ rpm -ql kernel-headers | grep if_addr
[lhh@ayanami magma]$ echo $?
[lhh@ayanami magma]$ rpm -q kernel-headers
If it makes a difference, my desktop is x86_64.
Seems that if_addr.h is in the kernel-devel package but needs to be in
kernel-headers package. I'll move if_addr.h from
/src/kernels/2.6.18-65.el5-x86_64/include/linux and see if the simple workaround
works if I put it in /usr/include/linux.
[root@ayanami linux]# rpm -qf /usr/include/linux/rtnetlink.h
Moving if_addr.h from /usr/src/kernels/`uname -r`/include/linux to
... allowed me to build locally.
Created attachment 291190 [details]
Patch assuming if_addr.h is moved to kernel-headers from kernel-devel
Lon, et al.
You can find kernel and kernel header packages containing a fix for this problem
in brew, under:
Please test them out and confirm that your previously broken builds build
properly again. The kernel-headers package is what you will need. Thanks!
net-snmp package has similar problems with moving IFA_PAYLOAD to unpackaged
if_addr.h. I tried compile with your
kernel-headers-2.6.18-65.el5.bz428143.x86_64.rpm, which resulted in confusing
errors. After some investigation I found problem at if_addr.h:53:
#define IFA_PAYLOAD(n) NLMSG_PAYLOAD(n,sizeof(struct ifaddrmsg)
There is a missing closing bracket at the end of the line ^. How did you
build the kernel with such syntax error???
Compilation of net-snmp succeeds if I add the closing bracket. I would
appreciate if fixed kernel-headers would appear in brew buildroot ASAP, RHEL5.2
user space deadline is at Jan 18 and I'd like some time for tests :) - thanks in
regarding the failure, thats easy, the kernel doesn't use those macros, and as
such it was never instantiated in post-porcessed code, so no opportunity ever
arocse for the compiler to check it. Since you confirmed that it worked, I'll
fix that oversight and post at once.
(In reply to comment #18)
> Since you confirmed that it worked, I'll fix that oversight and post at once.
Please note that I am not original reporter, I wrote that it works for net-snmp,
cluster guys may have different opinion.
* rebuilt openais w/o errors:
cc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -DOPENAIS_LINUX -I../include -fPIC
-fPIC -c -o totemip.o totemip.c
^^ was failing here; no warnings or errors. ;)
* rebuilt fence_xvm / fence_xvmd w/o errors
* tested fence_xvm + fence_xvmd - works; I didn't test on your test kernel -
only on a rebuild w/ the new headers. I'm assuming that since the type sizes
didn't change in the headers that they didn't change in the newer kernel either.
Last test will be ensuring Anaconda builds, but I think it needs to be pushed
before that will even be possible (not sure).
> Last test will be ensuring Anaconda builds, but I think it needs to be pushed
> before that will even be possible (not sure).
The easiest way for me is to have the new kernel packages in a buildroot so I
can do a scratch build of anaconda against it.
As an alternative you can get the dist-5E-qu-candidate mock-config from brew,
make a local buildroot with mock, and update to the test kernel-headers rpm
there for a scratch build.
Which kernel package version should I be waiting on before I can rebuild anaconda?
You can download this test kernel from http://people.redhat.com/dzickus/el5
verified that /usr/include/linux/if_addr.h is in the kernel-headers package
for the -83.el5 kernel... also was able to sucessfully rebuild the net-snmp
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.