Call for testers: OMV4 for ARM boards

  • I started to create OMV4 images for ARM boards. After checking download statistics I will only care about boards for which images were downloaded at least 30 times a month.


    The goal ist the same as with the OMV 3 approach from last year: provide settings that allow for maximum performance with minimum consumption at the same time, flashmemory plugin enabled to reduce wear on SD cards, no monitoring activated by intention for the same reason.


    The whole process is scripted as usual so it's rather boring to go through this. Also I gave away or sold most of the boards I owned last year so I won't be able to test through a lot of boards.


    At this URL http://kaiser-edv.de/tmp/jCslC8/ OMV4 images have been uploaded, most probably followed by one for Raspberries soon (due to closed source nature of the RPi stuff requiring maximum efforts). For each image/board at least one volunteer is needed booting the image, doing some basic tests, logging in via SSH and providing generic feedback and 'armbianmonitor -u' output (see below for example URLs).


    The below test results will be updated over time:


    • Allwinner A20 family: Successfully tested Cubietruck (myself), Banana Pi (frankm)
    • Allwinner H3 family: Successfully tested Orange PI PC Plus (myself)
    • Allwinner H5 family: Successfully tested OPi Zero Plus (by guidol). Known issue: cpufreq not working, CPU cores limited to 816 MHz, shouldn't affect NAS performance that much and will be fixed by apt update in a few weeks/months
    • ODROID-C2: Successfully tested (by @ryecoaaron)
    • ODROID-XU4/HC1/HC2: Successfully tested (by @vinntec)
    • Pine64: Successfully tested (by [ade]). Known issue: cpufreq and thermal readouts not working, CPU cores limited to 816 MHz, shouldn't affect NAS performance that much and will be fixed by apt update in a few weeks/months
    • Raspberry Pi: Successfully tested RPi 2 (myself), RPi 3 ( jata1)
    • Offizieller Beitrag

    I can test on the C2 and XU4 and RPi 2/3 (if you create the image :) ) Downloading the images now.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • A special candidate is ODROID-C2. Last year I tried pretty hard to build an OMV3 image relying on a somewhat recent mainline kernel to get rid of the smelly 3.14 kernel the C2 usually runs with. But to no avail, there were always issues with this board (2nd most time consuming board after RPi).


    In the meantime I gave away all my Amlogic boards (since rather boring for NAS use cases due to shared USB2 bandwidth -- almost as lousy as with RPi). So I can't test at all.


    I prepared 2 images that should be tested in that order:

    A full test including network and USB storage performance is needed. I hope the first image (mainline with btrfs) will work but if not it should be pretty obvious within a minute (bootloader not able to access btrfs partition). In that case mainline on ext4 would be the next try and only if this doesn't succeed I look into building an image with the old/boring kernel.


    BTW: the download size of the btrfs images is larger than those of ext4 images but uncompressed when burned to SD card it's exactly the opposite since our btrfs images are created with zlib compression and later run with faster lzo compression. The larger download size is just the result of recompressing already compressed data resulting in a larger size unfortunately. But the btrfs images make a lot better use of the SD card's or eMMC's capacity due to transparent filesystem compression.

  • I can test on the C2 and XU4

    Would be great if you could test through both C2 and the XU4 image. I'll look into Raspberry Pi only if all the other images are tested due to avoiding unnecessary duplicate efforts (the image creation process for RPi is magnitudes more time consuming due to the proprietary RPi crap needing that ThreadX/bootloader stuff on a separate partition and so on)

    • Offizieller Beitrag

    A full test including network and USB storage performance is needed.

    Would be great if you could test through both C2 and the XU4 image.

    I will test them.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Burned image to SD card no problem. Booted very quickly, enabled root login on GUI, connected on SSH, and issued command "armbianmonitor -u" as requested. Response was "System diagnosis information will now be uploaded to ix.io/1bJJ" which I hope has worked, no error messages.


    Yep, http://ix.io/1bJJ looks fine to me. One known problem of the new image is that Hardkernel's support repos for their Cloudshell 2 stuff do not work. At image creation time I got


    Code
    E: Unable to locate package odroid-cloudshell
    E: Unable to locate package cloudshell2-fan

    But honestly don't care. Up to Hardkernel to add instructions to their wiki to add this stuff manually later.


    From my point of view the XU4/HC1/HC2 image is ready. Thank you!

  • Yep, http://ix.io/1bJJ looks fine to me. One known problem of the new image is that Hardkernel's support repos for their Cloudshell 2 stuff do not work. At image creation time I got


    Code
    E: Unable to locate package odroid-cloudshell
    E: Unable to locate package cloudshell2-fan

    But honestly don't care. Up to Hardkernel to add instructions to their wiki to add this stuff manually later.


    From my point of view the XU4/HC1/HC2 image is ready. Thank you!

    As far as I can see these both relate to the Cloudshell cases for the XU4 and won't affect anyone else. Installing them is mentioned in the Cloudshell Wiki and that should be enough hints for most people who happen to have one and are installing OMV4. You might mention it in the readme?

    • Offizieller Beitrag

    odroid-c2 is running well with btrfs image. It pretty much saturates usb2 according to lantest even with junky old 500gb drives. Here is the armbianmonitor output: http://ix.io/1bLf


    Just another note... I have been running this C2 with the armbian nightly Ubuntu image and the 4.14 kernel for a couple of months as my dns server. It works very well and even running fine since I release upgraded it to Ubuntu 18 a couple of weeks ago.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • odroid-c2 is running well with btrfs image

    Great, I already removed the ext4 variant. Now all that's missing is at least one tested Allwinner H5 board then I would already be fine with moving all those images over to Sourceforge.


    I might ask someone over at Armbian directly to test (the only H5 boards I currently have are two new NanoPi K1 Plus who are great performers but I lack the time to do the board bring-up right now).


    Got in the meantime feedback from a Pine64 user and frankm is testing in a few hours with Banana Pi.

  • BTW: In case anyone is wondering why ODROID-C1/C1+ are missing? Due to insufficient kernel support.


    Debian Stretch which is the basis for OMV4 requires kernel 3.14 for all (security) features and since ODROID-C1 is still on a smelly 3.10 kernel (unmaintained since Oct 2017!) there will be no OMV4 image for this board.


    Most probably existing OMV3/Jessie images can be updated with omv-release-upgrade but I neither know nor care what will not work afterwards. If you want to run OMV4 on your C1 you're on your own until whoever improves mainline kernel support for Amlogic's S805 SoC inside the C1.


    On the bright side: I sold my own C1+ half a year ago. To a guy who's name sounded somewhat familiar. But I only realized after I sold my ODROID to him who he was: Martin Blumenstingl, one of those awesome guys contributing a lot around Amlogic SoCs/boards to mainline kernel. If I would've realized earlier the C1+ would've been a donation. Silly me :(


    But at least one talented kernel developer has now a C1+ in his hands so things might improve wrt mainline kernel and Amlogic S805 devices like ODROID-C1.

  • RPi image ready: OMV_4_Raspberry_Pi_2_3_3Plus.img.xz


    Image creation process is slightly different than before with OMV 3. Now I let an OMV 4 image for Tinkerboard create and then automagically adjust as much as possible already as part of Armbian's user customizations.


    This time I moved a lot of action from firstrun service (executed at first boot) to customize-image.sh so in a final step on my MacBook already the image will be turned into something useful with RPi and way less storage activity happens on the first boot. Almost the whole stuff is scripted and in a repo as usual: https://github.com/ThomasKaiser/OMV4_for_Raspberries


    But due to RPi's closed source character (the primary operating system called ThreadX that needs to be loaded first from a FAT partition and so on) for me there's always also some annoying manual steps included to take a RPi image skeleton and replace the rootfs there (and also /etc/fstab since this gets modified by Armbian's build system in a final step)


    I tested on a RPi 2, should flawlessly work also on RPi 3 and 3+ since shares the /boot partition with all the proprietary RPi crap with our latest OMV 3 image. The image contains kernel 4.9.80 on the /boot partition that gets updated on first boot to latest 4.14.x kernel available from raspberrypi.org (it's a feature since this way we can spot easily if users screwed up first boot and have a broken installation). As usual one automatic reboot happens after first boot though should now happen way faster than before.


    Feedback welcome.

  • I will test them

    There you go: OMV_4_Raspberry_Pi_2_3_3Plus.img.xz -- only feedback from RPi 3 needed. And while the image must boot on a RPi 3+ too (since the relevant stuff is the proprietary ThreadX installation on the /boot partition where I didn't change a single bit) some feedback from RPi 3+ owners would help too.

    • Offizieller Beitrag

    There you go

    Downloading now. Can't wait to see how awesome the performance is... lol

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • @Frepke: I just created an OMV 4 image for Espressobin (untested). In case you want to give it a try: OMV_4_Espressobin.img.xz


    And Tinkerboard image (also untested) is uploading also: OMV_4_Tinkerboard.img.xz

    Thanks Thomas,


    That's very nice, unfortunately I sold my Espressobin and bought an HC1.
    The Espressobin wasn't stable enough for daily use, the HC1 runs without problems OMV4 for months now :)


    I tried to make an backup image/clone from the SD-card I currently use so I can try the new OMV4 image, but I can't make a useful backup from my SD-card (3 partitions; ext4, btrfs, btrfs)


    kr.,
    Frepke

    HP t630 Thin Cliënt (AMD Embedded G-Series GX-420GI | QuadCore | 8GB)
    7.0.3-1 (Sandworm) | 64 bit | pve-kernel-6.5 | omvextrasorg 7.0

    Einmal editiert, zuletzt von Frepke ()

    • Offizieller Beitrag

    RPi image seems to work ok. armbianmonitor output - http://ix.io/198a


    Not sure what kind of network adapter predictable name this is though; enxb827eb16c0de :D

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • RPi image seems to work ok. armbianmonitor output - ix.io/198a

    Thank you. Though after looking a bit closer I think I found a couple of issues, some generic, some related to the RPi image.


    In general there's a duplicate entry resulting in 'apt update' warning:

    Code
    W: Target Packages (main/binary-armhf/Packages) is configured multiple times in /etc/apt/sources.list:7 and /etc/apt/sources.list.d/openmediavault-kernel-backports.list:1


    And then this error occurs for whatever reasons:


    Code
    Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x762f8390>
    Traceback (most recent call last):
      File "/usr/lib/python3.5/weakref.py", line 117, in remove
    TypeError: 'NoneType' object is not callable
    Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x762f8390>
    Traceback (most recent call last):
      File "/usr/lib/python3.5/weakref.py", line 117, in remove
    TypeError: 'NoneType' object is not callable

    On the RPi there is a cosmetic problem with motd (affecting local and SSH login and easily fixable by other permissions). But with the current contents of /etc/apt/preferences.d/99raspberrypiorg we're running in a mixture of Raspbian+Debian packages after each update.



    I tried to play around with pin priorities, ending up here


    ...but to no avail. Still normal packages in ARMv6 version are pulled in from archive.raspberrypi.org ignoring Debian's packages.



    I'm still not familiar with apt pinning, wasted huge amounts of time last September with this and not willing to do it again. If we don't find an easy solution to only pull in 'firmware-brcm80211 libraspberrypi-bin libraspberrypi0 raspberrypi-bootloader raspberrypi-kernel' from raspberrypi.org and ignore everything else at least I will drop the idea to provide an OMV4 for Raspberries immediately.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!