unable to build zfs module on buster rockchip64


Recommended Posts

Hi Folks,

 

Trying to wrap my head around this still, so bear with my if I've crossed my wires somewhere, first some background.

 

With a 5.8 linux-image-current-rockchip64 kernel, zfs 0.8.4 and 2.0.0-rc won't compile because of the following error.

ERROR: modpost: "__stack_chk_guard" [/root/zfs/module/zfs/zfs.ko] undefined!

 

This has been mentioned in a few places:

 

https://github.com/openzfs/zfs/issues/10985

https://forum.armbian.com/topic/15065-downgrade-linux-image-current-rockchip64/

 

Digging into this I managed to build the module on focal with the same kernel and install that on buster. 

I'm of the belief that compiler should not be referencing "__stack_chk_guard" at all, since "CONFIG_STACKPROTECTOR_PER_TASK=y" is configured for this kernel and the symbol isn't listed in "/proc/kallsyms"

My suspicion (and this is where my knowledge limits me) is that something changed in GCC between the version buster ships with (8.3) and the version the kernel was built with (9.2) that causes it to not do the correct things for per task stack canaries.

 

If anyone has thoughts/ideas I'd love the input

 

-- Jonas

Link to post
Share on other sites
Armbian is a community driven open source project. Do you like to contribute your code?

The suggestion Igor made in that thread solves the 0.8.3 problems on 5.8 because certain kernel methods were flagged as GPL and the module won't compile.

As others in that thread pointed out, using the newer 0.8.4 package works on focal but not buster.

 

0.8.4 compiles correctly against the rockchip64 kernel on focal (gcc9) and bullseye (gcc10), but not with buster (gcc8).

2.0.0-rc follows the same pattern.

 

the rockchip64 kernel is built using the armbian toolchain, which is focal based and thus using gcc 9.

 

I haven't been able to come up with any other theory than how the compiler is detecting if it should use CONFIG_STACKPROTECTOR or CONFIG_STACKPROTECTOR_PER_TASK.

 

It's only a theory, and I don't know how to prove or disprove it, short of building the same 5.8.13 kernel with gcc 8 and trying to build the module against it (which is probably my next step)

Link to post
Share on other sites

I am running Armbian bionic and installed gcc-9 and gcc-10 from "ppa:ubuntu-toolchain-r/test". I tried both compilers with dkms and am still getting

ERROR: modpost: "__stack_chk_guard" [/root/zfs/module/zfs/zfs.ko] undefined!

 

I set the compiler version by exporting `CC`, but I don't see any mention of the compiler version in the DKMS build output. The make.log does show different compiler warnings, so I'm pretty sure I am successfully setting the compiler version.

Link to post
Share on other sites

@Brocklobsta sounds like you're setting GCC correctly, and the issue thats left is probably that the zfs-dkms module is too old (try finding 0.8.4+ per here)

 

For the issue on buster, I think I've nailed the problem down.

 

STACKPROTECTOR_PER_TASK is defined as such

config CC_HAVE_STACKPROTECTOR_SYSREG
   def_bool $(cc-option,-mstack-protector-guard=sysreg -mstack-protector-guard-reg=sp_el0 -mstack-protector-guard-offset=0)

config STACKPROTECTOR_PER_TASK
   def_bool y
   depends on STACKPROTECTOR && CC_HAVE_STACKPROTECTOR_SYSREG

 

GCC in the focal build environment supports the options required for CC_HAVE_STACKPROTECTOR_SYSREG

$ gcc --version
gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0

$ gcc -mstack-protector-guard=sysreg -mstack-protector-guard-reg=sp_el0 -mstack-protector-guard-offset=0
gcc: fatal error: no input files
compilation terminated.

 

Whereas the gcc version buster doesn't support these.

$ gcc --version
gcc (Debian 8.3.0-6) 8.3.0

$ gcc -mstack-protector-guard=sysreg -mstack-protector-guard-reg=sp_el0 -mstack-protector-guard-offset=0
gcc: error: unrecognized command line option '-mstack-protector-guard=sysreg'; did you mean '-fstack-protector-strong'?
gcc: error: unrecognized command line option '-mstack-protector-guard-reg=sp_el0'; did you mean '-fstack-protector-all'?
gcc: error: unrecognized command line option '-mstack-protector-guard-offset=0'; did you mean '-fstack-protector-strong'?
gcc: fatal error: no input files
compilation terminated.

 

Since the kernel is built for both focal + buster, should features like this be disabled or are there some other workarounds?

Link to post
Share on other sites

I am using Armbian Bionic. I have upgraded the GCC from ppa:ubuntu-toolchain-r/test repo to gcc-10, but I was having the same error message until today:

 

