Building OMV automatically for a bunch of different ARM dev boards

  • What would be the best solution theoretical (Stability, speed etc.) is it a SSD?

    While an SSD is probably the fastest, it really doesn't affect the services since the data is on the data drive. The OS drive doesn't affect much other than web interface speed and even then, it is barely noticeable.

    omv 5.5.13 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.4.2 plugins source code and issue tracker - github

    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • Bought a 16GB Sandisk Ultra Class 10 microSD card.

    Used etcher on my MacBook to flash the omv-install IMG. Took a couple of minutes. Mounted it on the XU4 microSD slot, power on. And in less than a minute, it was up running. :)

  • Used etcher on my MacBook to flash the omv-install IMG. Took a couple of minutes. Mounted it on the XU4 microSD slot, power on. And in less than a minute, it was up running

    Those are the stories I like to hear/read :)

    omv 5.5.13 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.4.2 plugins source code and issue tracker - github

    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • Thanks to the supplier for assuring me that, i could install newest OMW image to emmc... might not be aware that there are now OS images for XU3/XU4 that make use of mainline kernel or a single partition scheme. With this OMV image when you want to continue using a 'crappy' SD card you could also install the system on a connected disk (run nand-sata-install), then only the bootloader on the SD card will be used and OS is on disk (I wouldn't do this with a HDD since your disk might never be able to spindown for longer periods of inactivity). An alternative is to buy a good SD card showing high random IO (not really a requirement with OMV though since using flashmemory plugin). But the price difference between good and bad SD cards is non existent so better choose good ones:…/954-sd-card-performance/

    The eMMC installation bug came to my attention just recently, you can follow progress here:…71#issuecomment-300119592

  • I could activate the LCD display on CloudShell2 after following simple six commands on OMV SSH shell.
    After installing four packages and rebooted without HDMI cable connection.

    apt-get install curl sysstat i2c-tools
    dpkg -i odroid-cloudshell
    dpkg -i cloudshell-lcd
    dpkg -i cloudshell2-fan

    I can monitor my OMV NAS status without connection now :)

    But I found a critical issue. Little Cores are running at 1.3Ghz instead of 1.4Ghz. Big Cores max freq is 1.8Ghz instead of 2Ghz.

    Hardkernel's Ubuntu image runs at 1.4Ghz & 2.0Ghz correctly.
    Something is wrong in Armbian or OMV image.
    Did you lower the max clocks intentionally to lower the power consumption?
    I need slightly more computing power for TVheadend realtime transcoding.

  • Something is wrong in Armbian or OMV image.

    Well, please keep in mind that this is still WiP. On my list regarding ODROID XU4 are the following things:

    • add 'odroid-cloudshell cloudshell-lcd cloudshell2-fan' to default package list (is there a trustworthy PPA available? The above? Using wget when URLs might change anytime due to different version numbers seems not the way to go)
    • Resolve UAS problems (though I fear that there won't happen that much since Hardkernel seem to care more about customer satisfaction and not trying to rule out potential problems with XU3/XU4 USB host controller which might need additional quirks). On the bright side: if you're not using a Seagate USB3 product chances are pretty low that you're affected
    • eMMC installation problem (though I've no idea how to fix this from our side currently)

    maximum cpufreq settings are part of device tree definition and eg. the 1.4GHz possible with little cores have been added just 4 days ago:…4394667b1ca3e5534b12af5b6

    These changes come with an update within the next weeks, if you're impatient you need to grab new .dts from the link above and use dtc to convert it to .dtb living below /boot/dtb/ (needs package 'device-tree-compiler'). And I believe you need to adjust /etc/defaults/cpufrequtils too -- can't test since my XU4 is away currently). Feedback welcomed!

  • Thank you for quick answers.
    I got the packages link from Hardkernel wiki page. I don't have any ppa idea.

    I'm very satisfied with CloudShell2 UASP support as well as neat small TFT LCD.
    SSD performance is near 320MB/sec.
    HDD performance is near 200MB/sec.

    The ext4load command in u-boot seems to be available in the recent updates.…ommits/odroidxu3-v2012.07…012.07/sd_fuse/hardkernel

    I will try to learn how to compile the dts to dtb this weekend.
    I hope I can have 2Ghz of big cores.

    Edit: Please consider changing the compression option to xz or gz like other OMV images..
    I had to uncompress it before using Etcher.

  • I don't have any ppa idea.

    You could help testing it:…t=26016&start=150#p189924 (just do an 'apt purge' for the three packages before). If this works future upgrades are available through 'apt upgrade' since this is IMO the only way to add this.

    Wrt 2GHz I think it should be sufficient to simply edit /etc/defaults/cpufrequtils already but in case you're willing to make a backup of your installation you could help testing here too (me currently having no XU4 around): please grab latest kernel/DT stuff from here: odroidxu4_5.27_4.9.27.tgz

    Then do a 'tar xf', 'dpkg -i' and a reboot. Should include latest fixes for DT (the 1.4GHz on little cores) and a slight overall speed improvement since we followed upstream kernel config yesterday.

    We already discussed moving to .xz internally but postponed it for now. And at least on macOS Etcher gets dog slow when dealing with .xz directly. Since I'm impatient I use only SD cards able to exceed 80MB/s (both read/write) for those SBC not able to use FEL boot. With .xz both write and verify happen with just a few MB/s so manually uncompress first and then etcher the image is magnitudes faster for me. Did you observe the same?

    The eMMC issue is unfortunately a bit more complex since updates to Hardkernel's u-boot branch would require an already installed image on eMMC to be able to update u-boot there. But I think we're able to resolve that too within the next weeks.

  • If someone can point me to the source code, I could put the three packages in the omv-extras repo.

    Well, according to this is still WiP: '57 updates added during the past month' so it might be the best idea to use this PPA at least in the beginning.

    And since this is only useful for Cloudshell 2 users it might be a good idea to detect this device (after installation of i2c-tools one can use i2cdetect to get an idea). But since I don't have the device and also no access to XU4 these days anyway I can't come up with a detection routine though provided i2cdetect output should already be sufficient.

  • @tkaiser
    After installing your kernel update packages, the little core clock is correct now. But the big cores is stilling running at 1.8Ghz not 2.0Ghz even in performance governor.
    When can you access your XU4? It is not easy to debug for me.

    Purging/reinstalling those three packages had no negative side effect on my side.

  • A few more questions.

    <1> When I restart or reboot the OMV, I had to mount the storages with web admin GUI every time.
    I reflashed OS image again, I still have the same issue.
    Is it a CloudShell2 issue? Anybody can reproduce the issue with CloudShell2?

    <2> Why big-core cluster governor is "ondemand" while little-core cluster is "performance"?
    Did you make it intentionally?

    root@odroidxu4:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
    root@odroidxu4:~# cat /sys/devices/system/cpu/cpu4/cpufreq/scaling_governor

    <3> IRQ affinity setting seems to be wrong and it slows the SATA and Ethernet performance.

    root@odroidxu4:~# cat /proc/interrupts
    144: 1414 0 16461 0 0 0 0 0 GIC-0 104 Edge xhci-hcd:usb3
    145: 471 0 0 34113 0 0 0 0 GIC-0 105 Edge xhci-hcd:usb5
    root@odroidxu4:~# cat /proc/irq/144/smp_affinity
    root@odroidxu4:~# cat /proc/irq/145/smp_affinity

    Two IRQ handlers should be assigned to big cores. I will do more tests when I have time.

    Sorry for too many complains.

  • Every booting time, I needed to wait around 2~5 minutes for ssh connection.
    I connected a serial console and captured this screen.
    How to remove this situation? Previous omv_xu3_xu4_3.0.65.img had no such issue at all.
    I will install Hardkernel Kernel 4.9.27 on the old OMV image and let you know the result.

  • Why big-core cluster governor is "ondemand" while little-core cluster is "performance"?

    Intentionally, same with IRQ affinity: all on the little cores while pushing the NAS daemons to the big cores since best performance and IRQs not bottlenecked by CPU on the little cores. Also consumption difference between ondemand and performance on the little cores is negligible while real world performance benefits from running the A7 cores with performance governor. I spent a few hours on optimizing this so in case you come up with 'complaints' be prepared that they get ignored unless you provide numbers (performance and consumption, backed by analyzing CPU core utilization and all the other necessary stuff)

    Wrt 2.0 GHz please check /etc/defaults/cpufrequtils as already suggested.

    No idea about the rest of the issues, currently further working on/with XU4 is discouraging anyway: no one helps detecting existence of Cloudshells through I2C and testing adding the Cloudshell 2 PPA as outlined above or over there:…t=26016&start=150#p189924

    I won't waste more money for sure on getting these Cloudshell thingies (which I consider pretty lame anyway), buying the XU4 was already a mistake.

  • Thank you for the explanation. Sorry for my misunderstanding about the /etc/defaults/cpufrequtils file.
    I could change the governor and max_freq for the A15 cores by editing the file.
    Now I have slightly higher CIFS throughput at 112~113MB/sec than previous 104~105MB/sec.
    Really appreciate your help. I will try realtime transcoding too.

    I saw @ryecoaaron already assembled his CloudShell2 in this thread.
    I think he is too busy and he had no time time to reply on your questions.
    I hope he can reproduce the other issues I reported.
    The most annoying thing is that I must manually mount the disks every reboots.

    I will try to learn how to identify the CloudShell via i2c scanning.
    But it may take time to know about "i2cdetect" command.
    Thank you for your patience.

  • I saw @ryecoaaron already assembled his CloudShell2 in this thread.
    I think he is too busy and he had no time time to reply on your questions.

    Well, I asked in ODROID forum for a reason since this is something Hardkernel guys could/should provide. They know their hardware, it's easy for them to come up with a I2C detection routine and they could also elaborate on whether this PPA can/should be trusted or not so that all the stuff necessary for both Cloudshell variants can be set up automagically without users having to fiddle around manually.

    @ryecoaaron does a great job here and I don't expect him wasting time with stuff the hardware vendor should take care of :)

  • i2cdetect command was very simpler than my guess.

    root@odroidxu4:~# i2cdetect -y 1
    0 1 2 3 4 5 6 7 8 9 a b c d e f
    00: -- -- -- -- -- -- -- -- -- -- -- -- --
    10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    60: 60 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    70: -- -- -- -- -- -- -- --

    The fan controller IC address is 0x60 as described in their schematics.…:xu4_cloudshell2#hardware

    Do you need a script to check the existence of CouldShell?

  • Please see commits from today:

    New image: OMV_3_0_75_Odroidxu4_4.9.27.7z

    If it works then great, if not then... sorry. I'm currently too busy and also slightly disappointed by upstream ignorance.

    Changes: kernel 4.9.27 with latest fixes, 2GHz possible, slightly higher overall performance, kyle1117 PPA integrated as repo (might work), if Cloudshell 2 is connected at first boot then the LCD service gets installed (might need a reboot -- due to lack of feedback that's up to those persons who sell/support this Cloudshell, it's easy to add necessary stuff to package postinstall scripts)

    TODO (not mine since I lost interest): Fixing eMMC and UAS issues. Maybe Hardkernel folks change their priorities and start to investigate into potential XU4 USB3 hostcontroller issues (but most probably they're only interested in customer satisfaction, tell their customers there wouldn't be a difference between UAS and the older/inefficient Mass Storage mode with HDDs -- not true by the way -- and try to blacklist everything that's not JMS567/561 as used on their Cloudshell)

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!