Created attachment 1651126 [details] kernel dmesg log 1. Please describe the problem: When a kernel module is built out of tree, the makefile tries to build the "syncconfig" target, and then fails when it cannot find flex or bison. drwilliams@rei:~$ sudo make -j8 KERNELRELEASE=5.4.7-200.fc31.x86_64 -C /lib/modules/5.4.7-200.fc31.x86_64/build SUBDIRS=/var/lib/dkms/dattobd/0.10.11/build KVER=5.4.7-200.fc31.x86_64 modules make: Entering directory '/usr/src/kernels/5.4.7-200.fc31.x86_64' LEX scripts/kconfig/lexer.lex.c /bin/sh: flex: command not found YACC scripts/kconfig/parser.tab.[ch] /bin/sh: bison: command not found make[2]: *** [scripts/Makefile.host:9: scripts/kconfig/lexer.lex.c] Error 127 make[2]: *** Waiting for unfinished jobs.... make[2]: *** [scripts/Makefile.host:17: scripts/kconfig/parser.tab.h] Error 127 make[1]: *** [Makefile:567: syncconfig] Error 2 make: *** [Makefile:678: include/config/auto.conf.cmd] Error 2 make: Leaving directory '/usr/src/kernels/5.4.7-200.fc31.x86_64' When those dependencies are installed, the build later fails as shown below. DKMS make.log for dattobd-0.10.11 for kernel 5.4.7-200.fc31.x86_64 (x86_64) Thu 09 Jan 2020 06:20:02 PM EST make: Entering directory '/usr/src/kernels/5.4.7-200.fc31.x86_64' LEX scripts/kconfig/lexer.lex.c YACC scripts/kconfig/parser.tab.[ch] HOSTCC scripts/kconfig/preprocess.o HOSTCC scripts/kconfig/symbol.o HOSTCC scripts/kconfig/lexer.lex.o HOSTCC scripts/kconfig/parser.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --syncconfig Kconfig Kconfig:34: can't open file "Documentation/Kconfig" make[2]: *** [scripts/kconfig/Makefile:73: syncconfig] Error 1 make[1]: *** [Makefile:567: syncconfig] Error 2 make: *** [Makefile:678: include/config/auto.conf.cmd] Error 2 make: Leaving directory '/usr/src/kernels/5.4.7-200.fc31.x86_64' 2. What is the Version-Release number of the kernel: 5.4.7-200.fc31 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 : It worked previously on 5.3.16-300.fc31, now fails on 5.4.7-200.fc31. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: - git clone https://github.com/datto/dattobd - cd src; mkdir build - ./genconfig.sh $(uname -r) -j1 - make KERNELRELEASE=$(uname -r) -C /lib/modules/$(uname -r)/build SUBDIRS=$PWD/build KVER=$(uname -r) modules Also can be reproduced by installing the dkms package: https://github.com/datto/dattobd/blob/master/INSTALL.md#fedora 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``: yes 6. Are you running any modules that not shipped with directly Fedora's kernel?: no 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. Attached
*** Bug 1789639 has been marked as a duplicate of this bug. ***
After installing potential fix 5.4.11-202.fc31 (https://src.fedoraproject.org/rpms/kernel/c/9a4238fbd6670f7a8b437e530336bdf21b270cdf?branch=f31) and installing flex and bison, the following behavior occurs when running the reproduction steps. make: Entering directory '/usr/src/kernels/5.4.11-202.fc31.x86_64' HOSTCC scripts/selinux/genheaders/genheaders scripts/selinux/genheaders/genheaders.c:18:10: fatal error: classmap.h: No such file or directory 18 | #include "classmap.h" | ^~~~~~~~~~~~ compilation terminated. make[3]: *** [scripts/Makefile.host:107: scripts/selinux/genheaders/genheaders] Error 1 make[2]: *** [scripts/Makefile.build:509: scripts/selinux/genheaders] Error 2 make[1]: *** [scripts/Makefile.build:509: scripts/selinux] Error 2 make: *** [Makefile:1097: scripts] Error 2 make: Leaving directory '/usr/src/kernels/5.4.11-202.fc31.x86_64'
Sorry for the distraction, I wasn't aware of the SUBDIRS removal, and there were two lines using it in our codebase. Only by building on 5.3.18-300.fc31 and seeing the warning there (which didn't show up on other builds), did I realize this. Closing not a bug. Again, sorry to waste people's time on this.