Genkernel 3.4.52 and later versions switched to the new default kernel config. This config is composed from defaults/kernel-generic-config and arch/arch_name/arch-config. Currently options in kernel-generic-config has a priority over arch-config. It seems to be a bug. Reproducible: Always Some options are turned on in arch-config, but turned off in kernel-generic-config and the resulting arch/arch_name/generated_config as well. For example: defaults/kernel-generic-config: # CONFIG_HYPERV is not set arch/x86_64/arch-config: CONFIG_HYPERV=m CONFIG_HYPERV_UTILS=m CONFIG_HYPERV_MOUSE=m CONFIG_HYPERV_STORAGE=m CONFIG_HYPERV_NET=m CONFIG_HYPERV_BALLOON=m resulting arch/x86_64/generated-config: # CONFIG_HYPERV is not set CONFIG_HYPERV_UTILS=m CONFIG_HYPERV_MOUSE=m CONFIG_HYPERV_STORAGE=m CONFIG_HYPERV_NET=m CONFIG_HYPERV_BALLOON=m This is obviously a non-intended behaviour and arch-config should have a priority. You should either 1) fix merge.pl --- merge.pl.bak 2015-10-24 01:08:38.003006031 +0300 +++ merge.pl 2015-11-03 01:47:50.476331291 +0300 @@ -13,7 +13,7 @@ # first, read the override file -open (FILE,"$args[0]") || die "Could not open $args[0]"; +open (FILE,"$args[1]") || die "Could not open $args[1]"; while (<FILE>) { my $str = $_; my $configname; @@ -34,7 +34,7 @@ # now, read and output the entire configfile, except for the overridden # parts... for those the new value is printed. -open (FILE2,"$args[1]") || die "Could not open $args[1]"; +open (FILE2,"$args[0]") || die "Could not open $args[0]"; while (<FILE2>) { my $configname; or 2) exchange arguments in Makefile change: perl merge.pl defaults/kernel-generic-config $(dir $@)arch-config > $@ to: perl merge.pl $(dir $@)arch-config defaults/kernel-generic-config > $@ The first solution seems more intuitive for me. Also, I'm not sure if this should be a separate bug, but I've noticed that the new config has a lot of debugging options turned on (CONFIG_KALLSYMS_ALL, CONFIG_DYNAMIC_DEBUG, CONFIG_DEBUG_INFO). You are basically building a debug version of the kernel. I can't even build a kernel with the new default config on a 10 GiB partition because it runs out of free space.
Is here anybody who can fix the bug?
I see the same issues... Having recently tried using Genkernel 3.4.52 for the first time (to build a 4.3.3-hardened-r4 kernel), I ran into the fact that none of my VMs have enough disk space to successfully complete compilation. Eventually figured out that the new default kernel config from genkernel has enabled various debug options, resulting in the excessive disk usage, and that lead me to this bug. Surely this is not intentional? It seems severely broken to me :(
To be more precise, I'm actually running 3.4.52.3. And the particular option in the default kernel config that is responsible for the excessive disk usage is CONFIG_DEBUG_INFO. Disabling that is sufficient to reduce disk usage to similar levels to kernel builds based around previous genkernel default configs.
I'm worried that this really simle bug is getting zero attention. I have reported it almost three months ago when versions >= 3.4.52 were in the unstable state. But recently new genkernel versions were stabilised in spite of it.
Fixed in git. The root bug of different order for merge.pl affected very few config options, HyperV was one of them. I have fixed that, and then disabled many of the debug options that were enabled after switching from the older kernel configs. In future, please file them as separate bugs.
