Building OMV automatically for a bunch of different ARM dev boards

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.

Zitat von tkaiser

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):

• https://forum.openmediavault.org/index.php/Thread/21575
• https://forum.armbian.com/topi…findComment&comment=48200

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.

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?)

Is it a bug or a feature?

Zitat von votdev

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

Zitat von tkaiser

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): https://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?

Zitat von tkaiser

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: https://github.com/openmediava…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:

Zitat von openmediavault

# 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}

Alles anzeigen

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!

It was November 2017:

Zitat von tkaiser

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?

I just read that OMV 4.x is out and that OMV 3.x is EOL. I did not see any new images besides the ISOs for PCs. Will there be builds for oDroid and other arm boards?

How can this 'minor tweak' be implemented if already updated to OMV4?
_{(already looked in /etc/apt/sources.list.d/armbian.list, but couldn't make any soup of it)}

Zitat von ryecoaaron

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.