I am unable to build sys-fs/zfs-kmod >=0.8.3 against gentoo-sources-5.4.38 with config which worked on gentoo-sources-5.4.28. And not even against genkernel default config on 5.4.38. The build of package fails during config phase with """ checking whether modules can be built... no configure: error: *** Unable to build an empty module. make: Entering directory '/usr/src/linux-5.4.38-gentoo' """ Reproducible: Always Steps to Reproduce: 1.install gentoo-sources-5.4.38 2.build default genkernel config 3.emerge sys-fz/zfs-kmod Actual Results: build fails during config phase Expected Results: built kmod
Created attachment 640738 [details] emerge --info
Did you build kernel first? It requires configured and built kernel in /usr/src/linux Also upload build log and config.log
The most likely cause if this failure is not running a full kernel build (as Georgy said) or running modules_prepare after configuring your kernel. We need to patch upstream to provide a more helpful error message when this happens. Try Building your kernel and reporting back. Also, build.log and config.log files from sys-fs/zfs-mood would be helpful in diagnosing this issue if the problem persists.
what's strange about this situation is that ebuild calls > linux-mod_pkg_setup which on other hand calls (from linux-info.eclass) > check_kernel_built which should die if kernel is not build ( checks if "include/generated/uapi/linux/version.h" exists ) I wonder if the check misfiring? our eclass message is much more verbose and it's clear what's needed to be done. I't the second occasion when users hit this problem with zfs-kmod.
also ricer CFLAGS. those also can lead to check failing. > CFLAGS="--param l1-cache-line-size=64 --param l1-cache-size=32 --param l2-cache-size=512 -O2 -fomit-frame-pointer -mabm -madx -maes -march=znver1 -mavx -mavx2 -mbmi -mbmi2 -mclflushopt -mclzero -mcx16 -mf16c -mfma -mfsgsbase -mfxsr -mlzcnt -mmmx -mmovbe -mmwaitx -mno-3dnow -mno-avx5124fmaps -mno-avx5124vnniw -mno-avx512bitalg -mno-avx512bw -mno-avx512cd -mno-avx512dq -mno-avx512er -mno-avx512f -mno-avx512ifma -mno-avx512pf -mno-avx512vbmi -mno-avx512vbmi2 -mno-avx512vl -mno-avx512vnni -mno-cldemote -mno-clwb -mno-fma4 -mno-gfni -mno-hle -mno-lwp -mno-movdir64b -mno-movdiri -mno-pconfig -mno-pku -mno-prefetchwt1 -mno-ptwrite -mno-rdpid -mno-rtm -mno-sgx -mno-shstk -mno-tbm -mno-vaes -mno-vpclmulqdq -mno-waitpkg -mno-wbnoinvd -mno-xop -mpclmul -mpopcnt -mprfchw -mrdrnd -mrdseed -msahf -msha -msse -msse2 -msse3 -msse4.1 -msse4.2 -msse4a -mssse3 -mtune=znver1 -mxsave -mxsavec -mxsaveopt -mxsaves -pipe"
Hi, I definitely have built my kernel (I usually use CMD_CALLBACK="/usr/bin/emerge @module-rebuild && /usr/sbin/grub-mkconfig -o /boot/grub/grub.cfg" in /etc/genkernel.conf). Also: # ls -l /usr/src/linux/include/generated/uapi/linux/version.h -rw-r--r-- 1 root root 97 May 15 17:54 /usr/src/linux/include/generated/uapi/linux/version.h # ls -l /usr/src/linux -d lrwxrwxrwx 1 root root 19 May 15 17:51 /usr/src/linux -> linux-5.4.38-gentoo My CFLAGS are equivalent of the "-march=native" CFLAGS. What shoud I drop? And also it was working with these before... Logs are in attchement.
Created attachment 641664 [details] zfs-kmod-0.8.3/work/zfs-0.8.3/config.log
zfs-kmod-0.8.3/work/zfs-0.8.3/build/conftest/build.log is empty...
(In reply to Georgy Yakovlev from comment #4) > what's strange about this situation is that ebuild calls > > > linux-mod_pkg_setup > > which on other hand calls (from linux-info.eclass) > > > check_kernel_built > > which should die if kernel is not build ( checks if > "include/generated/uapi/linux/version.h" exists ) > > I wonder if the check misfiring? our eclass message is much more verbose and > it's clear what's needed to be done. > > I't the second occasion when users hit this problem with zfs-kmod. That check has not been sufficient for years. There are conditions where the kernel being partially built, but not built enough for out of tree kernel modules. :/ (In reply to samurai.no.dojo from comment #8) > zfs-kmod-0.8.3/work/zfs-0.8.3/build/conftest/build.log > is empty... The build.log I meant would be in zfs-kmod-0.8.3/work/zfs-0.8.3/temp/build.log I suggest running `make -j$(nproc) -C /usr/src/linux modules_prepare` and then trying a build.
configure:17423: checking whether modules can be built configure:17483: KBUILD_MODPOST_NOFINAL= KBUILD_MODPOST_WARN= make modules -k -j32 -C /usr/src/linux M=/tmp/portage/sys-fs/zfs-kmod-0.8.3/work/zfs-0.8.3/build/conftest &>build/conftest/build.log configure:17486: $? = 0 configure:17489: test -f build/conftest/conftest.ko configure:17492: $? = 1 configure:17500: result: no configure:17503: error: *** Unable to build an empty module. this step fails you can try copying /tmp/portage/sys-fs/zfs-kmod-0.8.3/work/zfs-0.8.3/build/conftest to /tmp and run this outside of portage (chown directory to user you run as ) > KBUILD_MODPOST_NOFINAL= KBUILD_MODPOST_WARN= make modules -k -j32 -C /usr/src/linux M=/tmp/conftest this will give us some insight why it fails, I hope. as for cflags, if you look into emerge --info zfs-kmod output, you'll see that not all your flags get applied, because zfs-kmod uses strip-cflags > CFLAGS="-O2 -march=znver1 -mno-3dnow -mno-avx512cd -mno-avx512er -mno-avx512f -mno-avx512pf -mno-fma4 -mno-hle -mno-lwp -mno-rtm -mno-tbm -mno-xop -mtune=znver1 -pipe" specifying all of the -mno flags is not required btw, unless you have very strange configuration (trying to use more modern march/mtune with older CPU)
just for reference, here's how it looks for me > ya@hydra /tmp/conftest $ KBUILD_MODPOST_NOFINAL= KBUILD_MODPOST_WARN= make modules -k -j32 -C /usr/src/linux M=/tmp/conftest make: Entering directory '/usr/src/linux-5.4.42-gentoo' CC [M] /tmp/conftest/conftest.o Building modules, stage 2. MODPOST 1 modules WARNING: modpost: missing MODULE_LICENSE() in /tmp/conftest/conftest.o see include/linux/module.h for more information CC [M] /tmp/conftest/conftest.mod.o LD [M] /tmp/conftest/conftest.ko make: Leaving directory '/usr/src/linux-5.4.42-gentoo'
file conftest.ko conftest.ko: ELF 64-bit LSB relocatable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), BuildID[sha1]=3e05980a34b3339dce15c9f3f27be1da354400e9, not stripped
just for test, try building with simple CFLAGS "-O2 -march=znver1 -mtune=znver1 -pipe" you can leave cache params as well, those are safe.
> The build.log I meant would be in zfs-kmod-0.8.3/work/zfs-0.8.3/temp/build.logThere is no temp dir in zfs-kmod-0.8.3/work/zfs-0.8.3/ perhaps you mean /tmp/portage/sys-fs/zfs-kmod-0.8.3/temp/build.log.gz (attached) (I have not found it before since I was trying to "find" files ending with .log) # make -j$(nproc) -C /usr/src/linux modules_prepare make: Entering directory '/usr/src/linux-5.4.38-gentoo' scripts/kconfig/conf --syncconfig Kconfig DESCEND objtool CALL scripts/atomic/check-atomics.sh CALL scripts/checksyscalls.sh make: Leaving directory '/usr/src/linux-5.4.38-gentoo' # KBUILD_MODPOST_NOFINAL= KBUILD_MODPOST_WARN= make modules -k -j32 -C /usr/src/linux M=/tmp/conftest make: Entering directory '/usr/src/linux-5.4.38-gentoo' CC [M] /tmp/conftest/conftest.o Building modules, stage 2. MODPOST 1 modules WARNING: modpost: missing MODULE_LICENSE() in /tmp/conftest/conftest.o see include/linux/module.h for more information CC [M] /tmp/conftest/conftest.mod.o LD [M] /tmp/conftest/conftest.ko make: Leaving directory '/usr/src/linux-5.4.38-gentoo' # file /tmp/conftest/conftest.ko /tmp/conftest/conftest.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), BuildID[sha1]=1ed9aa0091781acf9a163259126cea7e3eaa9761, not stripped Still the same even with: CFLAGS="-O2 -march=znver1 -mtune=znver1 -pipe" I also attached output of # genkernel all which states that it built the kernel OK I was also capable of building sys-fs/vhba against the same kernel tree, after all steps stated above.
Created attachment 641918 [details] genkernel all output
Created attachment 641920 [details] /tmp/portage/sys-fs/zfs-kmod-0.8.3/temp/build.log.gz
so you can build empty module outside of portage as testcase shows, but can't do that outside of it. is zfs-kmod-0.8.3/work/zfs-0.8.3/build/conftest/build.log really empty all the time it fails? configure:17486: $? = 0 looks like build succeed but file build/conftest/conftest.ko is either absent or not readable? very strange. Can you tar+*zip and attach the whole /var/tmp/portage/sys-fs/zfs-kmod-* for investigation? And a kernel .config to replicate with. anything special about your /usr/src layout? some users move that dir and/or symlink it and it caused problems in the past. do you do anything special with /var/tmp/portage? which filesystem is that on?
requested files are in attachments /usr/src/ is separate partition # grep src /etc/fstab UUID="..." /usr/src ext4 defaults,noatime 0 6 I am not using /var/tmp/portage. I build in /tmp/portage which is tmpfs # grep tmp /etc/fstab tmpfs /tmp tmpfs defaults,nodev,nosuid,mode=1777 0 0
Created attachment 642086 [details] kernel .config
build dir is accesible on this link (valid for 30 days) https://www.farm.particle.cz/tmp/zfs-kmod-0.8.3-build_dir.tar.gz Or should I put it elsewhere?
I got the file. Haven't found anything too obvious yet. I'll set up a testing environment later. It all looks very strange, I'll add debug code and will try to find it.
Hi, I have found the cause (I do not have an exact line, but I have it). Problem is in something non-POSIXy in build scripts. I use dash as /bin/sh. But it build OK when I switched to bash as /bin/sh due to other bug related to non-POSIXness. Cheers S PS: for the record: app-shells/dash-0.5.10.2-r1 and app-shells/bash-4.4_p23-r1
that's a bit strange, because zfs is well tested on debian and ubuntu, both use dash as /bin/sh afaik and build-tested every commit/pr.
(In reply to samurai.no.dojo from comment #22) > Hi, > I have found the cause (I do not have an exact line, but I have it). > Problem is in something non-POSIXy in build scripts. > I use dash as /bin/sh. > But it build OK when I switched to bash as /bin/sh due to other bug related > to non-POSIXness. > Cheers > S > > PS: for the record: > app-shells/dash-0.5.10.2-r1 > and > app-shells/bash-4.4_p23-r1 Coincidentally, I used to test with dash, but I switched to bash after hitting an issue involving dev-util/perf where upstream would not take a patch to fix it. Anyway, I have reproduced this locally. The checkbashisms script is finding quite a few bashisms, mostly in code for generating RPMs. It also is broken by this: https://github.com/openzfs/zfs/commit/85ce3f4fd114cf3c7a77feb07b397d43b90d11c7 Deleting the lines that break checkbashisms and running it again found a large number of bashisms, although none near the kernel module check. Running `checkbashisms -xp /path/to/configure` finds more issues, including close to the kernel module check. However, these are not the cause either. This would appear to be the offending commit: https://github.com/openzfs/zfs/commit/ff3e2e3c7096200c4d4771f724762b15e1484259 In particular, these lines: ff3e2e3c70 (Brian Behlendorf 2019-10-01 12:50:34 -0700 602) AC_DEFUN([ZFS_LINUX_COMPILE], [ ff3e2e3c70 (Brian Behlendorf 2019-10-01 12:50:34 -0700 603) AC_TRY_COMMAND([ ff3e2e3c70 (Brian Behlendorf 2019-10-01 12:50:34 -0700 604) KBUILD_MODPOST_NOFINAL="$5" KBUILD_MODPOST_WARN="$6" ff3e2e3c70 (Brian Behlendorf 2019-10-01 12:50:34 -0700 605) make modules -k -j$TEST_JOBS -C $LINUX_OBJ $ARCH_UM ff3e2e3c70 (Brian Behlendorf 2019-10-01 12:50:34 -0700 606) M=$PWD/$1 &>$1/build.log]) ff3e2e3c70 (Brian Behlendorf 2019-10-01 12:50:34 -0700 607) AS_IF([AC_TRY_COMMAND([$2])], [$3], [$4]) c9c0d073da (Brian Behlendorf 2010-08-26 11:22:58 -0700 608) ]) It isn't obvious at a glance, but you can try running `echo Hello World &>/tmp/log` in bash and in dash to see what happens. In dash, we have to hit enter twice. In bash, it just works. The correct way to write something like this is `echo Hello World 2>&1 >/tmp/log`. Fixing this in the configure script allows it to configure until the next usage of "&>". Interestingly, patching that file does not trigger the automatic reconfiguration of autotools that I was told we were supposed to support. Also, just running this check has revealed many things of concern. :/ Anyway, a fix is in progress. I am marking this as IN_PROGRESS.
By the way, for the curious, checkbashisms did not detect the &> issue because the shell code is in a string that gets processed by eval.
I have filed an upstream issue regarding this regression since the root cause is now known to be something that upstream did: https://github.com/openzfs/zfs/issues/10510
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a0addbfd6902fe7454a16722c17e3d63ed8dd914 commit a0addbfd6902fe7454a16722c17e3d63ed8dd914 Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2020-09-21 22:43:33 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2020-09-21 22:51:06 +0000 sys-fs/zfs: use bash as config shell explicitly dash as /bin/sh users get build failures for 0.8.x but it seems to be ok in 2.0.x Bug: https://bugs.gentoo.org/724452 Package-Manager: Portage-3.0.8, Repoman-3.0.1 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> sys-fs/zfs/zfs-0.8.4-r2.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=72ca90fa2e9e5028983cce06f3726fcd622af825 commit 72ca90fa2e9e5028983cce06f3726fcd622af825 Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2020-09-21 22:40:52 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2020-09-21 22:50:21 +0000 sys-fs/zfs-kmod: use bash as config shell explicitly dash as /bin/sh users get build failures for 0.8.x but it seems to be ok in 2.0.x Bug: https://bugs.gentoo.org/724452 Package-Manager: Portage-3.0.8, Repoman-3.0.1 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> sys-fs/zfs-kmod/zfs-kmod-0.8.4-r1.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
ok we have a workaround in place. and 2.0.* is fine as is with dash. Closing. thanks for reporting and figuring it out, it was a weird one.
