Building OMV automatically for a bunch of different ARM dev boards

  • New image: OMV_3_0_70_Odroidxu4_4.9.23.7z


    Problem is that monitoring is not disabled since the RPC calls running in the chroot environment failed:


    Code
    {"response":null,"error":{"code":0,"message":"Failed to connect to socket: No such file or directory","trace":"exception 'OMV\\Rpc\\Exception' with message 'Failed to connect to socket: No such file or directory' in \/usr\/share\/php\/openmediavault\/rpc\/rpc.inc:140\nStack trace:\n#0 \/usr\/sbin\/omv-rpc(107): OMV\\Rpc\\Rpc::call('perfstats', 'set', Array, Array, 2)\n#1 {main}"}}
    {"response":null,"error":{"code":0,"message":"Failed to connect to socket: No such file or directory","trace":"exception 'OMV\\Rpc\\Exception' with message 'Failed to connect to socket: No such file or directory' in \/usr\/share\/php\/openmediavault\/rpc\/rpc.inc:140\nStack trace:\n#0 \/usr\/sbin\/omv-rpc(107): OMV\\Rpc\\Rpc::call('config', 'applyChanges', Array, Array, 2)\n#1 {main}"}}

    So I move those 'omv-rpc' calls either to Armbian's firstrun function or you might tell me how I could achieve the same by fiddling with config files (XML?) again?


    Wrt consumption numbers unfortunately I mixed two measurement setups: those numbers on Github in Armbian's documentation repo are without PSU (I used a Banana Pro as 'measuring PSU') and the XU4 numbers were done at the wall (so including the PSU which can make a huge difference). Let's not focus on that now, I already ordered another cable I need to measure XU4 consumption more reliable (and between PSU and board).


    To sum it up:

    • the above image should be fine but monitoring has to be disabled in the UI
    • I/we need a way to reliably disable monitoring at image creation time (or in firstrun function -- this is the next thing I'll test now)
  • The remaining issues are fixed with this commit: https://github.com/igorpecovni…b3e3aacdbddbbc64255db823b


    But they're not part of the last image so there still monitoring has to be disabled and the following done to fix the performance cron job:

    Code
    echo '* * * * * root for i in `pgrep "ftpd|nfsiod|smbd|afpd|cnid"` ; do ionice -c1 -p $i ; taskset -c -p 4-7 $i ; echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor ; done >/dev/null 2>&1' >/etc/cron.d/make_nas_processes_faster
  • Tested latest fixes and uploaded XU4 image again: http://kaiser-edv.de/tmp/NumpU8/


    Now waiting for some feedback for further tweaks since (at least my) final goal is to finalize settings and then simply add a simple 'OMV=next' entry to board's configs to let OMV images be built for all SBC that are worth the efforts (which are quite a lot if we also think about that XU4's Gigabit Ethernet is just an USB3 RTL8153 chip that can be added as dongle to USB2 ports too: https://forum.armbian.com/inde…findComment&comment=29569)

  • Thank you for the image.
    I've installed "OMV_3_0_71_Odroidxu4_4.9.23" image on my XU4 and it booted well and the automatic root file system resizing was fine.
    I can access OMV web UI on my laptop now and I will try some benchmark tests this weekend.


    BTW, how can I login to console or SSH?
    When I typed "root" on login:, it didn't ask password and just showed "Login incorrect".
    The serial console also doesn't allow my root login.
    Sorry for my very basic question. I'm a noob in this world.


    Edit: never mind.
    After reflashing the OS image, I can login on HDMI console as well as SSH.
    But serial console login doesn't work.
    I can do further test. :)

  • When I typed "root" on login:, it didn't ask password and just showed "Login incorrect".

    That's normally a sign for 'burning went wrong'. There's a reason Hardkernel provides an advanced burning tool (that does a verify): http://com.odroid.com/sigong/blog/blog_list.php?bid=144


    And there's a reason Armbian only recommends Etcher (that does a verify): https://docs.armbian.com/User-…#how-to-prepare-a-sd-card


    We recommend Etcher now since a year and have maybe 25% threads less complaining 'something is wrong'. Please reimage with Etcher and if it reports problems use either F3 or H2testw to check your SD card.

  • Quick test on CLI with a 3 years old ADATA 128GB SSD o the CloudShell2. I have no spare 3.5inch HDDs at this moment.

    The UASP works well out of the box. :)
    Samba performance is also quite impressive.


    Transfer from PC to XU4 (With 2.5inch 128GB SSD)


    Transfer from XU4 to PC (With 2.5inch 128GB SSD)



    Very nice performance even with a small 2.5inch HDD.


    Transfer from PC to XU4 (With 2.5inch WD 500GB HDD)


    Transfer from XU4 to PC (With 2.5inch WD 500GB HDD)





    One critical issue should be fixed. The XU4 cooling fan doesn't run at all after u-boot stage.
    So the CPU temperature goes up to 90C and it causes frequent thermal throttling.
    Something is wrong in thermal management in Kernel probably.

  • One critical issue should be fixed. The XU4 cooling fan doesn't run at all after u-boot stage.

    This is stuff that happens at kernel level. Armbian's build system uses this https://github.com/igorpecovni…es/odroidxu4.conf#L33-L34 so you should get in touch directly with Hardkernel guys (hint: there's a thread already over at https://forum.odroid.com/viewforum.php?f=146). OTOH there's nothing wrong with 90°C, those SoCs are made for tiny tablets/phones and fine to run even at 100°C. But in case you're concerned please discuss this over there in HK forum since it's possible to adjust fan behaviour through sysfs. In case HK comes up with a different strategy this will later be available through 'apt upgrade' (since Armbian packages kernel and device tree stuff as debs and puts them on apt.armbian.com)


    BTW: with your Windows Explorer test you neither tested your SSD nor your HDD but just Samba buffering to and reading from RAM (there's a reason why I recommend Helios LanTest with '10 GbE' setting but as usual no one cares :) )


    And you should still test your SD card. Trying to log in and getting "Login incorrect" means filesystem is read-only which is a clear indication for data corruption.

  • I've run Hardkernel's trial Ubuntu image with 4.9 kernel for several weeks but there was no fan cooling issue at all.
    So something could be wrong in your fan control sysfs values or drivers. But I am not sure.


    I've used the LanTest too. But the difference was less than 5~10% against the Windows Explorer. So I don't use it anymore.
    I think you might be interested in the IOPS benchmark. But most NAS users are not interested in small file access speed.


    As I mentioned in previous post, the login issue was gone after reflashing the OS image with DD tricks.
    I could verify the burned SD with original img file on DD command. Refer this nice guide.
    http://odroid.com/dokuwiki/dok…e_burned_image_with_linux



    Anyway, I've limited the max clock on A15 cores at 1.6Ghz instead of 2Ghz and the temperature decreased dramatically.
    I still have over 105MB/sec average Samba transfer speed. So I can live with this configuration. :)

  • The kernel has been built yesterday from sources so it's very likely that HK's 4.9 image from several weeks ago uses different settings. Just check this thread and commit log.


    From my perspective it's useless to continue here any more since I don't get the information I would need to further improve things. And instead of time consuming and stupid md5 games I prefer to use tools that are made with verify in mind (Etcher sometimes detects that something's wrong even at flashing stage and stops right there so you'll save a lot of time)


    @ryecoaaron: I'll update images over at http://kaiser-edv.de/tmp/NumpU8/ within the next days.


    Wrt Etcher: GUI and CLI.

    • Offizieller Beitrag

    From my perspective it's useless to continue here any more since I don't get the information I would need to further improve things.

    What am I missing? I thought I was giving you information?


    I'll update images over at kaiser-edv.de/tmp/NumpU8/ within the next days.

    I will try them tomorrow. 16 hour day at work today.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | 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!

  • Sorry, I was talking about getting useless feedback like those Windows Explorer screenshots testing nothing (since if you copy one large file that fits in RAM to board and back it's just a waste of time since everything that needs attention will not be tested. This is more or less a 'network throughput' test leaving out everything that needs further tweaks).


    I'm talking about stuff like this: https://forum.armbian.com/inde…findComment&comment=29993


    It's all about process/CPU/IRQ affinity tweaking on those small ARM boards and especially on the XU4 the big.LITTLE/HMP situation gets interesting. And Windows Explorer doesn't tell anything, while 5 (unattended) LanTest runs that also show result variation (that's the orange triangles) tell you directly where to look into next. Just compare min/max values (orange triangles) in the referenced post that indicate in this specific situation that there must be an IRQ collission which bottlenecks overall write throughput.


    On ODROID-XU4 it's different since both Ethernet and storage able to use SuperSpeed but for further tweaking it seems I have to rely on own tests (already scheduled with a customer who set up 2 Win10 VMs so I can test in 2 weeks also concurrent access)

    • Offizieller Beitrag

    I was talking about getting useless feedback like those Windows Explorer screenshots testing nothing

    I'm glad I wasted my time creating them then. Pretty sure the 30GB file I was copying doesn't fit in ram.


    it seems I have to rely on own tests

    Welcome to my world. I ask for help and get none. I supply help and people complain it isn't good enough.


    I don't see why these are so much more helpful but here they are...

  • Thank you for the numbers/screenshots. The problem with Explorer (or macOS Finder) numbers is that they're compensating for bad settings with parallelism. So if one is interested in improving performance (applies to me here) they're worthless especially when done like odroidq did it (with file sizes way too low). Sorry for not being more precise.


    Anyway: I'm going to test this myself in 2 weeks and no further feedback is needed atm. :)


    The OS images at http://kaiser-edv.de/tmp/NumpU8/ are ready for redistribution even if I plan some further tweaks in a few weeks (but all those are either part of kernel package or 'board support package' so they're just an 'apt upgrade' away in a few weeks).


    On a related note: My main motivation for enabling Armbian's build system to create 'virgin' OMV images was the ESPRESSOBin: https://forum.armbian.com/inde…findComment&comment=30111 (in other words: we're all able to push out an optimized OMV image for ESPRESSOBin in a few days without even having the board here :) )

  • Subscribed to this topic. Please keep us updated on your efforts.

    Riddle me this, riddle me that
    Who is afraid of the big, black bat?
    I write on a blog (Romanian mostly)
    Testing (latest) OMV 6.x (HURRAY) on an Intel i5820K NAS (currently with proxmox kernel 6.2)

  • I'm finished for now since the general issues are resolved (use individual cpufreq/governor settings per board, minimize writes to SD cards or eMMC, general performance tweaks) and for a couple of interesting OMV targets it's better to wait a few weeks/months for mainline kernel situation to stabilize.


    Current status:


    Stable:

    • Allwinner A20/GbE boards (Banana Pi/Pro/M1+, Cubietruck, Lime2, pcDuino3/Nano): performance tweaks finished, stable support
    • ODROID-XU4: performance tweaks finished, stable support
    • ODROID-C2: performance tweaks finished, stable support (though in a few months switch to mainline kernel will happen)
    • ODROID-C1: performance tweaks finished, stable support (though kernel 3.10 EOL in half a year)
    • Pine64: performance tweaks finished, stable support (though in a few months switch to mainline kernel will happen)

    Unstable/experimental:

    • Clearfog (Armada 38x): performance tweaks finished, low performance with kernel 4.4, superiour performance with 4.10 but DSA (switch) broken, most likely resolved few weeks after 4.11 release
    • OrangePi Zero (Allwinner H3): performance tweaks finished, kernel situation WiP, not ready for productive use
    • NanoPi NEO 2 (Allwinner H5): performance untested, kernel situation WiP, not ready for productive use
    • Tinkerboard (Rockchip RK3288): performance untested, kernel situation WiP, somewhat stable since Armbian's kernel config takes care of OMV requirements
    • ESPRESSOBin (Armada 3700): performance untested, kernel situation WiP, not ready for productive use

    In case GlobalScale sends out an ESPRESSOBin dev sample I'll rather soon finish Armada 3700 support but all those cheap Allwinner H3 or H5 Gigabit equipped boards have to wait a few weeks/months until mainline kernel situation gets more stable and same applies to Pine64 too but here situation with legacy kernel is also sufficient so why not running those boards on kernel 3.10 until EOL in September and then switching to mainline?


    Besides that everyone can now build his own OMV images for ARM devices supported by Armbian: that means those +50 currently listed here https://www.armbian.com/download/ (and maybe 10 more we're working on at the moment). Requirements/procedure outlined in our documentation: https://docs.armbian.com/Developer-Guide_Build-Preparation/


    While making progress with OMV support we were able to fix/improve a lot of stuff in Armbian's build system and maybe in one case my try to improve settings led even to a hardware fix: I poked FriendlyELEC's kernel dev to forget about crappy Allwinner BSP kernel (3.10.65) and rely on mainline kernel. They then realized that with mainline kernel stuff works that fails with Allwinner's BSP: voltage regulation on H5 boards. As a result of our conversation FriendlyELEC decided to improve PCB of their latest 'NanoPi M1 Plus 2' to be able to let the H5 SoC clock higher due to better voltage regulation. Nice move :)


    BTW: I'll remove the OS images listed at http://kaiser-edv.de/tmp/NumpU8/ in a few weeks so maybe OMV admins here consider mirroring those labeled as stable on Sourceforge or somewhere else in the meantime?

    • Offizieller Beitrag

    I'll remove the OS images listed at kaiser-edv.de/tmp/NumpU8/ in a few weeks so maybe OMV admins here consider mirroring those labeled as stable on Sourceforge or somewhere else in the meantime?

    I will mirror them on sourceforge.


    I probably know the answer to this question but it would be nice if all of the OMV arm images were created the same way. I'm guessing the build process does not work for the RPi2/3?

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | 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!

  • I will mirror them on sourceforge.

    Great. I'll get back to this thread if there's something new (hoping for ESPRESSOBin soon since this thingie will be available in 2 weeks on Amazon US for $50 and easily outperform all the other ARM boards except the more expensive Marvell boards).


    Regarding Raspberries. In fact it's quite easy to add support for RPi 2 and 3 to Armbian's build system but in my personal opinion we should never provide official images for Raspberries (since then Armbian project would be dead due to useless amount of support questions). I'm actually playing around with this stuff and am running an Armbian userland on my RPi 3.


    Your idea is worth a consideration but it will take some time since I'll wait for Stretch becoming stable (any estimates when OMV will be released for Stretch?). And then some prerequisits must fit, eg. we need the ability to query Raspberries mythical firmware for under-voltage situations to warn users. Just as a reference: https://github.com/bamarni/pi6…/4#issuecomment-292707581 (the linked thread to Pete Scargill is maybe worth a read too).


    So let's talk about this in a few months again. For me a high priority is getting kernel fixes from a repository so in case no '3rd party' manages to set something up with mainline kernel for Raspberries then we'll have to rely on RPi Foundation's repo for kernels (which is fine since stuff like 'Dirty COW' got fixed pretty fast). And on RPi with the limited USB2 situation it's almost useless to think about a 64-bit kernel since the bottleneck is always USB and a 32-bit userland has at least the slight advantage that more DRAM is available. We'll see :)

    • Offizieller Beitrag

    I only bring up the RPi because there are a lot of people on this forum using them (2200 downloads per week if you look at sourceforge numbers). Doesn't bother me if it is supported but it would be one less image for me to maintain.


    any estimates when OMV will be released for Stretch?

    Stretch isn't released yet and OMV 3.x isn't even truly released yet. OMV 4 is on github and works on stretch but not ready. No idea when it will be released though.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | 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!

  • 2200 downloads per week for RPi 2 and 3 is close to insane especially since those Raspberries have serious architectural flaws and are outperformed by even the cheapest H3/H5 SBC (Orange Pi PC/One/Zero or the various NanoPis): http://linux-sunxi.org/Sunxi_d…e_not_blocking_each_other :)


    Anyway: I'll look into Raspberries in a few weeks again but can't promise anything (there's neither much to explore nor to learn but I'll keep the OMV use case in mind to justify spending some more time on Raspberries)

Jetzt mitmachen!

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