Building OMV automatically for a bunch of different ARM dev boards

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • I just found out there is a 4.14 kernel from HardKernel. Will the new version come in an update or a fresh install will be needed? I am using a XU4 with OMV 3.x, running kernel 4.9.x. Some kernel updates have come as an update.
      Riddle me this, riddle me that
      Who is afraid of the big, black bat?
      I write on a blog (Romanian mostly)
      Testing (latest) OMV 4.x on an oDroid XU4 (currently with kernel 4.14.x)
    • tmihai20 wrote:

      I just found out there is a 4.14 kernel from HardKernel. Will the new version come in an update or a fresh install will be needed?
      Via an update of course. But currently IMO there's a lot wrong with Armbian and reliability. The last attempt to switch to 4.14 led to bricked boards due to 'processes' that make no sense at all (rolling out updates without communicating and no sufficient testing):
    • tkaiser wrote:

      tmihai20 wrote:

      I just found out there is a 4.14 kernel from HardKernel. Will the new version come in an update or a fresh install will be needed?
      Via an update of course. But currently IMO there's a lot wrong with Armbian and reliability. The last attempt to switch to 4.14 led to bricked boards due to 'processes' that make no sense at all (rolling out updates without communicating and no sufficient testing):

      Oh, that is really, really bad :( I really, really do not want to redo the installation or start debugging it like that. Will you guys (OMV team) ditch Armbian as the base you build OMV from? I know that 4.14 is working on the Ubuntu images that HardKernel is using for their kernels.

      Edit: Sorry about the consecutive posts. The forum threw an error and it did not say that the post actually went. Delete my other posts.
      Riddle me this, riddle me that
      Who is afraid of the big, black bat?
      I write on a blog (Romanian mostly)
      Testing (latest) OMV 4.x on an oDroid XU4 (currently with kernel 4.14.x)
    • Your post on July 15 has a list of official images - notices RaspberryPi is not listed but is on Sourceforge - I too am unable to boot from image without the ttyS1.device error.

      The latest version available is producing the same error on various SD cards and on two different RPi 3

      Are you recommending the same fix as the ttyS0 just replacing with 1

      ?
    • Hello @tkaiser

      thank's a lot for this very nice flavor. I'm running it on a Orange Pi PC 2 since months without problems. Recently a Odroid HC1 went live and is working nicely.

      I just figured out one thing. Under "Diagnostics -> System Information -> Performance" none of the graphs is working. It's kind of a luxury but a nice one. The graphs should be created by rrd (in detail with rrd.php).

      The output right now is this on both boards (maybe on all arm flavors from omv?)

      [IMG:http://imgur.com/vNzZjPql.png]

      Is it a bug or a feature? :P
      "This post will remain inaccessible for others until approved by a censor." - George Orwell X/
    • You have to enable monitor data collection in the system menu.
      Absolutely no support through PM!

      I must not fear.
      Fear is the mind-killer.
      Fear is the little-death that brings total obliteration.
      I will face my fear.
      I will permit it to pass over me and through me.
      And when it has gone past I will turn the inner eye to see its path.
      Where the fear has gone there will be nothing.
      Only I will remain.

      Litany against fear by Bene Gesserit
    • Wasn wrote:

      I just figured out one thing. Under "Diagnostics -> System Information -> Performance" none of the graphs is working. ... Is it a bug or a feature?
      It's a feature since you're running off an SD card that gets destroyed pretty fast when the RRD databases are constantly updated. The problem is called 'write amplification' and I tried to collect everything important around SD cards here (check especially the links at the top): forum.armbian.com/topic/954-sd-card-performance/
    • Little 2018 'Single board computer storage performance' update: forum.armbian.com/topic/1925-s…ab=comments#comment-51350

      Especially RK3399 as on upcoming ODROID N1 for example is covered there and some impressive but rather irrelevant numbers made with an ARM board and a fast NVMe SSD: Up to 1600 MB/s with RK3399 without any tuning (and even wrong PCIe link state power management settings).

      Maybe I'll add soon also EspressoBin performance numbers for 'native SATA', USB3 and PCIe attached SATA. But since recently another interesting guy arrived -- see below -- I might play with PineH64 first:
      [IMG:http://linux-sunxi.org/images/thumb/c/ca/PineH64_3.jpg/800px-PineH64_3.jpg]
    • votdev wrote:

      You have to enable monitor data collection in the system menu.

      tkaiser wrote:


      Wasn wrote:

      I just figured out one thing. Under "Diagnostics -> System Information -> Performance" none of the graphs is working. ... Is it a bug or a feature?
      It's a feature since you're running off an SD card that gets destroyed pretty fast when the RRD databases are constantly updated. The problem is called 'write amplification' and I tried to collect everything important around SD cards here (check especially the links at the top): forum.armbian.com/topic/954-sd-card-performance/

      Very valid point that's disabled. Thank's for the link.


      Is there any chance to change the data collection target - so that I collect the numbers but write the RRD database to a attached SSD rather than the microSD?
      "This post will remain inaccessible for others until approved by a censor." - George Orwell X/
    • tkaiser wrote:

      Wasn wrote:

      Is there any chance to change the data collection target
      If it's not configurable then you might want to use symlinks. Stop OMV services, then move the directory containing the databases to the SSD and then set a symbolic link using 'ln -s' from SSD to original location.

      I spend the last to days a couple of hours finding out where the heck the data stored. As I found out the "default" target of rrd is changed in openmediavault and as well the technique to collect these data (collectd if I'm right?).

      The closest I came is this here: github.com/openmediavault/open…diavault/mkconf/rrdcached

      Where for me (I don't have any coding skills so please correct me if I'm wrong) this one here would be of importance:

      openmediavault wrote:

      # Where database files are placed. If left unset, the default /tmp will
      # be used. NB: The daemon will reject a directory that has symlinks as
      # components. NB: You may want to have -B in BASE_OPTS.
      BASE_PATH=${OMV_RRDCACHED_BASEDIR}

      # Where journal files are placed. If left unset, journaling will
      # be disabled.
      JOURNAL_PATH=${OMV_RRDCACHED_JOURNALDIR}

      I'm still not sure where the data is finally written and if it's possible to use the possibility of symlinks for changing the drive?
      Any help on this is highly appreciated! Thank's! ;)
      "This post will remain inaccessible for others until approved by a censor." - George Orwell X/
    • It was November 2017:

      tkaiser wrote:

      But it's almost 2018 now and USB2 only SBC aren't that great anymore anyway (look at ROCK64, ODROID-HC1 or EspressoBin for example to get the idea how performant inexpensive ARM NAS implementations can be these days)
      It is now April 2018 and ODROID-HC2 is available. I thought I'll buy ROCK64, but I found searching web to clarify that ROCK64 is the one I need, then I found ODROID-HC2.
      Because I need to plug one 3.5" HDD and run OMV on it, both boards are good choice.

      From my noobs perspective it seems that ROCK64 has USB3 and HDMI, therefore there is possibility to change of purpose in future if needed. Where ODROID-HC2 is more compact solution for NAS purpose only.

      But this might decide which board, because HDD will be Luks Encrypted. I googled that ROCK64 has ARMv8 Cryptography Extensions... I don't understand exactly if eater boards has AES hardware support and if it is being used today successfully, so I can benefit of it using OMV.
      Can you enlighten it a bit more for me and help me to chose, please?
    • houndhunger wrote:

      I googled that ROCK64 has ARMv8 Cryptography Extensions... I don't understand exactly if eater boards has AES hardware support and if it is being used today successfully, so I can benefit of it using OMV.
      Currently only ARMv8 Crypto Extensions will be used automagically. The Exynos 5244 on HC2 has also crypto support: wiki.odroid.com/odroid-xu4/software/disk_encryption -- but this needs kernel 4.14 (not available with OMV/Armbian yet unless you switch the branch with armbian-config) and some tweaking as outlined in the wiki.

      So Rock64 might be the better idea but you should keep in mind that USB3 connectivity problems happen from time to time and that it's highly recommended to also order the Rock64 SATA cable (and their PSU too of course!)
    • Really? it has been out for an hour. Obviously, the arm images wont stop. OMV 3.x is eol but the underlying OS is still supported by Debian/armbian. you dont have to upgrade asap.
      omv 4.1.15 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      OMV 3.x is eol but the underlying OS is still supported by Debian/armbian. you dont have to upgrade asap.
      Then there's sudo omv-release-upgrade which worked for me flawlessly within the last 6 months already. I just wonder whether we should add a minor tweak to omv-release-upgrade:

      Source Code

      1. [[ -f /etc/apt/sources.list.d/armbian.list ]] && sed -i 's/jessie/stretch/' /etc/apt/sources.list.d/armbian.list
    • tkaiser wrote:

      I just wonder whether we should add a minor tweak to
      I added it to the run parts directory that omv-release-upgrade calls - github.com/OpenMediaVault-Plug…8a8bff19c5172db6c6b90f7e1
      omv 4.1.15 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • Alexio wrote:

      How can this 'minor tweak' be implemented if already updated to OMV4?
      I guess I could have omv-extras maintain that file but going forward, you shouldn't need to. Just run the following command as root:
      sed -i "s/jessie/stretch/g" /etc/apt/sources.list.d/armbian.list
      omv 4.1.15 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      Really? it has been out for an hour. Obviously, the arm images wont stop. OMV 3.x is eol but the underlying OS is still supported by Debian/armbian. you dont have to upgrade asap.
      I thought OMV 4.x was out for a longer time and that some other OMV4.x arm images would be available. I am not requesting images at all. I am also not very eager to update. I like the fact that it has better mobile interface support. I am using an alternate Android app to do maintenance when I cannot use ssh.
      Riddle me this, riddle me that
      Who is afraid of the big, black bat?
      I write on a blog (Romanian mostly)
      Testing (latest) OMV 4.x on an oDroid XU4 (currently with kernel 4.14.x)
    • Users Online 3

      3 Guests