Bug 481680 - Kernel 2.6.18-92.el5.src.rpm won't build with NFS
Kernel 2.6.18-92.el5.src.rpm won't build with NFS
Status: CLOSED DUPLICATE of bug 631950
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.2
All Linux
low Severity medium
: rc
: ---
Assigned To: Jeff Layton
Red Hat Kernel QE team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-26 19:44 EST by Elliott Barrere
Modified: 2014-06-18 03:38 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-09-14 15:06:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
The custom config for 2.6.18-128.el5 sources. (66.42 KB, text/plain)
2009-01-27 09:56 EST, Alan Bartlett
no flags Details
The difference between the distro and custom configs. (826 bytes, text/plain)
2009-01-27 09:58 EST, Alan Bartlett
no flags Details
The relevant lines from the stderr of the failed build using 2.6.18-128.el5 sources. (4.09 KB, text/plain)
2009-01-27 09:59 EST, Alan Bartlett
no flags Details
Difference between the distributed kernel configuration and the revised custom kernel configuration. (875 bytes, text/plain)
2009-01-27 18:40 EST, Alan Bartlett
no flags Details
change FSCACHE from tristate to bool (default y) in Kconfig (538 bytes, patch)
2009-02-14 05:10 EST, Akemi Yagi
no flags Details | Diff
Revised patch for the fs/Kconfig file. (697 bytes, patch)
2009-02-14 11:13 EST, Alan Bartlett
no flags Details | Diff
Second revised patch for the fs/Kconfig file. (709 bytes, patch)
2009-02-14 17:38 EST, Alan Bartlett
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
CentOS 3366 None None None Never

  None (edit)
Description Elliott Barrere 2009-01-26 19:44:27 EST
Description of problem:
Can't build custom NFS-capable kernel from kernel-2.6.18-92.el5.src.rpm.

Version-Release number of selected component (if applicable):
kernel-2.6.18-92.el5.src.rpm and kernel-2.6.18-128.el5.src.rpm at least

How reproducible:
Always

Steps to Reproduce:
1. Download/unpack kernel source RPMs
2. Apply custom config (attached)
3. rpmbuild -bb --target=`uname -m` --with baseonly rpmbuild/SPECS/kernel-2.6.spec
  
Actual results:

make: *** [.tmp_vmlinux1] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.6811 (%build)
Bad exit status from /var/tmp/rpm-tmp.6811 (%build)

Additional info:

My original post in the CentOS Community forums is here:
http://www.centos.org/modules/newbb/viewtopic.php?topic_id=18268&forum=37&post_id=66626#forumpost66626
Comment 1 Jeff Layton 2009-01-27 06:54:04 EST
Unfortunately the error you've posted tells me nothing. It just says that the rpm-tmp script failed. Typically we don't support custom configs, but if you can do a bit more legwork and determine where and why your build is falling down, I'll be willing to look at any patches you propose to fix it.
Comment 2 Alan Bartlett 2009-01-27 09:54:05 EST
I can confirm that this issue is present when attempting to build a custom kernel using both the 2.6.18-92.1.22.el5 and 2.6.18-128.el5 sources.

Yes, I know you "don't support custom configs" but, as has previously been agreed, all code shipped *should* compile correctly!

My preliminary investigations show:

In the file include/linux/fscache.h
there are undefined references to:

__fscache_acquire_cookie
__fscache_read_or_alloc_page
__fscache_read_or_alloc_pages
__fscache_relinquish_cookie
__fscache_set_i_size
__fscache_uncache_page
__fscache_write_page

All are surrounded by:

#if defined(CONFIG_FSCACHE) || defined(CONFIG_FSCACHE_MODULE)
//blah
#endif

constructs.
Comment 3 Alan Bartlett 2009-01-27 09:56:29 EST
Created attachment 330091 [details]
The custom config for 2.6.18-128.el5 sources.
Comment 4 Alan Bartlett 2009-01-27 09:58:02 EST
Created attachment 330092 [details]
The difference between the distro and custom configs.
Comment 5 Alan Bartlett 2009-01-27 09:59:38 EST
Created attachment 330094 [details]
The relevant lines from the stderr of the failed build using 2.6.18-128.el5 sources.
Comment 6 Alan Bartlett 2009-01-27 10:06:24 EST
I would recommend that this bug is viewed from the current (as of the date of this comment) sources, 2.6.18-128.el5 

Should it actually be cloned, in view of its heading?
Comment 7 Jeff Layton 2009-01-27 10:14:15 EST
No, we can just work this here.

Yes, it would be nice if it were to compile with any possible configuration. That said, I'm not going to spend any time tracking down a problem that doesn't exist in the configurations that we ship.

