ZFS on Helios4


SvenHz

Recommended Posts

Donate and support the project!

I finally got ZFS installed on my Helios4 using Armbian 19.11.3 Buster with Linux 4.19.84, but I had to stick with ZFS version 0.7.12, as advise by @SvenHz in this post. Loading the ZFS 0.8 module would fail with the same error.

 

@Steven Keuchel  Thanks again for your input on the kernel/ZFS memory settings. I had a more detailed look at your settings and noticed that you set `zfs_arc_max=805306368` (i.e. to 768 MB), which corresponds to the maximum `vmalloc` you seem to use. Or were those ZFS settings with `CONFIG_VMSPLIT_2G` and you use in fact an even higher value for `vmalloc`? Which ZFS version did you use, 0.6 or 0.7?

 

As @qstaq stated, the default for `zfs_arc_max` is 50% of the available memory. There is however a pull request to increase this even further to 3/4 of all memory or all but 1GB, whichever is greater. This change is enabled due to the revised memory allocation for the ARC buffers in ZFS version 0.7.  In fact, this change makes me wonder if those settings for `vmalloc` and `zfs_arc_max` still make sense for ZFS >= 0.7. 

 

The fundamental issue with the extensive use of the virtual address space in ZFS was outlined rather well by one of the developers in this ZOL issue. This was addressed however in version 0.7 with the introduction of the ARC Buffer Data (ABD), as also mentioned in the ZFS 0.7 release notes.

 

It appears that the issues with the virtual address space are limited to ZFS versions 0.6 and older. Or is my understanding of this incorrect? Any advice or comment in this regard would be greatly appreciated.

Link to post
Share on other sites
On 12/23/2019 at 8:19 AM, SvenHz said:

If I manually use dkms to build the ZFS 0.8.2 from the sources left around by apt-get, I get a successful build, however "mobprobe zfs" gives me a Exec Format Error. dmesg shows:

zlua: section 4 reloc 44 sym 'longjmp': unsupported interworking call (Thumb -> ARM)

 

Does anyone have 0.8.2 succesfully running on Helios4?

 

@SvenHz I made some progress on tracking down this issue with zfs 0.8 on the Helios4, more precisely James Robertson (@jsrlabs) identified and fixed the missing Thumb-2 instructions used by the Armbian kernel, see the discussion on the ZFS mailinglist.

 

