Important: the final result of this full thread (highly optimized OMV images for ARM boards) can be found here: https://sourceforge.net/projec…s/Other%20armhf%20images/
Apologies for probably asking in the wrong place but I didn't find a developer sub forum here.
Purpose of this post is asking for support to get OMV built in a fully automated way for ~50 different single board computers. I know that for many SBC already OMV OS images exist but either hardware is not sufficient (eg. Raspberries with their slow Fast Ethernet and limited USB bandwidth) or the quality of the images is questionable (someone used the OS image he found somewhere on the net, installed OMV inside, didn't care about kernel/settings and pushed it out... so the result is neither fast nor trustworthy).
We (Armbian team) thought let's change this since we implemented a scripted build system to create Debian/Ubuntu based OS images fully automated from scratch currently supporting +50 devices: https://www.armbian.com/download/
Getting OMV built automagically wasn't that hard: adjusting kernel configs to meet OMV requirements as first step and adding a customization routine that gets called at the end of image creation and adding OMV unattended to freshly created OS images. Still WiP latest attempt looks like this (executed on a x64 build host in a chrooted ARM environment): https://github.com/igorpecovni…mage.sh.template#L31-L126
My problems currently with implementing this are
- I wonder how I can influence/prevent overwriting of /etc/defaults/cpufrequtils -- OMV's default settings are counterproductive on armhf and arm64 since most kernels we're dealing with here perform badly with 'conservative' cpufreq governor
- some of those small ARM boards with fast Gigabit Ethernet but only slow storage (USB2 or SDIO 2.0) would benefit a lot from compress=lzo as btrfs mount option (and of course noatime,nodiratime). I found ways to specify that globally but the problem here is that a lot of ARM devices are supported by more than one kernel flavour (eg. a smelly 3.4 kernel with multimedia features and latest and greatest mainline kernel). I would consider using btrfs these days with something lower than 4.4 dangerous, so the question is: are btrfs options accessible or can btrfs be 'hidden' when old kernels are used (I would assume no, so we have to fix this in the build system and check kernel variant at build time)
I'll stop now and wait for feedback since maybe this is the wrong place to discuss this anyway? Progress can be monitored here: https://forum.armbian.com/inde…ges-for-sbc-with-armbian/
Kudos for all your great work. Tried really hard to destroy my various OMV builds the last two days but to no avail. Even mean CLI modifications got absorbed by OMV and performance is also not bad on those small gems (though a little tuning on ARM boards could improve performance significantly)