Red Hat Bugzilla – Bug 481680
Kernel 2.6.18-92.el5.src.rpm won't build with NFS
Last modified: 2014-06-18 03:38:26 EDT
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
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
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)
My original post in the CentOS Community forums is here:
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.
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:
All are surrounded by:
#if defined(CONFIG_FSCACHE) || defined(CONFIG_FSCACHE_MODULE)
Created attachment 330091 [details]
The custom config for 2.6.18-128.el5 sources.
Created attachment 330092 [details]
The difference between the distro and custom configs.
Created attachment 330094 [details]
The relevant lines from the stderr of the failed build using 2.6.18-128.el5 sources.
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?
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:
...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.
I'll look into that asap, unless the OP wishes to test . . . ;-)
(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 .
"Comment #1 From Prarit Bhargava (firstname.lastname@example.org) 2008-05-05 10:28:32 EDT (-) [reply] -------
While we (RedHat) don't include this module in our distro, it should at least
Created attachment 330177 [details]
Difference between the distributed kernel configuration and the revised custom kernel configuration.
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.
Great. When you get a KConfig patch, post it here and I'll have a look.
I'll leave NEEDINFO checked for now.
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?
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.
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.
Over a year on now. Any movement on this, please?
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 ***
(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 . . . :-)