I went ahead and opened a bug report (zfsonlinux/zfs#9957), and one of the zfs developers proposed a fix in this pull request: zfsonlinux/zfs#9967. However, the fix needs testing, so I thought to bring this up here in the hope that someone else will give this a shot as well.

Link to post
Share on other sites

@dkxls,

 

Thanks for your digging into using ZFS on 32-bit on ARM (I also found your recent thread on the ZoL mailing list). This revelation about changes in ZoL 0.7 appears to blow my previous assumptions about 64-bit being required (in general) for ZFS right out of the water. Which opens up a lot more hardware possibilities (in particular, ironically enough, outside of ARM).

 

Within ARM, the Helios4 is the only hardware I am aware of that has ECC memory (that is not something designed for server farms). And as far as I am concerned, there is no point really doing ZFS without ECC.

 

At this point I am really looking forward to Helios64 going forward. But this is still great news for lots of older 32-bit pre-IME x86 hardware.

 

Cheers!

Link to post
Share on other sites
On 1/28/2020 at 4:01 AM, dkxls said:

I finally got ZFS installed on my Helios4 using Armbian 19.11.3 Buster with Linux 4.19.84, but I had to stick with ZFS version 0.7.12, as advise by @SvenHz in this post. Loading the ZFS 0.8 module would fail with the same error.

 

@Steven Keuchel  Thanks again for your input on the kernel/ZFS memory settings. I had a more detailed look at your settings and noticed that you set `zfs_arc_max=805306368` (i.e. to 768 MB), which corresponds to the maximum `vmalloc` you seem to use. Or were those ZFS settings with `CONFIG_VMSPLIT_2G` and you use in fact an even higher value for `vmalloc`? Which ZFS version did you use, 0.6 or 0.7?

 

As @qstaq stated, the default for `zfs_arc_max` is 50% of the available memory. There is however a pull request to increase this even further to 3/4 of all memory or all but 1GB, whichever is greater. This change is enabled due to the revised memory allocation for the ARC buffers in ZFS version 0.7.  In fact, this change makes me wonder if those settings for `vmalloc` and `zfs_arc_max` still make sense for ZFS >= 0.7. 

 

The fundamental issue with the extensive use of the virtual address space in ZFS was outlined rather well by one of the developers in this ZOL issue. This was addressed however in version 0.7 with the introduction of the ARC Buffer Data (ABD), as also mentioned in the ZFS 0.7 release notes.

 

It appears that the issues with the virtual address space are limited to ZFS versions 0.6 and older. Or is my understanding of this incorrect? Any advice or comment in this regard would be greatly appreciated.

The 768MB arc_max was for a vmalloc of 1024MB and I was using zfs 0.7.12 when I wrote that, but since then I have switched to 0.8 (with Thumb2 patches from github). I have looked at this again (now with 0.8), and it seems the situation has indeed changed. When looking at vmalloc of zfs (spl actually) via /proc/vmallocinfo it seems to hover around 100-150MB with about 220MB being the highest I've seen and also the total address space occupied by all allocations has always been under 300MB and usually far below. So it seems rather compact with only little fragmentation happening. So zfs appears to use less vmalloc than I assumed and more lowmem, so I will have to revise my settings, because they clearly don't make sense anymore.

Link to post
Share on other sites
On 2/11/2020 at 11:10 PM, Steven Keuchel said:

The 768MB arc_max was for a vmalloc of 1024MB and I was using zfs 0.7.12 when I wrote that, but since then I have switched to 0.8 (with Thumb2 patches from github). I have looked at this again (now with 0.8), and it seems the situation has indeed changed. When looking at vmalloc of zfs (spl actually) via /proc/vmallocinfo it seems to hover around 100-150MB with about 220MB being the highest I've seen and also the total address space occupied by all allocations has always been under 300MB and usually far below. So it seems rather compact with only little fragmentation happening. So zfs appears to use less vmalloc than I assumed and more lowmem, so I will have to revise my settings, because they clearly don't make sense anymore.

Thanks @Steven Keuchel for clarifying this. I am currently running zfs 0.7.12 with the default memory settings on my helios4 and haven't encountered any issues yet. 

 

Regarding zfs 0.8, it would be good if you could post your experience with the patched version from zfsonlinux/zfs#9967 in that PR to get more feedback on the changes. We also still need zfs test results from other ARM 32-bit systems to establish a baseline before this can get merged.

Link to post
Share on other sites

So, reporting in here after over a year of smooth operations on the Helios4 with zfs 0.7.x. Soon I'd like to upgrade (clean install) and I see a lot of things happening with ZFS 2.0.x on Helios64 with Armbian. I am a bit lost, so: what is the current best/easiest way to install ZFS 2.0.x on Helios4? I'd like to move to an LTS kernel if possible (not a hard requirement). Ideally future upgrades are 'easy' but again not a hard feature, I can live with a reinstall once a year.

edit: please move this topic to the Helios4 section, thanks :-)

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

what is the current best/easiest way to install ZFS 2.0.x on Helios4?


There are problems with 32bit ZFS support and there is nothing more we can do. 

https://github.com/armbian/build/pull/2547 

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

Broken od Debian, buildable on Ubuntu based Armbian. At least on latest (LTS) kernel 5.10.y


Upgrade to 5.10.y on 32bit target doesn't work automatically ...

 

Spoiler





apt upgrade                              
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  armbian-config armbian-firmware armbian-zsh linux-dtb-current-rockchip
  linux-focal-root-current-tinkerboard linux-headers-current-rockchip linux-image-current-rockchip
  linux-u-boot-tinkerboard-current
