Bug 456765

Summary: kabitool blocks custom kernel builds when kernel version > 2.6.18-53.1.21.el5
Product: Red Hat Enterprise Linux 5 Reporter: Alan Bartlett <ajb>
Component: kernelAssignee: Jon Masters <jcm>
Status: CLOSED ERRATA QA Contact: Mike Gahagan <mgahagan>
Severity: low Docs Contact:
Priority: medium    
Version: 5.4CC: amyagi, andriusb, jwilson, qcai
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 655889 (view as bug list) Environment:
Last Closed: 2011-01-13 20:42:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 626668    
Attachments:
Description Flags
The last few lines of the stdout & stderr (separated) from a failed build.
none
Removes two calls to sys.exit(1) that were added on 2007/11/26 @ 18:21:15
none
don't run kabitool if disabled with kabichk
none
Revised patch for .spec file
none
The last few lines of the stderr.
none
Second revised patch for .spec file
none
Result of build having applied 2nd revised patch to the .spec file.
none
Third revised patch for .spec file
none
Result of build having applied 3rd revised patch to the .spec file.
none
456765-kabi-Don-t-generate-kABI-dependencies-when-building-.patch none

Description Alan Bartlett 2008-07-26 18:35:04 UTC
Description of problem: Highly customised kernels that built successfully
(source <= kernel-2.6.18-53.1.21.el5.src.rpm) with the use of the --without
kabichk option on the rpmbuild command line now fail to build (source >=
kernel-2.6.18-92.el5.src.rpm) due to changes in kabitool. The current kabitool
(dated Nov 26 2007) has two extra lines (both sys.exit(1)) when compared with
the previous version (dated Dec 11 2006). Reverting to the earlier version of
kabitool allow custom kernels to be built.


Version-Release number of selected component (if applicable): 1.3


How reproducible: Always.


Steps to Reproduce:
1.Highly customise a kernel such that it would need to be built with the
--without kabichk on the rpmbuild command line.
2.Attempt the build.
3.
  
Actual results: Build exits with "RPM build errors"


Expected results: Built proceeds to satisfactory conclusion.


Additional info:

Comment 1 Alan Bartlett 2008-07-26 18:35:04 UTC
Created attachment 312712 [details]
The last few lines of the stdout & stderr (separated) from a failed build.

Comment 6 Alan Bartlett 2009-02-14 23:05:57 UTC
Created attachment 331945 [details]
Removes two calls to sys.exit(1) that were added on 2007/11/26 @ 18:21:15

Removes two calls to "sys.exit(1)" that were erroneously added on 2007/11/26 and also the "else:" & "print "blah"" line that preceded each of the above calls.

Comment 7 Don Zickus 2009-02-18 16:51:02 UTC
NAK to the patch.  There was a reason why we added the sys.exit(1) lines to the kabitool.  It was created to catch the situations where developers backported upstream drivers and accidentally removed kabi symbols that we promised to customers we would maintain for the entire life of RHEL-5, ie a safety net.

Removing that safety net is not an option.  Perhaps moving the kabichk check in the spec up a few lines to prevent the tool from running would be more appropriate.  I will attach a completely untested patch, but gives the idea of what I was suggesting.

-Don

Comment 8 Don Zickus 2009-02-18 16:54:00 UTC
Created attachment 332416 [details]
don't run kabitool if disabled with kabichk


Do not run the kabitool if the user is not interested in preventing kabi problems.
I am not sure what the end result will look like and if the -devel packages need certain files on the other side, but this seems like a more workable solution.

