Jump to content

Build ZFS on RK3328


fossxplorer

Recommended Posts

Has anyone been able to build ZFS/SPL?:

checking linux distribution... ubuntu
checking default package type... deb
checking whether rpm is available... yes (4.12.0.1)
checking whether rpmbuild is available... yes (4.12.0.1)
checking whether spec files are available... yes (rpm/generic/*.spec.in)
checking whether dpkg is available... yes (1.18.4)
checking whether dpkg-buildpackage is available... yes (1.18.4.)
checking whether alien is available... yes (8.95)
checking spl config... all
checking kernel source directory... /usr/src/linux-headers-4.4.115-rk3328
checking kernel build directory... /usr/src/linux-headers-4.4.115-rk3328
checking kernel source version... 4.4.115-rk3328
checking kernel file name for module symbols... Module.symvers
checking whether debugging is enabled... no
checking whether basic kmem accounting is enabled... no
checking whether detailed kmem tracking is enabled... no
checking whether modules can be built... no
configure: error: *** Unable to build an empty module.
root@rock64:~/tmp/spl-spl-0.7.6#

root@rock64:~/tmp/spl-spl-0.7.6# uname -a
Linux rock64 4.4.115-rk3328 #3 SMP Sun Mar 18 11:31:44 CET 2018 aarch64 aarch64 aarch64 GNU/Linux

 

 

I've tried numerous times, without any luck on my Android box running armbian Rock64 image. Although the kernel devel/headers are there, it fails!

 

 

 

 

Link to comment
Share on other sites

Thanks for that info!

root@rock64:~/tmp/spl-spl-0.7.6# find /usr/src/linux-headers-4.4.115-rk3328/ -iname 'gcc-wrapper*'
/usr/src/linux-headers-4.4.115-rk3328/scripts/gcc-wrapper.py
root@rock64:~/tmp/spl-spl-0.7.6# mv /usr/src/linux-headers-4.4.115-rk3328/scripts/gcc-wrapper.py /tmp/
root@rock64:~/tmp/spl-spl-0.7.6# ./autogen.sh

..

# went fine

root@rock64:~/tmp/spl-spl-0.7.6# ./configure

..

checking whether dpkg-buildpackage is available... yes (1.18.4.)
checking whether alien is available... yes (8.95)
checking spl config... all
checking kernel source directory... /usr/src/linux-headers-4.4.115-rk3328
checking kernel build directory... /usr/src/linux-headers-4.4.115-rk3328
checking kernel source version... 4.4.115
checking kernel file name for module symbols... Module.symvers
checking whether debugging is enabled... no
checking whether basic kmem accounting is enabled... no
checking whether detailed kmem tracking is enabled... no
checking whether modules can be built... no
configure: error: *** Unable to build an empty module.

 

Any more hints would be welcome :)

 

Link to comment
Share on other sites

After fighting with this with a few distros..  I am close here:

 

1. First, go to your linux-headers directory (e.g. /usr/src/linux-headers-4.4.129-rk3328/) and:

 

make scripts

 

If that fails (classmap.h missing for example), there is a problem with the headers package.  You may need to manually edit scripts/Makefile and comment out the line with selinux -- there is a problem with the kernel config not matching the header deb in my case.

 

# subdir-$(CONFIGS_SECURITY_SELINUX) += selinux

 

2. From the same headers directory, verify that include/generated/utsrelease.h matches the full kernal name from: uname -a

 

- My headers (from beta repo) had 4.4.129 as utsrelease.h and 4.4.129-rk3328 as the kernel version/release.  This causes modules to be built incorrectly and their vermagic to not match--you can use modprobe --force to get around this, but ill-advised to use that for more than a quick test with something like zfs.  My utsrelease.h now reads: 4.4.129-rk3328

 

3. Edit /var/lib/dkms/spl/<yourversion>/source/configure and search for KUID, for lines that look like this:

 

kuid_t userid = KUIDGT_INIT(0);

kgid_t groupid = KGIDT_INIT(0);

 

Erase those two lines, the test itself is broken on our environments.  Leave the lines surrounding it.  These appear twice in the configure script--remove both sets.   

 

Now look for these lines:

 

kuid_t userid = 0;

kgid_t groupid = 0;

 

Change them to:

 

kuid_t userid;

kgid_t groupid;

 

(I filed a bug here https://github.com/zfsonlinux/spl/issues/653#issuecomment-333973785 )

 

Now you can run:

 

dkms build spl/<yourversion>

dkms install --force spl/<yourversion>

modprobe spl

# should be no errors here, check dmesg otherwise

 

dkms build zfs/<yourversion>

dkms install --force zfs/<yourversion>

 

When configure runs, you should now see:

checking whether kuid_t/kgid_t is available... yes; mandatory

 

Some notes:

 

- I ended up switching to beta (sources.d) and doing an update/upgrade/dist-upgrade first because there were no kernel headers for the WIP rock64 image I installed.

 

- If you use kernel 4.11.x you will need to use SPL/ZFS 0.7.x.  I am using the standard zfs-dkms/spl-dkms 0.6.5.9 packages for now..  install SPL and let it fail, then dkms install it after the steps above and then install the ZFS package.

 

Just started with Armbian today .. in retrospect it looks like it has drawn me in.. ;)

 

Link to comment
Share on other sites

On 5/2/2018 at 2:32 AM, Jason Fisher said:

After fighting with this with a few distros..  I am close here:

 

1. First, go to your linux-headers directory (e.g. /usr/src/linux-headers-4.4.129-rk3328/) 

 

sorry Jason, but if I can not find my kernel-headers (/usr/src/ is empty directory) , what is the right way to download a specific kernel header not the generic one ?

Link to comment
Share on other sites

On 5/3/2018 at 1:48 PM, Mustafa85 said:

sorry Jason, but if I can not find my kernel-headers (/usr/src/ is empty directory) , what is the right way to download a specific kernel header not the generic one ?

If you use armbian-config, one of the options is 'install kernel headers' -- however this did not match the kernel I had installed in my case (rock64 stretch image) so I ended up adding the beta repo to sources.list and then updating to the latest 4.4.x kernel that also had 4.4.x headers availble.  (the newer dev kernel did not work for me)

Link to comment
Share on other sites

Just wanted to confirm that everything is working well with ZFS here on ARM64.  Successfully running two MediaRAID 8x eSATA/USB3 enclosures off of a USB3 hub, 16 drives/20TB .. 10+ year old raidz2 pools that has moved between a dozen machines .. VM under Windows, Mac, Linux .. adozen controllers (PMP SATA, eSATA, USB3) survived 7 total drives dying, no data loss.  4GB RAM is plenty for media streaming -- 2.6GB RAM was fine with some tuning (VM in Windows that ran Plex and shared ZFS back to host).

 

Benchmarks eventually .. but downloading with sabnzbd/sonarr, using Chromium, and streaming 1080p to Plex at just under 3GB RAM in use.

Link to comment
Share on other sites

My friend is trying to set up ZFS on his Rock64 and we've tried everything under the sun to get this thing working but we've hit a wall every single time :( We're running Armbian Xenial version 4.4.124 and downloaded the kernel header (4.4.0-124) because using armbian-config gave a kernel mismatch error, and it still reports that it can't find the kernel header. We couldn't find a 4.4.124 header, for some reason there are only 4.4.0-x available.


The process fails with installing ZFS with the lines:


Loading new spl-0.6.5.6 DKMS files...
Building only for 4.4.124 rk3228
Module build for the currently running kernel was skipped since the kernel source for this kernel does not seem to be installed.

The armbian-config doesn't seem to download the correct headers into /usr/src/linux-headers-4.4.x , we only have 4.4.77...

The only option for the headers is to uninstall them. Any help would be greatly appreciated! We've not been able to get ZFS working because of kernel module issues on DietPi, OpenMediaVault, and now Armbian.

Link to comment
Share on other sites

35 minutes ago, Kattaleya said:

The armbian-config doesn't seem to download the correct headers into /usr/src/linux-headers-4.4.x , we only have 4.4.77...

 

apt.armbian.com is not up to date:

root@rock64:~# apt-cache search headers | grep rk3328
linux-headers-dev-rk3328 - Linux kernel headers for 4.14.0-rc2-rk3328 on arm64
linux-headers-rk3328 - Linux kernel headers for 4.4.77-rk3328 on arm64

By switching to 'nightly' with armbian-config (and accepting that you're fine with a bricked system) which replaces apt.armbian.com with beta.armbian.com things change:

root@rock64:~# uname -a
Linux rock64 4.4.138-rk3328 #10 SMP Mon Jul 9 13:05:42 PDT 2018 aarch64 GNU/Linux

root@rock64:~# apt-cache search headers | grep rk3328
linux-headers-dev-rk3328 - Linux kernel headers for 4.17.0-rc6-rk3328 on arm64
linux-headers-rk3328 - Linux kernel headers for 4.4.138-rk3328 on arm64

Of course this is not a solution.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines