On Mon, 30 Jul 2018 10:28:28 -0700
Laura Abbott <labbott(a)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.