gprovost Posted December 26, 2019 Posted December 26, 2019 @dkxls Right now we are too busy on Helios64. Our wiki is open to contribution, so would be greatly appreciated if you or someone else compile all the useful info on this thread into a wiki page. We are using mkdocs, so it's pretty straight forward to write a page. https://github.com/helios-4/wiki 0 Quote
dkxls Posted December 26, 2019 Posted December 26, 2019 @gprovost Sure. I wasn't aware that you accept community contributions to the wiki. I might take a stab at that once I have my own setup working ... If someone else, probably more experienced with ZFS, is up for that, please go ahead - I for one would certainly appreciate it. 1 Quote
dkxls Posted January 28, 2020 Posted January 28, 2020 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. 2 Quote
dkxls Posted February 7, 2020 Posted February 7, 2020 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. 1 Quote
TRS-80 Posted February 8, 2020 Posted February 8, 2020 @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! 0 Quote
Steven Keuchel Posted February 11, 2020 Posted February 11, 2020 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. 2 Quote
dkxls Posted February 18, 2020 Posted February 18, 2020 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. 0 Quote
SvenHz Posted January 27, 2021 Author Posted January 27, 2021 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 :-) 0 Quote
Werner Posted January 27, 2021 Posted January 27, 2021 34 minutes ago, SvenHz said: edit: please move this topic to the Helios4 section, thanks :-) Done 1 Quote
Igor Posted January 27, 2021 Posted January 27, 2021 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 3 Quote
SvenHz Posted January 27, 2021 Author Posted January 27, 2021 Wow thanks Igor. Clear. I will wait a bit to see if the cross-compilation issue is fixed soon. Otherwise I'll stick with the out-of-tree module build that I had done last year. 0 Quote
dkxls Posted February 13, 2021 Posted February 13, 2021 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). 1 Quote
SvenHz Posted March 20, 2021 Author Posted March 20, 2021 (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 March 20, 2021 by TRS-80 put long outputs inside spoilers 2 Quote
dkxls Posted April 27, 2021 Posted April 27, 2021 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: /etc/apt/sources.list.d/testing.list: deb http://httpredir.debian.org/debian testing main #deb-src http://httpredir.debian.org/debian testing main /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. 1 Quote
Recommended Posts
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.