8 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 48.9 MB of archives.
After this operation, 741 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 https://beta.armbian.com focal/main armhf armbian-config all 21.02.0-trunk.79 [44.5 kB]
Get:2 https://beta.armbian.com focal/main armhf armbian-firmware all 21.02.0-trunk.79 [6,919 kB]
Get:3 https://beta.armbian.com focal/main armhf armbian-zsh all 21.02.0-trunk.79 [1,849 kB]
Get:4 https://beta.armbian.com focal/main armhf linux-dtb-current-rockchip armhf 21.02.0-trunk.78 [76.7 kB]
Get:5 https://beta.armbian.com focal/main armhf linux-focal-root-current-tinkerboard armhf 21.02.0-trunk.80 [433 kB]
Get:6 https://beta.armbian.com focal/main armhf linux-headers-current-rockchip armhf 21.02.0-trunk.78 [11.5 MB]
Get:7 https://beta.armbian.com focal/main armhf linux-image-current-rockchip armhf 21.02.0-trunk.78 [27.5 MB]
Get:8 https://beta.armbian.com focal/main armhf linux-u-boot-tinkerboard-current armhf 21.02.0-trunk.62 [496 kB]
Fetched 48.9 MB in 5s (9,363 kB/s)                    
(Reading database ... 67811 files and directories currently installed.)
Preparing to unpack .../0-armbian-config_21.02.0-trunk.79_all.deb ...
Unpacking armbian-config (21.02.0-trunk.79) over (20.11.6) ...
Preparing to unpack .../1-armbian-firmware_21.02.0-trunk.79_all.deb ...
Unpacking armbian-firmware (21.02.0-trunk.79) over (20.11.3) ...
Preparing to unpack .../2-armbian-zsh_21.02.0-trunk.79_all.deb ...
Unpacking armbian-zsh (21.02.0-trunk.79) over (20.11.10) ...
Preparing to unpack .../3-linux-dtb-current-rockchip_21.02.0-trunk.78_armhf.deb ...
Unpacking linux-dtb-current-rockchip (21.02.0-trunk.78) over (20.11.3) ...
Preparing to unpack .../4-linux-focal-root-current-tinkerboard_21.02.0-trunk.80_armhf.deb ...
Unpacking linux-focal-root-current-tinkerboard (21.02.0-trunk.80) over (20.11.6) ...
Preparing to unpack .../5-linux-headers-current-rockchip_21.02.0-trunk.78_armhf.deb ...
Unpacking linux-headers-current-rockchip (21.02.0-trunk.78) over (20.11.3) ...
Preparing to unpack .../6-linux-image-current-rockchip_21.02.0-trunk.78_armhf.deb ...
dkms: removing: zfs 2.0.1 (5.9.14-rockchip) (armv7l)

-------- Uninstall Beginning --------
Module:  zfs
Version: 2.0.1
Kernel:  5.9.14-rockchip (armv7l)
-------------------------------------

Status: Before uninstall, this module version was ACTIVE on this kernel.

zavl.ko:
 - Uninstallation
   - Deleting from: /lib/modules/5.9.14-rockchip/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.


znvpair.ko:
 - Uninstallation
   - Deleting from: /lib/modules/5.9.14-rockchip/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.


zunicode.ko:
 - Uninstallation
   - Deleting from: /lib/modules/5.9.14-rockchip/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.


zcommon.ko:
 - Uninstallation
   - Deleting from: /lib/modules/5.9.14-rockchip/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.


zfs.ko:
 - Uninstallation
   - Deleting from: /lib/modules/5.9.14-rockchip/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.


icp.ko:
 - Uninstallation
   - Deleting from: /lib/modules/5.9.14-rockchip/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.


zlua.ko:
 - Uninstallation
   - Deleting from: /lib/modules/5.9.14-rockchip/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.


spl.ko:
 - Uninstallation
   - Deleting from: /lib/modules/5.9.14-rockchip/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.


zzstd.ko:
 - Uninstallation
   - Deleting from: /lib/modules/5.9.14-rockchip/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.

depmod.....

DKMS: uninstall completed.

------------------------------
Deleting module version: 2.0.1
completely from the DKMS tree.
------------------------------
Done.
update-initramfs: Deleting /boot/initrd.img-5.9.14-rockchip
Removing obsolete file uInitrd-5.9.14-rockchip
Unpacking linux-image-current-rockchip (21.02.0-trunk.78) over (20.11.3) ...
Preparing to unpack .../7-linux-u-boot-tinkerboard-current_21.02.0-trunk.62_armhf.deb ...
Unpacking linux-u-boot-tinkerboard-current (21.02.0-trunk.62) over (20.11.6) ...
Setting up linux-dtb-current-rockchip (21.02.0-trunk.78) ...
Setting up linux-headers-current-rockchip (21.02.0-trunk.78) ...
Compiling headers - please wait ...
Setting up linux-image-current-rockchip (21.02.0-trunk.78) ...
 * dkms: running auto installation service for kernel 5.10.10-rockchip                                [ OK ] 
