On Wed, Jul 7, 2021 at 9:41 AM stan via kernel <kernel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Hi, > I'm building the 5.14 kernel from > kernel-5.14.0-0.rc0.20210706git79160a603bdb.11.fc35.src.rpm > I've run into two issues. > > The first is to do with bpftool. I see in the comments that it is > supposed to be disabled in Fedora. But, it still has a buildrequires:, > and there is a segment of code that is not protected even if bpftool is > turned off. > > %ifnarch armv7hl > # Generate vmlinux.h and put it to kernel-devel path > bpftool btf dump file vmlinux format c > $RPM_BUILD_ROOT/$DevelDir/vmlinux.h > %endif > > Because bpftool is turned off, this chokes. bpftool is a builreq, the failure there has to do with where you are building it. You need bpftool from 5.13 to build a 5.14 snapshot. The error is unclear, but that is the solution. This is actually a very useful bit in that we will use that vmlinux.h to build kernel-tools for Fedora. It is built in kernel for ELN. As I rebase stable Fedora to 5.13, it will require a prebuild of kernel-tools for 5.13 followed by the kernel build. > > The second is to do with a symbolic link. > > > # Move the devel headers out of the root file system > mkdir -p $RPM_BUILD_ROOT/usr/src/kernels > mv $RPM_BUILD_ROOT/lib/modules/$KernelVer/build $RPM_BUILD_ROOT/$DevelDir > > # This is going to create a broken link during the build, but we don't use > # it after this point. We need the link to actually point to something > # when kernel-devel is installed, and a relative link doesn't work across > # the F17 UsrMove feature. > ln -sf $DevelDir $RPM_BUILD_ROOT/lib/modules/$KernelVer/build > > The comment says that symbolic link should not matter, but rpmbuild > complains that files are being packaged that are not registered (?, > from memory). Building something else right now, but if you need the > exact error message, I can regenerate it later. This code is in > prior kernel spec files without problems. It seems that something > is being more assiduous now. I've tried various things to work around > this, but they haven't worked. I guess that is because I don't really > understand why this symbolic link is being created. What is your > suggestion for how to fix this? Would need to know what link this is. I know perf messed up the makefile and created a link in the wrong place. We don't package this link, but our command to remove it wasn't looking in the right place. Rather than fix this in spec, I sent a fix upstream which is applied and waiting for the next Linus perf pull. https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1237 but you shouldn't be hitting that at all if you are doing a fedora build which doesn't build perf. If it isn't that, let me know what it actually is, since I am not seeing it in rawhide builds. > Finally, I've built the kernel successfully several times while testing > my fixes. I've noticed that ccache is not being used; it is rebuilding > everything every time. Since I'm building a kernel customized to my > hardware, that isn't so onerous. But, how would I enable ccache so > that rebuilds are basically copy operations? > For building rpms, I am not sure here. When I am debugging and testing non packaging related fixes, I tend to just build manually in the kernel tree. Justin _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
