1. Please describe the problem: When building an external module it's currently difficult to build it with BTF because of this check in scripts/Makefile.modfinal: cmd_btf_ko = \ if [ ! -f vmlinux ]; then \ printf "Skipping BTF generation for %s due to unavailability of vmlinux\n" $@ 1>&2; \ else \ LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J $(PAHOLE_FLAGS) --btf_base vmlinux $@; \ $(RESOLVE_BTFIDS) -b vmlinux $@; \ fi; which means that even if one installs the kenel-debuginfo package with vmlinux the build script won't find it in the correct location, and one needs to manually move/link it there to build with BTF 2. What is the Version-Release number of the kernel: 6.7.4-200.fc39.x86_64 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : No. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Building any module works, I've reproduce it with https://github.com/ivbakula/hello-world-kernel-module for simpliciy: - git clone https://github.com/ivbakula/hello-world-kernel-module - cd hello-world-kernel-module - make -C /usr/src/kernels/$(uname -r) M=$PWD modules V=1 - notice it ends with `Skipping BTF generation for /tmp/hello-world-kernel-module/hello.ko due to unavailability of vmlinux` This is true even with kernel-debuginfo package installed normally. With kernel-debuginfo installed, one can (as root) run something like `ln /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /usr/src/kernels/$(uname -r)` which will place vmlinux in the source tree, at which point the module will be built with BTF. (this obviously assumes pahole (dwarves package) is also available) 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: Sorry, didn't check; the code is the same as upstream's master branch so I'd assume not, but the vmlinux file location is distro specific so I'm not sure if a fix would belong upstream or with distros at this point. 6. Are you running any modules that not shipped with directly Fedora's kernel?: doesn't matter at this point. 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. not relevant Reproducible: Always
hmm actually now I've tried rebuilding a rpm with these kernel modules, this also requires kludging _find_debuginfo_opts in the spec file (taken from https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/kernel.spec ): %{expand:%%global _find_debuginfo_opts %{?_find_debuginfo_opts} --keep-section '.BTF' -p '.*\/usr\/src\/kernels/.*|XXX' -o ignored-debuginfo.list -p '/.*/%%{KVERREL_RE}%{?1:[+]%{1}}/.*|/.*%%{KVERREL_RE}%{?1:\+%{1}}(\.debug)?' -o debuginfo%{?1}.list} It'd be great if that also could be made standard somehow; or at least made into something that could be easy to include for people making such spec files (I know external modules aren't supported in fedora, but there are plenty of vendors doing that for redhat kernels, and I'm not really comfortable pushing to add this macro when I don't understand all the options there -- happy to open a separate bz for this assigned to rhel instead if you think it's more appropriate) Thanks!
This message is a reminder that Fedora Linux 39 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '39'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 39 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
I've bumped the version to rawhide so it never autocloses; perhaps it would have made more sense to target redhat that does support external modules? In hindsight I'm not quite sure why I picked fedora here, but that can probably still be changed... Thanks!