If however, you wish to provide patches to fix this problem I'll be happy to review them and if they look sane, propose them internally for a later release.

The symbols that are missing are all fscache symbols, and I notice that you have:

CONFIG_FSCACHE=m

...you might want to try switching that to 'y' and see if it helps. If it does, then the "bug" is just fixing the KConfig dependencies.
Comment 8 Alan Bartlett 2009-01-27 10:23:57 EST
Thanks, Jeff.

I'll look into that asap, unless the OP wishes to test . . . ;-)
Comment 9 Akemi Yagi 2009-01-27 11:14:59 EST
(In reply to comment #7)

> Yes, it would be nice if it were to compile with any possible configuration.
> That said, I'm not going to spend any time tracking down a problem that doesn't
> exist in the configurations that we ship.

Thank you, Jeff.  You have always been helpful.

I understand custom kernels are not supported.  However, I also understand Red Hat wants to make all code compilable including those modules that are shipped disabled [1].  

"Comment #1 From  Prarit Bhargava (prarit@redhat.com)  2008-05-05 10:28:32 EDT   (-) [reply] -------

While we (RedHat) don't include this module in our distro, it should at least
compile."

[1] https://bugzilla.redhat.com/show_bug.cgi?id=445095#c1
Comment 10 Alan Bartlett 2009-01-27 18:40:59 EST
Created attachment 330177 [details]
Difference between the distributed kernel configuration and the revised custom kernel configuration.
Comment 11 Alan Bartlett 2009-01-27 18:49:20 EST
I can confirm that setting CONFIG_FSCACHE=y in the configuration file allows this custom kernel build to succeed.

The attachment (id=330177) shows the difference between the distro & the revised custom config files.

Thank you, Jeff. A correction to the KConfig dependencies, as you mentioned in comment #7, will be the fix.
Comment 12 Jeff Layton 2009-02-12 15:13:08 EST
Great. When you get a KConfig patch, post it here and I'll have a look.

I'll leave NEEDINFO checked for now.
Comment 13 Akemi Yagi 2009-02-14 05:10:30 EST
Created attachment 331906 [details]
change FSCACHE from tristate to bool (default y) in Kconfig

The attached patch will change FSCACHE from tristate to bool in Kconfig.  I am not sure if the default should be set to y or n.  Because the original was M, it should now be y?

I noticed that, in the original Kconfig, FSCACHE "depends on EXPERIMENTAL" but the "tristate" line lacks the term "(EXPERIMENTAL)".  So, this was added in the patched Kconfig on the (newly modified) "bool" line.

And if this is indeed experimental, would it be alright to make it built-in in the kernel?
Comment 14 Alan Bartlett 2009-02-14 11:13:58 EST
Created attachment 331926 [details]
Revised patch for the fs/Kconfig file.

I have removed the "depends on EXPERIMENTAL" for FSCACHE and have added "select FSCACHE" for ROOT_NFS.

This seems to do what is required, when looking via a make menuconfig command, however it should be tested with an actual kernel build.

Due to my current health issue, I may be a little slow with the testing. If anyone should wish to jump in and do it (Akemi ?), please feel free to do so.
Comment 15 Alan Bartlett 2009-02-14 17:38:58 EST
Created attachment 331942 [details]
Second revised patch for the fs/Kconfig file.

Removes "depends on EXPERIMENTAL" and adds "default n" for FSCACHE.

Adds "select FSCACHE" for ROOT_NFS.

This seems to be satisfactory when I test. Independent verification would be advisable.
Comment 16 Alan Bartlett 2010-03-12 08:28:03 EST
Hi Jeff,

Over a year on now. Any movement on this, please?
Comment 17 Jeff Layton 2010-09-14 15:06:05 EDT
I think that the right solution to this problem is just to back out the FS-Cache code altogether. Now that the mount option is disabled, it just gets in the way...

To that end, I've proposed a patch to do this for 5.7. I'm going to close this bug as a duplicate of that bug. If you want to experiment with the patch for this, it's available at my people.redhat.com page, at least until it has been committed or NACK'ed.

*** This bug has been marked as a duplicate of bug 631950 ***
Comment 18 Alan Bartlett 2010-09-14 16:19:10 EDT
(In reply to comment #17)
> I think that the right solution to this problem is just to back out the
> FS-Cache code altogether. Now that the mount option is disabled, it just gets
> in the way...
> 
> To that end, I've proposed a patch to do this for 5.7. I'm going to close this
> bug as a duplicate of that bug. If you want to experiment with the patch for
> this, it's available at my people.redhat.com page, at least until it has been
> committed or NACK'ed.
> 
> *** This bug has been marked as a duplicate of bug 631950 ***

Thanks for the update, Jeff. I thought this bz had been swallowed by a passing black hole . . .  :-)

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