ERROR: modpost: "__stack_chk_guard" [/root/zfs/zfs-0.8.5/module/zfs/zfs.ko] undefined!
ERROR: modpost: "__stack_chk_guard" [/root/zfs/zfs-0.8.5/module/zcommon/zcommon.ko] undefined!
...

 

Today Armbian upgraded the kernel&header package (#20.08.8) and zfs compiles without any errors. I checked the changelog from https://docs.armbian.com/Release_Changelog/

but could not see any related changes. Most probably Armbian is now building the kernel with a newer GCC version, because I did not change anything since the build failed.

Link to post
Share on other sites
9 hours ago, turkerali said:

I am using Armbian Bionic. I have upgraded the GCC from ppa:ubuntu-toolchain-r/test repo to gcc-10, but I was having the same error message until today:

 

ERROR: modpost: "__stack_chk_guard" [/root/zfs/zfs-0.8.5/module/zfs/zfs.ko] undefined!
ERROR: modpost: "__stack_chk_guard" [/root/zfs/zfs-0.8.5/module/zcommon/zcommon.ko] undefined!
...

 

Today Armbian upgraded the kernel&header package (#20.08.8) and zfs compiles without any errors. I checked the changelog from https://docs.armbian.com/Release_Changelog/

but could not see any related changes. Most probably Armbian is now building the kernel with a newer GCC version, because I did not change anything since the build failed.

 

@turkerali

Which kernel package are you using? linux-image-current-rockchip64? I am not able to compile with the "current" kernel, but the "legacy" kernel has always worked.

Link to post
Share on other sites
14 hours ago, Brocklobsta said:

 

@turkerali

Which kernel package are you using? linux-image-current-rockchip64? I am not able to compile with the "current" kernel, but the "legacy" kernel has always worked.

 

Yes, I am using the linux-image-current-rockchip64 (5.8.x) on nanopc-t4.

 

There is one more possibility that might have resolved the issue for me. When you install the "linux-headers" package, apt runs "make scripts" command at the end of installation,

which builds some helper utilities inside the linux-headers package. I believe these helper utilities are responsible for module compilation and the "modpost" errors.

 

As a workaround, before you install the linux-headers package, make sure to upgrade the gcc version to gcc-9 or gcc-10 from ppa:ubuntu-toolchain-r/test repo.

Then install the linux-headers package. If you do this, the binary utilites in the scripts folder will be built with the upgraded gcc, and will be able to build & link the zfs modules.

 

I may be wrong, but it's worth trying.

 

Link to post
Share on other sites
On 10/10/2020 at 12:47 AM, turkerali said:

 

Yes, I am using the linux-image-current-rockchip64 (5.8.x) on nanopc-t4.

 

There is one more possibility that might have resolved the issue for me. When you install the "linux-headers" package, apt runs "make scripts" command at the end of installation,

which builds some helper utilities inside the linux-headers package. I believe these helper utilities are responsible for module compilation and the "modpost" errors.

 

As a workaround, before you install the linux-headers package, make sure to upgrade the gcc version to gcc-9 or gcc-10 from ppa:ubuntu-toolchain-r/test repo.

Then install the linux-headers package. If you do this, the binary utilites in the scripts folder will be built with the upgraded gcc, and will be able to build & link the zfs modules.

 

I may be wrong, but it's worth trying.

 

Thanks @turkerali! Recompiling the kernel headers with GCC-10 fixed the issue.

Link to post
Share on other sites
1 hour ago, antsu said:

@jberglerThanks again for the ZFS module you shared on the Helios64 support thread. It's been running for days without any problems.

If it's not too much trouble, would you mind sharing the process you used to build it?

 

Yes, that would be much appreciated.

And thanks again @jbergler for your work

Link to post
Share on other sites

These won't be exact instructions, since I decided to switch to focal (mostly for other reasons).

 

mkdir zfs-scratch
cd zfs-scratch

apt-get download linux-headers-current-rockchip64
git clone -b zfs-0.8.5 https://github.com/openzfs/zfs.git 

docker run --rm -it -v $(pwd):/scratch ubuntu:focal

# inside the container
cd /scratch
apt update
apt install build-essential autoconf automake libtool gawk alien fakeroot dkms libblkid-dev uuid-dev libudev-dev libssl-dev zlib1g-dev libaio-dev libattr1-dev libelf-dev python3 python3-dev python3-setuptools python3-cffi libffi-dev
dpkg -i linux-headers-current-*.deb

cd zfs
sh autogen.sh
./configure
make -s -j$(nproc) deb

 

At that point you can exit the container (it'l vanish because of the --rm) and inside zfs-scratch/zfs you should have a bunch of Debian packages you can install

 

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...