Fedora 17: cannot compile anymore

[Rudd-O]

After the latest batch of updates:

make
make  all-recursive
make[1]: Entering directory `/home/rudd-o/Projects/Mine/spl'
Making all in lib
make[2]: Entering directory `/home/rudd-o/Projects/Mine/spl/lib'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/rudd-o/Projects/Mine/spl/lib'
Making all in cmd
make[2]: Entering directory `/home/rudd-o/Projects/Mine/spl/cmd'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/rudd-o/Projects/Mine/spl/cmd'
Making all in scripts
make[2]: Entering directory `/home/rudd-o/Projects/Mine/spl/scripts'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/rudd-o/Projects/Mine/spl/scripts'
Making all in module
make[2]: Entering directory `/home/rudd-o/Projects/Mine/spl/module'
make -C /usr/src/kernels/3.4.4-5.fc17.x86_64 SUBDIRS=`pwd`  modules
make[3]: Entering directory `/usr/src/kernels/3.4.4-5.fc17.x86_64'
  Building modules, stage 2.
/usr/src/kernels/3.4.4-5.fc17.x86_64/scripts/Makefile.modpost:113: target `/home/rudd-o/Projects/Mine/spl/module/.tmp_versions/spl.mod' doesn't match the target pattern
/usr/src/kernels/3.4.4-5.fc17.x86_64/scripts/Makefile.modpost:114: warning: overriding recipe for target `/home/rudd-o/Projects/Mine/spl/module/.tmp_versions/spl.mod'
/usr/src/kernels/3.4.4-5.fc17.x86_64/scripts/Makefile.modpost:101: warning: ignoring old recipe for target `/home/rudd-o/Projects/Mine/spl/module/.tmp_versions/spl.mod'
/usr/src/kernels/3.4.4-5.fc17.x86_64/scripts/Makefile.modpost:113: target `/home/rudd-o/Projects/Mine/spl/module/.tmp_versions/splat.mod' doesn't match the target pattern
/usr/src/kernels/3.4.4-5.fc17.x86_64/scripts/Makefile.modpost:114: warning: overriding recipe for target `/home/rudd-o/Projects/Mine/spl/module/.tmp_versions/splat.mod'
/usr/src/kernels/3.4.4-5.fc17.x86_64/scripts/Makefile.modpost:101: warning: ignoring old recipe for target `/home/rudd-o/Projects/Mine/spl/module/.tmp_versions/splat.mod'
/usr/src/kernels/3.4.4-5.fc17.x86_64/scripts/Makefile.modpost:124: target `/home/rudd-o/Projects/Mine/spl/module/.tmp_versions/spl.mod' doesn't match the target pattern
/usr/src/kernels/3.4.4-5.fc17.x86_64/scripts/Makefile.modpost:125: warning: overriding recipe for target `/home/rudd-o/Projects/Mine/spl/module/.tmp_versions/spl.mod'
/usr/src/kernels/3.4.4-5.fc17.x86_64/scripts/Makefile.modpost:114: warning: ignoring old recipe for target `/home/rudd-o/Projects/Mine/spl/module/.tmp_versions/spl.mod'
/usr/src/kernels/3.4.4-5.fc17.x86_64/scripts/Makefile.modpost:124: target `/home/rudd-o/Projects/Mine/spl/module/.tmp_versions/splat.mod' doesn't match the target pattern
/usr/src/kernels/3.4.4-5.fc17.x86_64/scripts/Makefile.modpost:125: warning: overriding recipe for target `/home/rudd-o/Projects/Mine/spl/module/.tmp_versions/splat.mod'
/usr/src/kernels/3.4.4-5.fc17.x86_64/scripts/Makefile.modpost:114: warning: ignoring old recipe for target `/home/rudd-o/Projects/Mine/spl/module/.tmp_versions/splat.mod'
make[4]: Circular /home/rudd-o/Projects/Mine/spl/module/.tmp_versions/spl.mod <- __modpost dependency dropped.
make[4]: Circular /home/rudd-o/Projects/Mine/spl/module/.tmp_versions/splat.mod <- __modpost dependency dropped.
  MODPOST 2 modules
