src.rpm for latest kernel in koji fails to build with weird errors about config mismatches
Hi,
I build the kernel every few weeks from the koji rawhide src.rpm for the latest kernel version. This has been working fine for the 4.18 kernels until the latest version. Since I'm only building locally for x86_64, I change the nobuildarches to
%define nobuildarches i386 ppc64 s390x %{arm} %{power64} aarch64 ppc64le
That has worked previously, but no longer seems to be effective. I can't see any reason it shouldn't work. There's been the major change of no longer creating header files in the kernel package, but that doesn't seem to impact this. Anyway, I see
Processing /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-aarch64.config ... done Processing /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-armv7hl-lpae.config ... done Processing /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-armv7hl.config ... done Processing /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-i686-PAE.config ... done Processing /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-i686.config ... done Processing /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-ppc64.config ... done Processing /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-ppc64le.config ... done Processing /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-ppc64p7.config ... Found unset config items, please set them to an appropriate value
and then this
+ ./process_configs.sh -n -c kernel 4.18.0 /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-aarch64.config:5810:warning: override: SPARSEMEM_MANUAL changes choice state /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-aarch64.config:6835:warning: override: VIRT_CPU_ACCOUNTING_NATIVE changes choice state /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-aarch64.config:5810:warning: override: SPARSEMEM_MANUAL changes choice state /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-aarch64.config:6835:warning: override: VIRT_CPU_ACCOUNTING_NATIVE changes choice state /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-armv7hl-lpae.config:5846:warning: override: SPARSEMEM_MANUAL changes choice state /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-armv7hl-lpae.config:6894:warning: override: VIRT_CPU_ACCOUNTING_NATIVE changes choice state /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-armv7hl-lpae.config:5846:warning: override: SPARSEMEM_MANUAL changes choice state /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-armv7hl-lpae.config:6894:warning: override: VIRT_CPU_ACCOUNTING_NATIVE changes choice state /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-armv7hl.config:6231:warning: override: SPARSEMEM_MANUAL changes choice state /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-armv7hl.config:7346:warning: override: VIRT_CPU_ACCOUNTING_NATIVE changes choice state /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-armv7hl.config:6231:warning: override: SPARSEMEM_MANUAL changes choice state /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-armv7hl.config:7346:warning: override: VIRT_CPU_ACCOUNTING_NATIVE changes choice state /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-i686-PAE.config:5911:warning: override: UNWINDER_ORC changes choice state /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-i686-PAE.config:6383:warning: override: VIRT_CPU_ACCOUNTING_NATIVE changes choice state /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-i686-PAE.config:5911:warning: override: UNWINDER_ORC changes choice state /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-i686-PAE.config:6383:warning: override: VIRT_CPU_ACCOUNTING_NATIVE changes choice state /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-i686.config:5911:warning: override: UNWINDER_ORC changes choice state /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-i686.config:6383:warning: override: VIRT_CPU_ACCOUNTING_NATIVE changes choice state /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-i686.config:5911:warning: override: UNWINDER_ORC changes choice state /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-i686.config:6383:warning: override: VIRT_CPU_ACCOUNTING_NATIVE changes choice state /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-ppc64.config:5249:warning: override: SPARSEMEM_MANUAL changes choice state /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-ppc64.config:5249:warning: override: SPARSEMEM_MANUAL changes choice state /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-ppc64le.config:5176:warning: override: SPARSEMEM_MANUAL changes choice state /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-ppc64le.config:5176:warning: override: SPARSEMEM_MANUAL changes choice state /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-ppc64p7.config:1686:warning: symbol value 'm' invalid for HOTPLUG_PCI_SHPC /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-ppc64p7.config:1722:warning: symbol value 'm' invalid for HW_RANDOM_TPM /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-ppc64p7.config:1725:warning: symbol value 'm' invalid for HWSPINLOCK /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-ppc64p7.config:2473:warning: symbol value 'm' invalid for LIRC /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-ppc64p7.config:3347:warning: symbol value 'm' invalid for NF_TABLES_ARP /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-ppc64p7.config:3348:warning: symbol value 'm' invalid for NF_TABLES_BRIDGE /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-ppc64p7.config:3349:warning: symbol value 'm' invalid for NF_TABLES_INET /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-ppc64p7.config:3350:warning: symbol value 'm' invalid for NF_TABLES_IPV4 /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-ppc64p7.config:3351:warning: symbol value 'm' invalid for NF_TABLES_IPV6 /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-ppc64p7.config:3353:warning: symbol value 'm' invalid for NF_TABLES_NETDEV /home/stan/rpmbuild/BUILD/kernel-4.17.fc28/linux-4.18.0-0.rc6.git3.1.20180729.fc28.x86_64/configs/kernel-4.18.0-ppc64p7.config:3475:warning: symbol value 'm' invalid for NVMEM error: Bad exit status from /var/tmp/rpm-tmp.LvChTe (%prep)
The logic in the spec file says it should ignore config files for any nobuild architectures, but it isn't. I found a workaround by setting
%define listnewconfig_fail 0 %define configmismatch_fail 0
even if there were patches, which of course there always are. But I didn't have to do this before, so something isn't right somewhere. I don't see how this could have built successfully in koji with the logic in the spec file in place.
On Sun, 29 Jul 2018 10:12:04 -0700 stan stanl-fedorauser@vfemail.net wrote:
Hi,
I build the kernel every few weeks from the koji rawhide src.rpm for the latest kernel version. This has been working fine for the 4.18 kernels until the latest version. Since I'm only building locally for x86_64, I change the nobuildarches to
%define nobuildarches i386 ppc64 s390x %{arm} %{power64} aarch64 ppc64le
That has worked previously, but no longer seems to be effective. I can't see any reason it shouldn't work. There's been the major change of no longer creating header files in the kernel package, but that doesn't seem to impact this. Anyway, I see
[snip]
In case it has any bearing, I built, and installed, the kernel-headers package successfully by pruning the arches to x86 only, and renaming the tar.xz source to have the same name as the kernel I built. I did it after rebooting into the new kernel, in case there were any dependences for the headers. I'm not sure if that matters or not, but it worked this way.
On 07/29/2018 10:43 AM, stan wrote:
On Sun, 29 Jul 2018 10:12:04 -0700 stan stanl-fedorauser@vfemail.net wrote:
Hi,
I build the kernel every few weeks from the koji rawhide src.rpm for the latest kernel version. This has been working fine for the 4.18 kernels until the latest version. Since I'm only building locally for x86_64, I change the nobuildarches to
%define nobuildarches i386 ppc64 s390x %{arm} %{power64} aarch64 ppc64le
That has worked previously, but no longer seems to be effective. I can't see any reason it shouldn't work. There's been the major change of no longer creating header files in the kernel package, but that doesn't seem to impact this. Anyway, I see
[snip]
In case it has any bearing, I built, and installed, the kernel-headers package successfully by pruning the arches to x86 only, and renaming the tar.xz source to have the same name as the kernel I built. I did it after rebooting into the new kernel, in case there were any dependences for the headers. I'm not sure if that matters or not, but it worked this way.
I'm not seeing this on my machine locally with a quick 'fedpkg prep'. This is the change I made
diff --git a/kernel.spec b/kernel.spec index 85bb6fa1..c105d3b2 100644 --- a/kernel.spec +++ b/kernel.spec @@ -327,7 +327,8 @@ Summary: The Linux kernel # Which is a BadThing(tm).
# We only build kernel-headers on the following... -%define nobuildarches i386 +# %define nobuildarches i386 +%define nobuildarches i386 ppc64 s390x %{arm} %{power64} aarch64 ppc64le
%ifarch %nobuildarches %define with_up 0
It seems like something picked up an old kernel configuration settings. Can you be more explicit about what steps you did to get the failing setup?
On Mon, 30 Jul 2018 08:11:21 -0700 Laura Abbott labbott@redhat.com wrote:
I'm not seeing this on my machine locally with a quick 'fedpkg prep'. This is the change I made
diff --git a/kernel.spec b/kernel.spec index 85bb6fa1..c105d3b2 100644 --- a/kernel.spec +++ b/kernel.spec @@ -327,7 +327,8 @@ Summary: The Linux kernel # Which is a BadThing(tm).
# We only build kernel-headers on the following... -%define nobuildarches i386 +# %define nobuildarches i386 +%define nobuildarches i386 ppc64 s390x %{arm} %{power64} aarch64 ppc64le %ifarch %nobuildarches %define with_up 0
It seems like something picked up an old kernel configuration settings. Can you be more explicit about what steps you did to get the failing setup?
I downloaded the src.rpm from koji, and then used rpm -ivh to install it into the ~/rpmbuild tree. Expanded the src with rpmbuild -bp kernel.spec I used the last build config file to run make oldconfig with no errors or additions. Then I copied that config to the local config file so it would become the actual config during build.
Then just a build with rpmbuild -bb kernel.spec
I don't see where any config files that weren't in the src.rpm could come from, as the BUILD directory is recreated every time the -bb command is run. I have some other kernel-4.xx files in there from earlier builds, but that has never been a problem before. What is the difference between where 'fedpkg prep' gets its *.config files and the *.config files in the src.rpm?
Am 30.07.2018 um 18:02 schrieb stan:
Then just a build with rpmbuild -bb kernel.spec
I don't see where any config files that weren't in the src.rpm could come from, as the BUILD directory is recreated every time the -bb command is run. I have some other kernel-4.xx files in there from earlier builds, but that has never been a problem before. What is the difference between where 'fedpkg prep' gets its *.config files and the *.config files in the src.rpm?
the BUILD directory yes, but SOURCES which is propageted by "rpm -ivh" not - that's why i have a "build-src-rpms.sh" so that i can kill everything within SPECS and SOURCES and doing a fresh "rpm -ivh SRPMS/*.rpm" to keep everything clean
On Mon, 30 Jul 2018 18:12:42 +0200 Reindl Harald h.reindl@thelounge.net wrote:
the BUILD directory yes, but SOURCES which is propageted by "rpm -ivh" not - that's why i have a "build-src-rpms.sh" so that i can kill everything within SPECS and SOURCES and doing a fresh "rpm -ivh SRPMS/*.rpm" to keep everything clean
Thanks, I'll look into this to be sure it isn't happening.
On Mon, 30 Jul 2018 10:55:48 -0700 stan stanl-fedorauser@vfemail.net wrote:
On Mon, 30 Jul 2018 18:12:42 +0200 Reindl Harald h.reindl@thelounge.net wrote:
the BUILD directory yes, but SOURCES which is propageted by "rpm -ivh" not - that's why i have a "build-src-rpms.sh" so that i can kill everything within SPECS and SOURCES and doing a fresh "rpm -ivh SRPMS/*.rpm" to keep everything clean
Thanks, I'll look into this to be sure it isn't happening.
This seems to have been the issue. I cleaned anything related to kernel configuration out of the ~/rpmbuild/SOURCE directory, reinstalled the kernel src.rpm, followed my usual procedure to create a kernel-local config, and the kernel began the build as usual. That is, it got past the point where this error was occurring. I didn't continue the build because it would just be a repeat of yesterday's.
Thanks again.
On 07/30/2018 09:02 AM, stan wrote:
I downloaded the src.rpm from koji, and then used rpm -ivh to install it into the ~/rpmbuild tree. Expanded the src with rpmbuild -bp kernel.spec I used the last build config file to run make oldconfig with no errors or additions. Then I copied that config to the local config file so it would become the actual config during build.
Then just a build with rpmbuild -bb kernel.spec
I don't see where any config files that weren't in the src.rpm could come from, as the BUILD directory is recreated every time the -bb command is run. I have some other kernel-4.xx files in there from earlier builds, but that has never been a problem before. What is the difference between where 'fedpkg prep' gets its *.config files and the *.config files in the src.rpm?
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.
Thanks, Laura
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.
kernel@lists.fedoraproject.org
-
Laura Abbott -
Reindl Harald -
stan