Comment 9 Alan Bartlett 2009-02-18 17:22:16 UTC
(In reply to comment #8)
> Created an attachment (id=332416) [details]
> don't run kabitool if disabled with kabichk
> 
> 
> Do not run the kabitool if the user is not interested in preventing kabi
> problems.
> I am not sure what the end result will look like and if the -devel packages
> need certain files on the other side, but this seems like a more workable
> solution.

Thanks Don. I'll have a look at your suggested patch asap and report back my findings, in due course.

Comment 10 Alan Bartlett 2009-02-19 02:24:09 UTC
Created attachment 332492 [details]
Revised patch for .spec file

NAK to your patch, Don. It needs another conditional --

%if %{with_kabichk}
     mv $RPM_BUILD_ROOT/kabi_whitelist $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
%endif

I have another test build in progress, result in due course.

Comment 11 Alan Bartlett 2009-02-19 02:33:09 UTC
Created attachment 332493 [details]
The last few lines of the stderr.

After applying Don's patch to the .spec file, a test build was started using the flag "--without kabichk" on the rpmbuild command line.

The build ultimately failed. This is the last few lines of the stderr -- which provided the info for the revised patch.

Comment 12 Alan Bartlett 2009-02-19 09:56:11 UTC
Created attachment 332518 [details]
Second revised patch for .spec file 

NAK to the first proposed revised patch. Build fails due to missing symsets-$KernelVer.tar.gz file.

Now trying (second revised patch) --

%if %{with_kabichk}
    mv $RPM_BUILD_ROOT/kabi_whitelist $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
    if [ -e $RPM_BUILD_ROOT/Module.kabi ]; then
        mv $RPM_BUILD_ROOT/Module.kabi $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
    fi
    cp symsets-$KernelVer.tar.gz $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
%endif

Comment 13 Alan Bartlett 2009-02-19 09:59:04 UTC
I should make the comment that I'm using the latest 5.3 kernel sources, kernel-2.6.18-128.1.1.el5.src.rpm.

Comment 14 Alan Bartlett 2009-02-19 15:52:18 UTC
Created attachment 332574 [details]
Result of build having applied 2nd revised patch to the .spec file.

A successful build occurred. However, there are three lines output to the stderr during the packaging phase that I do not like --

/usr/local/src/kernel/rpmbuild/SOURCES/find-provides: cannot locate kabideps file: /var/tmp/kernel-2.6.18-128.1.1.el5.bz456765-kabideps
error: /usr/local/src/kernel/rpmbuild/SOURCES/find-provides failed
error: Failed to find Provides:

I would appreciate any advice as how to proceed and resolve this issue.

Comment 15 Alan Bartlett 2009-02-19 23:28:56 UTC
Created attachment 332650 [details]
Third revised patch for .spec file

Comment 16 Alan Bartlett 2009-02-19 23:34:47 UTC
Created attachment 332651 [details]
Result of build having applied 3rd revised patch to the .spec file.

A successful build occurred.

The stdout was "clean". The stderr was "clean".

Please check for any latent problems and advise how you would like me to proceed.

Comment 17 Don Zickus 2009-02-20 01:57:13 UTC
This looks fine.  I'll talk with Jon about this to make sure he is ok with it and try to bring the patch into rhel-5.4 in the next few weeks.

Thanks for the patch and testing.

Comment 20 RHEL Program Management 2009-03-26 16:51:14 UTC
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

Comment 21 Alan Bartlett 2009-03-26 17:00:09 UTC
(In reply to comment #20)
> This request was evaluated by Red Hat Product Management for
> inclusion, but this component is not scheduled to be updated in
> the current Red Hat Enterprise Linux release. If you would like
> this request to be reviewed for the next minor release, ask your
> support representative to set the next rhel-x.y flag to "?".  

Would a human being now translate the above into English, please?

Comment 22 Don Zickus 2009-03-26 17:43:44 UTC
Basically the automated message is saying 'we are at capacity but we can try again next update to get your fix in'.  

I thought we sent these messages later in the cycle.  Regardless your patch is small enough and doesn't really impact anything, so maybe we can still try to bring it in for 5.4.  No promises though.

-Don

Comment 23 Alan Bartlett 2009-03-26 18:09:37 UTC
(In reply to comment #22)
> Basically the automated message is saying 'we are at capacity but we can try
> again next update to get your fix in'.  
> 
> I thought we sent these messages later in the cycle.  Regardless your patch is
> small enough and doesn't really impact anything, so maybe we can still try to
> bring it in for 5.4.  No promises though.
> 
> -Don  

Thanks Don. It now makes perfect sense -- as typed in your first sentence.

As an Englishman, I thought I had a thorough grasp of my native language but that computer generated simulation really pushed the boundaries . . .

Thanks again.

Comment 24 Jon Masters 2009-05-13 19:29:10 UTC
I'm pretty sure I said this before, but I'm ok with the latest patch on this bug. The idea is fine, and touching an empty file if the test is off is ok too.

Comment 26 Alan Bartlett 2009-05-26 12:39:53 UTC
(In reply to comment #24)
> I'm pretty sure I said this before, but I'm ok with the latest patch on this
> bug. The idea is fine, and touching an empty file if the test is off is ok too.  

Great. Thanks Jon. I couldn't find any error in my logic (no matter how hard I tried) but it really needed reviewing / testing by others.

After leaving this issue alone for a while and then going through it afresh, I am still unable to find any flaw. Can that be deemed a suitable re-test (that has been requested of me)?

Comment 27 Alan Bartlett 2009-07-12 15:28:05 UTC
<Big sigh.>

What *does* a mere-mortal have to do to get this fix accepted?

The issue was discovered as soon as 5.2 was released but it was totally ignored, despite being logged here.

5.3 was released with this defect still present and so the "bottom of the pond" was stirred with a big stick, making the water rather muddy. Having done all the required spade- & leg-work and having had the pleasure of communicating with (whom I assume to be) the two main men of the EL5 kernel -- remember, all of this was done very early after the release of 5.3 -- I naively assumed it would appear in 5.4.

Having now looked at the 5.4-beta kernel-2.6.spec file, I realise what a fool I have been in making such an assumption.

Quite honestly, I wonder why I bother.

Comment 28 Andrius Benokraitis 2009-07-13 04:45:24 UTC
Alan - this fix just missed the RHEL 5.4 code freeze many months ago and has since been deferred to RHEL 5.5. We apologize for not notifying you earlier. Everyone here is fine with committing this, but not post-Beta in RHEL 5.4, therefore it will be proposed in RHEL 5.5 (since it's done, hence in MODIFIED state).

Just curious though - if someone was going to run an unsupported version of a RHEL kernel, what's stopping the same person from committing this patch him/herself? 

Thanks!

Comment 31 RHEL Program Management 2009-11-06 18:41:47 UTC
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

Comment 33 Jon Masters 2010-02-26 18:29:21 UTC
Reset to "kernel" component so there's no issue with "driver-upate-program" not being on the planned update list.

Comment 34 RHEL Program Management 2010-05-20 12:48:16 UTC
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
release.

Comment 35 Jon Masters 2010-09-03 05:44:20 UTC
Created attachment 442796 [details]
456765-kabi-Don-t-generate-kABI-dependencies-when-building-.patch

Comment 36 Jon Masters 2010-09-03 05:44:59 UTC
Alan,

Please let me know if there are any remaining issues with this patch, and sorry again that it slipped under the radar before.

Jon.

Comment 37 Alan Bartlett 2010-09-03 15:00:07 UTC
(In reply to comment #36)
> Alan,
> 
> Please let me know if there are any remaining issues with this patch, and sorry
> again that it slipped under the radar before.
> 
> Jon.

Jon,

Thank you for this patch. Having read it twice, line by line, I can say that it will definitely resolve this issue. ;-)

I just hope it makes 5.6 before the cut-off point!

Alan.

Comment 38 Jon Masters 2010-09-07 04:09:59 UTC
Should do. Thanks Alan.

Comment 39 Akemi Yagi 2010-09-18 20:51:33 UTC
Just a note to add that the patch is in the test kernel -221.

http://people.redhat.com/jwilson/el5/

Thanks, Jon.

Akemi

Comment 40 Jarod Wilson 2010-09-20 16:56:43 UTC
Ah, apologies, automated posting of the fact it was included in a test kernel escaped my tools' notice, due to a quirk of specfile-only-patches.

Comment 42 Jon Masters 2010-09-21 05:08:56 UTC
Thanks everyone!

Comment 43 Mike Gahagan 2010-12-08 15:54:07 UTC
I've tested this by patching the kernel to remove a symbol export that maches one of the ones in the kabi list. I can confirm that the patched kernel will not build unless I use the --without kabichk arguement to rpmbuild so this one can be verified. Testing was done with the 2.6.18-236 kernel source.

Comment 45 errata-xmlrpc 2011-01-13 20:42:15 UTC
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 therefore 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.

http://rhn.redhat.com/errata/RHSA-2011-0017.html