fossxplorer Posted March 20, 2018 Posted March 20, 2018 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!
tkaiser Posted March 20, 2018 Posted March 20, 2018 https://forum.odroid.com/viewtopic.php?f=154&t=30280&view=unread#p218515
fossxplorer Posted March 20, 2018 Author Posted March 20, 2018 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
Jason Fisher Posted May 2, 2018 Posted May 2, 2018 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.. 3
Mustafa85 Posted May 3, 2018 Posted May 3, 2018 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 ?
Jason Fisher Posted May 8, 2018 Posted May 8, 2018 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)
Jason Fisher Posted May 27, 2018 Posted May 27, 2018 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. 1
fossxplorer Posted July 13, 2018 Author Posted July 13, 2018 Thanks a lot @Jason Fisher Based on your feedback and invaluable hints and tips, i was finally able to get ZFS to compile/build on my V88 RK3328 box. I also did switch to experimental kernel (beta) and things went fine. Thank you very much!
Kattaleya Posted July 21, 2018 Posted July 21, 2018 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.
tkaiser Posted July 21, 2018 Posted July 21, 2018 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.
Recommended Posts