On Mon, 30 Jul 2018 10:28:28 -0700 Laura Abbott labbott@redhat.com wrote:
I'm pretty sure it's that last 'make oldconfig' step which is screwing things up and shouldn't be necessary. The checks that are failing are designed to catch differences between what fedora has set in the kernel- fragments and what gets generated after a "make oldconfig". I don't know why copying back again wouldn't work but the script is not perfect and I generally tell people to turn off the checks if they are building with local changes anyway.
Is there a reason you need to do the last "make oldconfig" and copy step? You are duplicating what the kernel build process will do with the configs anyway.
Yeah, I use a custom config tuned to my hardware. I run it to make sure that any new configuration options are presented to me so I can set them before the build. Usually I take the defaults, but not always. Hmmm, your answer sort of makes sense, though the configuration file should only be for x86_64, why is it setting all those other arches? I put at the top x86_64, and the configuration files for the new build come directly from the tar.gz file. rpmbuild tells me it is building a kernel for x86_64, not any other arch. I used to run a make menuconfig after the oldconfig, and then save the config from there. But when the changes in 4.18 stopped, I stopped doing that. Would that make a difference? What's puzzling is that this whole process worked for the kernel on 7/15, no problem whatsoever.
If I just wanted to build the Fedora kernel the way that Fedora does, I would use the koji binaries. No point in wasting the time and energy to do that. But there are *lots* of options and modules that I don't need, and the kernel is much smaller, which I think has advantages.
I'll also look at harald's procedure to see if that makes a difference.
Thanks for taking the time to look at this.