Hi,
Rawhide builds of the kernel for x86 have started failing with a segfault:
https://koji.fedoraproject.org/koji/taskinfo?taskID=27618835
+ ./process_configs.sh -n -c kernel 4.18.0 ~/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git9.1.fc29.i686 ~/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git9.1.fc29.i686/configs Processing /builddir/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git9.1.fc29.i686/configs/kernel-4.18.0-aarch64.config ... /builddir/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git9.1.fc29.i686/configs/kernel-4.18.0-aarch64.config:5814:warning: override: SPARSEMEM_MANUAL changes choice state /builddir/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git9.1.fc29.i686/configs/kernel-4.18.0-aarch64.config:6846:warning: override: VIRT_CPU_ACCOUNTING_NATIVE changes choice state make[1]: *** [scripts/kconfig/Makefile:64: olddefconfig] Segmentation fault (core dumped)
I don't have a setup to try and debug this so I've disabled building on i686 for now. I know the kernel can be a bit of a PITA to deal with so I'm happy to answer questions about how things work for whoever wants to take a swing at fixing this.
Hi Laura,
I tried cross-building it in the latest mock (1.4.11-1), with mock -r fedora-29-i386 --forcearch=i386 kernel-4.18.0-0.rc0.git9.1.fc29.src.rpm and it failed right after installing repos and keys: […] Finish: dnf install ERROR: Exception(kernel-4.18.0-0.rc0.git9.1.fc29.src.rpm) Config(fedora-rawhide-i386) 1 minutes 16 seconds INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-i386/result ERROR: Could not find useradd in chroot, maybe the install failed?
The logs don't mention something useful, and I won't be able to test on actual 32-bit hardware until later tonight.
Well, after I moved past the useradd error, I was able to build the package just fine (in a 64-bit VM), so it could be a problem with the version of mock used by the builders.
On 06/15/2018 04:42 AM, Alexander Ploumistos wrote:
Well, after I moved past the useradd error, I was able to build the package just fine (in a 64-bit VM), so it could be a problem with the version of mock used by the builders.
Thanks for checking. I'm going to continue keeping the i686 kernel disabled until someone gives me the go ahead that it's building okay in mock.
Thanks, Laura
I messed up, I didn't notice that the actual kernel was disabled in the spec file. I took the source rpm that is being currently built in koji (4.18.0-0.rc0.git10.1), I removed the nobuildarches macro and the build failed, albeit at a different step:
Processing /builddir/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git10.1.fc29.i686/configs/kernel-4.18.0-i686-PAE.config ... /builddir/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git10.1.fc29.i686/configs/kernel-4.18.0-i686-PAE.config:5910:warning: override: UNWINDER_ORC changes choice state /builddir/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git10.1.fc29.i686/configs/kernel-4.18.0-i686-PAE.config:6381:warning: override: VIRT_CPU_ACCOUNTING_NATIVE changes choice state make[1]: *** [scripts/kconfig/Makefile:64: olddefconfig] Segmentation fault (core dumped) make: *** [Makefile:536: oldnoconfig] Error 2
Why do we still need the PAE config? Anyway, sorry to have wasted your time. If anyone else has any ideas, please chime in.
On Fri, Jun 15, 2018 at 2:50 PM Alexander Ploumistos < alex.ploumistos@gmail.com> wrote:
I messed up, I didn't notice that the actual kernel was disabled in the spec file. I took the source rpm that is being currently built in koji (4.18.0-0.rc0.git10.1), I removed the nobuildarches macro and the build failed, albeit at a different step:
Processing /builddir/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git10.1.fc29.i686/configs/kernel-4.18.0-i686-PAE.config ... /builddir/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git10.1.fc29.i686/configs/kernel-4.18.0-i686-PAE.config:5910:warning: override: UNWINDER_ORC changes choice state
/builddir/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git10.1.fc29.i686/configs/kernel-4.18.0-i686-PAE.config:6381:warning: override: VIRT_CPU_ACCOUNTING_NATIVE changes choice state make[1]: *** [scripts/kconfig/Makefile:64: olddefconfig] Segmentation fault (core dumped) make: *** [Makefile:536: oldnoconfig] Error 2
Why do we still need the PAE config? Anyway, sorry to have wasted your time. If anyone else has any ideas, please chime in.
The PAE config is still there because these kernels get rebased back to
F27 still, and PAE is still built there. That said, if the config were gone, the segfault would just happen elsewhere.
Justin
On 06/15/2018 12:50 PM, Alexander Ploumistos wrote:
I messed up, I didn't notice that the actual kernel was disabled in the spec file. I took the source rpm that is being currently built in koji (4.18.0-0.rc0.git10.1), I removed the nobuildarches macro and the build failed, albeit at a different step:
Processing /builddir/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git10.1.fc29.i686/configs/kernel-4.18.0-i686-PAE.config ... /builddir/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git10.1.fc29.i686/configs/kernel-4.18.0-i686-PAE.config:5910:warning: override: UNWINDER_ORC changes choice state /builddir/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git10.1.fc29.i686/configs/kernel-4.18.0-i686-PAE.config:6381:warning: override: VIRT_CPU_ACCOUNTING_NATIVE changes choice state make[1]: *** [scripts/kconfig/Makefile:64: olddefconfig] Segmentation fault (core dumped) make: *** [Makefile:536: oldnoconfig] Error 2
Why do we still need the PAE config? Anyway, sorry to have wasted your time. If anyone else has any ideas, please chime in.
This was still segfaulting on a test build as of last night and the i686 kernel is still disabled. Again, I'm happy to answer questions about the kernel for whomever wants to debug the segfault.
Thanks, Laura
On Wed, Jun 20, 2018 at 07:32:05 -0700, Laura Abbott labbott@redhat.com wrote:
This was still segfaulting on a test build as of last night and the i686 kernel is still disabled. Again, I'm happy to answer questions about the kernel for whomever wants to debug the segfault.
Is this something that is useful to test building kernel source or does one need to be rebuilding from the source rpm in mock to really test it?
I can build from source in a reasonable amount of time on a rawhide i686 machine, but building an SRPM is likely to take more than a day and I'm not very comfortable with mock. I usually just use rpmbuild to rebuild packages from srpms when I need to do that.
If sinple builds from source are good enough, I'm willing to do a bisect to find the change that triggered the problem.
On 06/20/2018 09:24 AM, Bruno Wolff III wrote:
On Wed, Jun 20, 2018 at 07:32:05 -0700, Laura Abbott labbott@redhat.com wrote:
This was still segfaulting on a test build as of last night and the i686 kernel is still disabled. Again, I'm happy to answer questions about the kernel for whomever wants to debug the segfault.
Is this something that is useful to test building kernel source or does one need to be rebuilding from the source rpm in mock to really test it?
I can build from source in a reasonable amount of time on a rawhide i686 machine, but building an SRPM is likely to take more than a day and I'm not very comfortable with mock. I usually just use rpmbuild to rebuild packages from srpms when I need to do that.
If sinple builds from source are good enough, I'm willing to do a bisect to find the change that triggered the problem.
It's not clear, the segfault is coming from running the Kconfig binary so it seems like it should be something that would be reproducible building kernel source but it's also possible something in the mock environment is setting different build flags that might affect things. It's at least worth testing building kernel from source to start and see if the environment makes a difference.
Thanks, Laura
On Wed, Jun 20, 2018 at 11:10:37 -0700, Laura Abbott labbott@redhat.com wrote:
It's not clear, the segfault is coming from running the Kconfig binary so it seems like it should be something that would be reproducible building kernel source but it's also possible something in the mock environment is setting different build flags that might affect things. It's at least worth testing building kernel from source to start and see if the environment makes a difference.
I'll start one up. It might not be done before I go to sleep. But I expect it to complete one way or the other by tomorrow morning.
On Thu, Jun 14, 2018 at 18:09:00 -0000, Laura Abbott labbott@fedoraproject.org wrote:
Rawhide builds of the kernel for x86 have started failing with a segfault:
Is there a bugzilla entry for this?
I may want to record a .config file or possibly some output after my test builds and a bugzilla would probably be better than attaching this info to a reply to this thread.
On 06/20/2018 12:07 PM, Bruno Wolff III wrote:
On Thu, Jun 14, 2018 at 18:09:00 -0000, Laura Abbott labbott@fedoraproject.org wrote:
Rawhide builds of the kernel for x86 have started failing with a segfault:
Is there a bugzilla entry for this?
I may want to record a .config file or possibly some output after my test builds and a bugzilla would probably be better than attaching this info to a reply to this thread.
You can use https://bugzilla.redhat.com/show_bug.cgi?id=1592374 for now