Bug 783527

Summary:	Config files in /boot are not the config of the running kernel
Product:	[Fedora] Fedora	Reporter:	penguinbait <mlewis>
Component:	kernel	Assignee:	John W. Linville <linville>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	16	CC:	gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-03-01 18:35:07 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description penguinbait 2012-01-20 17:57:10 UTC

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1

both config files in /boot

config-3.1.7-1.fc16.x86_64
config-3.1.9-1.fc16.x86_64  

Do not have CONFIG_IWLWIFI and other missing options.  This module is built in both kernels referenced but the /boot/config files are NOT correct for the kernels installed.

Pull kernel source from kernel.org with git
switch to branch to build
cp /boot/config-3.1.9-1.fc16.x86_64 .config (in kernel source dir)
make oldconfig
make
make modules
make modules_install
make install

Then I realized I have no wifi, I looked at original file 
config-3.1.9-1.fc16.x86_64 which did not have ALL the options.  They not not set CONFIG_IWLWIFI does not exist, and make oldconfig does not fix this.

Reproducible: Always

Steps to Reproduce:
1.grep CONFIG_IWL /boot/config-3.1.9-1.fc16.x86_64
2.
3.
Actual Results:  
(NULL)

Expected Results:  
CONFIG_IWLWIFI=m

Comment 1 Josh Boyer 2012-01-23 16:02:28 UTC

This is probably a result of the f16 kernel using the compat-wireless mechanism.  I don't know of a great way to have the resulting /boot/config-<kver> reflect what compat-wireless is building.

John, thoughts?

Comment 2 John W. Linville 2012-01-24 14:03:51 UTC

The /boot/config-<kver> files only reflect the configuration for the base kernel.  The compat-wireless bits are built externally, although we have combined them in the kernel package for Fedora.

Adding the compat-wireless bits to the /boot/config-<kver> files directly wouldn't really be correct either -- those files should reflect the base kernel only.  We might consider adding the config.mk file from the compat-wireless package or something, but I'm not sure if that is worthwhile either.

Anyway, the observation that CONFIG_IWLWIFI is not set in those files is correct.  The base kernel was built without it (and several other options), so as to ensure there was no conflict between drivers in the base kernel and those built from the compat-wireless package.  If you want to build an upstream tree with your Fedora kernel config then you will either need to modify the config enough to turn-on your wireless drivers or you will need to build the compat-wireless package to go along with your upstream kernel.

Comment 3 penguinbait 2012-01-24 17:15:23 UTC

Personally I think this should in some way be fixed.  A user should not have to go through the hassle of building a kernel and then find out they need to start all over.  Additionally its not clear to me exactly what options are missing and building a kernel, then to find out you missed something else is a freaking pain.  My personal suggestion is either put out a config that represents the actual kernel running or remove the config file from /boot so as to not waste users time and effort.

Comment 4 John W. Linville 2012-01-24 18:22:24 UTC

I'm sorry, but I just don't see this as a big hardship for someone that wants to build a kernel from sources rather than using the package provided by Fedora.

Comment 5 Josh Boyer 2012-03-01 18:35:07 UTC

We actually started installing the config.mk from compat-wireless in /boot a while ago.  When F16 rebases to the 3.3 kernel, we won't be using compat-wireless any longer so this won't be an issue going forward.

Either way, this bug has been fixed.