2.6.35.10-74 compilation (and build) problems

Jarod Wilson jarod at redhat.com
Thu Jan 6 04:47:41 UTC 2011


On Wed, Jan 05, 2011 at 07:53:38PM -0800, JD wrote:
> On 01/05/2011 06:29 PM, Don Zickus wrote:
...
> > The way the config options work is basically a bunch of templates that
> > override each other as they get stacked on top.  So
> >
> > config-generic is usually the base config that all arches start with
> > config-$ARCH-generic is merged onto config-generic and overrides those
> >      options
> > config-$ARCH-$VARIANT is merged onto that with more overrides
> >
> > the result config blob is full of stuff that may or may not be relevant to
> > the particular type of kernel we are building, therefore we use the
> > for-loop (from earlier in the email), to filter out that cruft.  The magic
> > is 'make ARCH=$ARCH nonint_oldconfig'  (think make oldconfig without the
> > prompting).
> >
> > The output files are kernel-$version-$arch.config.  If you want to copy
> > .config files somewhere, it really should be the kernel-*.config files.
> > But I don't have the .spec file handy to know if those get repeatedly
> > overwritten on a rpmbuild.
> >
> > The way the kernel maintainers set the options is to modify the
> > config-$pickone-generic  file with the option you care about to on/off.
> >
> > But as explained in other threads, we never supported custom configs so no
> > one really designed a process to make it easy.
> >
> 
> Thank you for the elucidation, Don.  I find it very useful,
> as I have struggled with this issue for a long time.
> 
> So, for a sysadmin, who needs a custom configured kernel
> for multiple machines, and wants to produce the custom
> binaries for these machines that have same architecture and
> devices, to enable features and drivers that are not by
> default enabled in the vanilla fedora binary rpm: what is the
> sysadmin to do?
> 
> It seems to me that the rpm packagers need to provide a way
> for the admin to use an existing config file which has enabled
> all that is needed, as a base config file. Thus running rpmbuild
> should somehow use this base config file, and add to it if necessary,
> but at least keep the features/drivers that are enabled in the
> base config file, enabled for the actual build.
> 
> To date, I have not succeeded in producing a kernel with my drivers
> enabled as per an existing config file, using the rpmbuild method.
> PS: my needed drivers are in staging, and they work. But I do not
> seem to be able to use my current .config file 
> (/boot/config-2.6....et...etc)
> as a base config file (such as ~/rpmbuild/SOURCES/config-x86-generic
> (my arch is i686), when building from a new source rpm release.
> It never yielded a kernel with my drivers enabled.
> 
> I did follow the instructions at 
> http://fedoraproject.org/wiki/Docs/CustomKernel
> very very closely, to no avail.
> 
> Maybe I AM doing someting wrong, but I have no idea what that might be.
> 
> So, what do I do? I simply prep from source
> (rpmbuild -bp kernel.spec)
> and then cd to ~/rpmbuild/BUILD/kernel-2.6.35.10-74/linux-2.6.35.i686,
> copy my current kernel's config file to .config, run
> make oldconfig and
> male all
> and that does it.
> The new config file inherits my enabled drivers selections.

>From the kernel spec:

# Dynamically generate kernel .config files from config-* files
make -f %{SOURCE20} VERSION=%{version} configs

And Source20 is Makefile.config, from which with a bit of effort, you can
determine the order in which the various config-* files are smashed
together to form the end result .config files.

I think this topic actually came up once in the past, and an idea to add
an extra layer similar to the 'if rhel' clause in the spec was kicked
around, but never came to fruition. In theory, that file would, if
present, apply additional Kconfig changes from an additional overrides
file. It could be an empty file by default, but obviously named or
documented, so that anyone rebuilding could simply put their assorted
additional config options in there, and they'd always be applied over the
top of the stock config options.

-- 
Jarod Wilson
jarod at redhat.com



More information about the kernel mailing list