update-initramfs: Generating /boot/initrd.img-5.10.10-rockchip
update-initramfs: Converting to u-boot format
Setting up armbian-zsh (21.02.0-trunk.79) ...
Setting up armbian-config (21.02.0-trunk.79) ...
Setting up armbian-firmware (21.02.0-trunk.79) ...
Setting up linux-u-boot-tinkerboard-current (21.02.0-trunk.62) ...
Setting up linux-focal-root-current-tinkerboard (21.02.0-trunk.80) ...
Processing triggers for initramfs-tools (0.136ubuntu6.3) ...
update-initramfs: Generating /boot/initrd.img-5.10.10-rockchip
update-initramfs: Converting to u-boot format

 

after reboot you need to run 

dpkg-reconfigure zfs-dkms

and select that you agree with 32b troubles but at the end, it works. I could load my pool without issues.

Spoiler





dpkg-reconfigure zfs-dkms

------------------------------
Deleting module version: 2.0.1
completely from the DKMS tree.
------------------------------
Done.
WARNING: Building ZFS module on a 32-bit kernel.
Loading new zfs-2.0.1 DKMS files...
Building for 5.10.10-rockchip
Building initial module for 5.10.10-rockchip
/var/lib/dkms/zfs/2.0.1/build/configure: line 13146: test: =: unary operator expected
/var/lib/dkms/zfs/2.0.1/build/configure: line 13154: test: =: unary operator expected
/var/lib/dkms/zfs/2.0.1/build/configure: line 13162: test: =: unary operator expected
/var/lib/dkms/zfs/2.0.1/build/configure: line 13170: test: =: unary operator expected
/var/lib/dkms/zfs/2.0.1/build/configure: line 13178: test: =: unary operator expected
Done.

zavl.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.10-rockchip/updates/dkms/

znvpair.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.10-rockchip/updates/dkms/

zunicode.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.10-rockchip/updates/dkms/

zcommon.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.10-rockchip/updates/dkms/

zfs.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.10-rockchip/updates/dkms/

icp.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.10-rockchip/updates/dkms/

zlua.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.10-rockchip/updates/dkms/

spl.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.10-rockchip/updates/dkms/

zzstd.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.10-rockchip/updates/dkms/

depmod......

DKMS: install completed.
root@tinkerboard:~# modprobe zfs

 

 

Link to post
Share on other sites
On 1/28/2021 at 2:08 AM, SvenHz said:

Otherwise I'll stick with the out-of-tree module build that I had done last year.

