The file /proc/config.gz
isn't updated when I rebuild kernel with changed configuration (from make menuconfig
). For instance, I have rebuilt kernel with BLK_DEV_IO_TRACE
which works fine but config.gz
is still showing # CONFIG_BLK_DEV_IO_TRACE is not set
. Isn't the .config
file in the root directory of kernel source which is included in kernel binary when we enable CONFIG_IKCONFIG
?
And BTW config.gz
shows CONFIG_IKCONFIG=y
while in actual it is CONFIG_IKCONFIG=m
.
I'm using Android NDK standalone GCC toolchain to build this kernel (3.18 arm64).
NOTE:
Just to clarify, as it's causing confusion, I'm sure my new kernel is running with new configuration. I've enabled a long list of changes to my default configuration which are working now, a number of userspace programs depend on these configurations:
CONFIG_IKCONFIG=m
CONFIG_IKCONFIG_PROC=y
CONFIG_VETH=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_NFS_FS=m
CONFIG_NFS_V2=m
CONFIG_NFS_V3=m
CONFIG_NFS_V4=m
CONFIG_NFS_V4_1=y
CONFIG_NFS_V4_2=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_V4_SECURITY_LABEL=y
CONFIG_KEYS_DEBUG_PROC_KEYS=y
CONFIG_OVERLAY_FS=m
CONFIG_UTS_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_CLS_CGROUP=m
CONFIG_CGROUP_NET_CLASSID=y
CONFIG_NETFILTER_XT_MATCH_CGROUP=m
CONFIG_NETFILTER_NETLINK=m
CONFIG_ISO9660_FS=m
CONFIG_SQUASHFS=m
CONFIG_UDF_FS=m
CONFIG_UNIX_DIAG=m
CONFIG_PSTORE=y
CONFIG_FANOTIFY=y
CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y
CONFIG_DEBUG_FS=y
CONFIG_FTRACE=y
CONFIG_BLK_DEV_IO_TRACE=y
config.gz
shows Linux/arm64 3.18.71 Kernel Configuration
while the current is Linux/arm64 3.18.140 Kernel Configuration
. Also it doesn't matches with any of the 16 There are 185 differences (88 additions, 97 drops) between actual config and *defconfig
files in arch/arm64/configs/
.config.gz
. Initially I used arch/arm64/configs/franco_mido_defconfig
; the one provided by custom kernel developer.
Best Answer
I should have done more research prior to posting this question, but I thought might be I was missing something. For reference, the problem reveals to be specific to my kernel source. Custom kernel developer applied a patch to always include an older configuration in kernel binary. So this should be undone (considering the risks, if any):