make[3]: Leaving directory `/usr/src/kernels/3.4.4-5.fc17.x86_64'
make[2]: Leaving directory `/home/rudd-o/Projects/Mine/spl/module'
Making all in include
make[2]: Entering directory `/home/rudd-o/Projects/Mine/spl/include'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/rudd-o/Projects/Mine/spl/include'
make[2]: Entering directory `/home/rudd-o/Projects/Mine/spl'
make[2]: Nothing to be done for `all-am'.
make[2]: Leaving directory `/home/rudd-o/Projects/Mine/spl'
make[1]: Leaving directory `/home/rudd-o/Projects/Mine/spl'

[Rudd-O]

There is something wrong with something in the build chain. When I move the spl directory to /dev/shm/spl, it WORKS. When, on the contrary, I have it on my /home/rudd-o/Projects/Mine/spl, it DOES NOT.

I will track down more info about this ASAP.

[Rudd-O]

When working from /usr/src

(note: ssd/ROOT/fedora-17/usr on /usr type zfs (rw,relatime,xattr))

It DOES NOT WORK.

It appears that kernel module compiles will simply not work if the sources are stored in ZFS file systems.

That's a pretty big bug.

[Rudd-O]

I tested by moving /usr/src/spl to /spl

It won't work. As long as the file system containing the ZFS / SPL sources is located inside a ZFS dataset, the compile fails.

I will now try ext4.

[Rudd-O]

Confirmed working with ext4.

So far we know that:

• if the spl sources are in a ZFS dataset, it does not work
• if the spl sources are in a tmpfs, it works
• if the spl sources are in an ext4 file system, it works

How cool is it that we are building a file system that cannot build itself when it is being used? :-S

[Rudd-O]

I have also verified that, if I go to /dev/shm and I make a symlink to the source directory, then cd into the directory and attempt to compile ZFS, it won't work either. It also dies with the modpost errors above.

kernel version

~/Projects/Mine@karen.dragonfear α:
uname -r
3.4.4-5.fc17.x86_64

[Rudd-O]

Finally, I have verified that, if I put the sources of spl on an ext4 file system backed by a ZVol, it works and the compile succeeds.

This points to a problem, not with the block layer or the SPA, but rather the POSIX layer of ZFS and the way it interacts with my particular kernel version.

[behlendorf]

Yes, I suspect this is related to openzfs/zfs#764. This really need to go on my short list of things to get fixed. But the gist of it is that we're not strictly updating the inode in all cases. Certain utilities have stumbled due to this problem. Your right, it's a big deal.

[Rudd-O]

Yes. Well, that situation got worse in the past few days. I used to be able to compile zfs in zfs. Now I cannot :)

[behlendorf]

That's a little surprising, maybe the updated tool chain is just more likely to notice the issue. It's just that the updates aren't quite as prompt as they should be. Anyway, we'll get it fixed.

[behlendorf]

@Rudd-O Could this perhaps actually have been caused by the broken version of grep, openzfs/zfs#829 ?

[fuhry]

This just bit me too. Arch Linux 3.4.2 with custom kernel built with CONFIG_PREEMPT_NONE, zfs/spl 0.6.0-rc9. My new 3.4.7 kernel package and spl both failed to build their modules. Unsure if zfs succeeded, or if those were just the old modules sitting in /usr/lib/modules/extramodules-3.4-no-preempt.

[behlendorf]

@fuhry Can you check what version of grep you have installed?

[ghost]

nh:root:~ # yaourt -Q grep
core/grep 2.13-2 (base)
nh:root:~ # grep --version
grep (GNU grep) 2.13
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Mike Haertel and others, see http://git.sv.gnu.org/cgit/grep.git/tree/AUTHORS.

[behlendorf]

That may be it then. GNU grep 2.13 is buggy see openzfs/zfs#829 , could try downgrading it verify that resolves the problem.

[behlendorf]

Closing this issue. The build failures are believed to have been due to a bug introduced by grep.