I just recently upgraded my Helios4 to Armbian 20.11.6 with kernel 5.9.14-mvebu. I encountered some minor hiccups, which turn out to be either a kernel or binutils bug, but the binutils developers fixed this in the 2.35 release which you can install from testing (see https://github.com/openzfs/zfs/issues/11444 for the details).

 

I haven't tested this on a 5.10-kernel, nor have I made the switch to ZFS 2.0 yet. But according to @Igor this seems to work also just fine. @SvenHz, if you get this working on your Helios4, I would appreciate if you could report this here, just to keep track of any issues (or the absence thereof).

Link to post
Share on other sites
Posted (edited)

Here is an update. TL;DR: happy to report that zfs 2.0.2 seems to work fine on Armbian Hirsute.

 

I am planning a reinstall of our "family production NAS" with the aim to do as little hacking/customization as possible to get ZFS to work.

 

First I tried both the current (Mar 2021) Buster and Focal images but failed at the 'apt install zfs-dkms' step due to "exec format error" and basically failing to produce a working kernel module for ZFS. I suspect this is caused by the older binutils on both images.

 

So then I downloaded the Ubuntu Hirsute unstable image with kernel 5.10.23 of 13 Mar 2021. Supplied binutils is 2.36 I believe.


After the clean install, these are the steps I took:

 

# apt update
# apt upgrade
Use armbian-config to install kernel headers (turns out to be 5.10.17)
Use armbian-config to downgrade kernel 5.10.23 to 5.10.17 to match old headers...
# apt install zfs-dkms

 

Spoiler

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
  debhelper
Recommended packages:
  zfs-zed zfsutils-linux linux-libc-dev
The following NEW packages will be installed:
  zfs-dkms
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 2,222 kB of archives.
After this operation, 17.3 MB of additional disk space will be used.
Get:1 http://ports.ubuntu.com hirsute/universe armhf zfs-dkms all 2.0.2-1ubuntu3 [2,222 kB]
Fetched 2,222 kB in 0s (4,991 kB/s)
Preconfiguring packages ...
Selecting previously unselected package zfs-dkms.
(Reading database ... 68376 files and directories currently installed.)
Preparing to unpack .../zfs-dkms_2.0.2-1ubuntu3_all.deb ...
Unpacking zfs-dkms (2.0.2-1ubuntu3) ...
Setting up zfs-dkms (2.0.2-1ubuntu3) ...
WARNING: Building ZFS module on a 32-bit kernel.
Loading new zfs-2.0.2 DKMS files...
Building for 5.10.17-mvebu
Building initial module for 5.10.17-mvebu
/var/lib/dkms/zfs/2.0.2/build/configure: line 16422: test: =: unary operator expected
/var/lib/dkms/zfs/2.0.2/build/configure: line 16430: test: =: unary operator expected
/var/lib/dkms/zfs/2.0.2/build/configure: line 16438: test: =: unary operator expected
/var/lib/dkms/zfs/2.0.2/build/configure: line 16446: test: =: unary operator expected
/var/lib/dkms/zfs/2.0.2/build/configure: line 16454: test: =: unary operator expected
Done.

zavl.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.17-mvebu/updates/dkms/

znvpair.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.17-mvebu/updates/dkms/

zunicode.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.17-mvebu/updates/dkms/

zcommon.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.17-mvebu/updates/dkms/

zfs.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.17-mvebu/updates/dkms/

icp.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.17-mvebu/updates/dkms/

zlua.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.17-mvebu/updates/dkms/

spl.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.17-mvebu/updates/dkms/

zzstd.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.10.17-mvebu/updates/dkms/

depmod.....

DKMS: install completed.
Processing triggers for initramfs-tools (0.139ubuntu2) ...
update-initramfs: Generating /boot/initrd.img-5.10.17-mvebu
W: Possible missing firmware /lib/firmware/renesas_usb_fw.mem for built-in driver xhci_pci
update-initramfs: Converting to u-boot format

 


apt install zfsutils-linux

 

Spoiler

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libnvpair3linux libuutil3linux libzfs4linux libzpool4linux
Suggested packages:
  nfs-kernel-server samba-common-bin zfs-initramfs | zfs-dracut
Recommended packages:
  fs-zed
The following NEW packages will be installed:
  libnvpair3linux libuutil3linux libzfs4linux libzpool4linux zfsutils-linux
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,949 kB of archives.
After this operation, 5,012 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://ports.ubuntu.com hirsute/main armhf libnvpair3linux armhf 2.0.2-1ubuntu3 [45.2 kB]
Get:2 http://ports.ubuntu.com hirsute/main armhf libuutil3linux armhf 2.0.2-1ubuntu3 [46.3 kB]
Get:3 http://ports.ubuntu.com hirsute/main armhf libzfs4linux armhf 2.0.2-1ubuntu3 [219 kB]
Get:4 http://ports.ubuntu.com hirsute/main armhf libzpool4linux armhf 2.0.2-1ubuntu3 [1,177 kB]
Get:5 http://ports.ubuntu.com hirsute/main armhf zfsutils-linux armhf 2.0.2-1ubuntu3 [461 kB]
Fetched 1,949 kB in 0s (4,728 kB/s)
Selecting previously unselected package libnvpair3linux.
(Reading database ... 69284 files and directories currently installed.)
Preparing to unpack .../libnvpair3linux_2.0.2-1ubuntu3_armhf.deb ...
Unpacking libnvpair3linux (2.0.2-1ubuntu3) ...
Selecting previously unselected package libuutil3linux.
Preparing to unpack .../libuutil3linux_2.0.2-1ubuntu3_armhf.deb ...
Unpacking libuutil3linux (2.0.2-1ubuntu3) ...
Selecting previously unselected package libzfs4linux.
Preparing to unpack .../libzfs4linux_2.0.2-1ubuntu3_armhf.deb ...
Unpacking libzfs4linux (2.0.2-1ubuntu3) ...
Selecting previously unselected package libzpool4linux.
Preparing to unpack .../libzpool4linux_2.0.2-1ubuntu3_armhf.deb ...
Unpacking libzpool4linux (2.0.2-1ubuntu3) ...
Selecting previously unselected package zfsutils-linux.
Preparing to unpack .../zfsutils-linux_2.0.2-1ubuntu3_armhf.deb ...
Unpacking zfsutils-linux (2.0.2-1ubuntu3) ...
Setting up libnvpair3linux (2.0.2-1ubuntu3) ...
Setting up libuutil3linux (2.0.2-1ubuntu3) ...
Setting up libzfs4linux (2.0.2-1ubuntu3) ...
Setting up libzpool4linux (2.0.2-1ubuntu3) ...
Setting up zfsutils-linux (2.0.2-1ubuntu3) ...
insmod /lib/modules/5.10.17-mvebu/updates/dkms/spl.ko
insmod /lib/modules/5.10.17-mvebu/updates/dkms/icp.ko
insmod /lib/modules/5.10.17-mvebu/updates/dkms/zavl.ko
insmod /lib/modules/5.10.17-mvebu/updates/dkms/znvpair.ko
insmod /lib/modules/5.10.17-mvebu/updates/dkms/zcommon.ko
insmod /lib/modules/5.10.17-mvebu/updates/dkms/zlua.ko
insmod /lib/modules/5.10.17-mvebu/updates/dkms/zzstd.ko
insmod /lib/modules/5.10.17-mvebu/updates/dkms/zunicode.ko
insmod /lib/modules/5.10.17-mvebu/updates/dkms/zfs.ko
Created symlink /etc/systemd/system/zfs-import.target.wants/zfs-import-cache.service → /lib/systemd/system/zfs-import-cache.service.
Created symlink /etc/systemd/system/zfs.target.wants/zfs-import.target → /lib/systemd/system/zfs-import.target.
Created symlink /etc/systemd/system/zfs-mount.service.wants/zfs-load-module.service → /lib/systemd/system/zfs-load-module.service.
Created symlink /etc/systemd/system/zfs.target.wants/zfs-load-module.service → /lib/systemd/system/zfs-load-module.service.
Created symlink /etc/systemd/system/zfs.target.wants/zfs-mount.service → /lib/systemd/system/zfs-mount.service.
Created symlink /etc/systemd/system/zfs.target.wants/zfs-share.service → /lib/systemd/system/zfs-share.service.
Created symlink /etc/systemd/system/zfs-volumes.target.wants/zfs-volume-wait.service → /lib/systemd/system/zfs-volume-wait.service.
Created symlink /etc/systemd/system/zfs.target.wants/zfs-volumes.target → /lib/systemd/system/zfs-volumes.target.
Created symlink /etc/systemd/system/multi-user.target.wants/zfs.target → /lib/systemd/system/zfs.target.
zfs-import-scan.service is a disabled or a static unit, not starting it.
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for libc-bin (2.33-0ubuntu2) ...

 

 

After this and a reboot, I successfully imported an existing (zfs 0.7.x) pool.

So far so good. I will wait until we are stable with Hirsute.

 

Edited by TRS-80
put long outputs inside spoilers
Link to post
Share on other sites
On 3/21/2021 at 2:39 AM, SvenHz said:

Here is an update. TL;DR: happy to report that zfs 2.0.2 seems to work fine on Armbian Hirsute.

Great! Thanks @SvenHz for sharing your experience!

 

 

Quote

First I tried both the current (Mar 2021) Buster and Focal images but failed at the 'apt install zfs-dkms' step due to "exec format error" and basically failing to produce a working kernel module for ZFS. I suspect this is caused by the older binutils on both images.

Yes, it's very likely the issue I mentioned above with binutils, for the Debian Buster image I am actually sure as the stable repositories still have version 2.31 which is too old.

 

The simple solution here is to use the packages from the Debian testing repository. This can be simply done by adding two files:

  1.  /etc/apt/sources.list.d/testing.list:
    deb http://httpredir.debian.org/debian testing main
    #deb-src http://httpredir.debian.org/debian testing main

     

  2.  /etc/apt/preferences.d/10_testing:
    Package: *
    Pin: release a=testing
    Pin-Priority: -10
    
    Package: binutils binutils-common libbinutils binutils-arm-linux-gnueabihf libctf0
    Pin: release a=testing
    Pin-Priority: 900

After that a simple "apt update && apt upgrade" should do the trick. With these settings, apt will only prefer the listed binutils packages from testing and keep all other packages as they are.

Link to post
Share on other sites