Building OMV automatically for a bunch of different ARM dev boards

Zitat von ryecoaaron

Uploading the new image now

Thank you!

BTW: I installed the cloudshell-lcd service more or less by accident (simulating a connected Cloudshell 2) and just noticed that my XU4 got noisy (in a cabinet so I didn't take notice earlier). The fan starts every few seconds. Reason: the amazingly inefficient /bin/cloudshell-lcd script. This keeps the A15 cores up at 2.0 GHz all the time, prevents the CPU cores entering power saving states and led to 'idle' temperature increasing by a whopping 8°C.

I don't know why it's necessary to check every single second the temperature of connected disks (preventing them to spin-down) or the kernel version or whether the distro is Debian or Ubuntu or even the hostname (WTF?). Until this gets fixed the best you could do with this script is a

systemctl disable cloudshell-lcd

(fortunately this is only installed on XU4 with Cloudshell 2 connected)

Zitat von ryecoaaron

The ads7846 module consumes a full cpu even with cloudshell-lcd disabled

That's really bad (fortunately my XU4 is not affected since no such display connected). Maybe it helps to adjust /proc/irq/147/smp_affinity so only the little cores are kept busy doing nothing?

In the meantime I realized that the 'package' odroid-cloudshell just adds one single file to the installation:

root@odroidxu4:~# cat /etc/modprobe.d/odroid-cloudshell.conf 
options fbtft_device name=hktft9340 busnum=1 rotate=270 speed=35000000

And cloudshell-lcd is just the ressource hungry script + service definition (lacking taskset prefix to keep this stuff on the little cores) while cloudshell2-fan 'package' is more or less just a wrapper around one i2cset call. I'm somewhat confused...

Anyway: Installation of odroid-cloudshell package by default is wrong but I won't change it any more since affected users (using other SPI displays with their XU4) should be familiar enough with diagnosing/fixing module calling options. And I really hope that cloudshell-lcd script gets fixed soon upstream by @kyle1117 so an update will fix affected Cloudshell 2 installations.

Zitat von nasnas

Just adding "ads7846" into /etc/modprobe.d/blacklist-odroid.conf solved the issue.

@kyle1117 can you please add this to the odroid-cloudshell package? I won't touch anything XU4 related for the next time (already wasted too much time with board and Cloudshell gimmick) and maybe forever (will soon get a Rock64 dev sample with 4 GB DRAM, USB3 and native Gigabit Ethernet so if performance there looks promising and RK3328's USB3 IP doesn't show problems there's no reason to look back at XU4 anyway)

BTW: I call Cloudshell a gimmick since the advertised LCD feature is obviously 'monitoring'. But monitoring 'solutions' that affect the behaviour of the system so badly (keeping one CPU core busy with a useless touch display driver if Cloudshell is connected and keeping the A15 cores all the time at 2000 MHz due to an insanely high load caused by the /bin/cloudshell-lcd script) are counterproductive. Monitoring that completely changes the system's behaviour is... just weird to remain polite.

Zitat von nasnas

Is there any benchmark result of the RK3328 USB 3.0?

Nothing available yet. By looking into https://github.com/rockchip-li…nel/tree/release-4.4-3328 it seems same Synopsys Designware USB3 IP is used as in Exynos so maybe similar problems. It's way too early for any numbers but since Rockchip does a pretty good job in the meantime pushing their code also upstream I'm rather confident that this board won't suck (also RGMII attached Gigabit Ethernet instead of USB3 attached as on XU4 is an advantage and I hope there's no internal USB3 hub on the board).

Due to the generic OMV creation routine added to Armbian's build system at least it's ensured that as soon as there's community Linux support somewhat stable for new devices an OMV image with good settings can be created automagically from scratch (that was also my main motivation to be prepared for Marvell EspressoBin now and both Rock64 and Allwinner H6 boards later)

Zitat von nasnas

EspressoBin seems to have only one SATA port unfortunately. We might need to plug an add-on board into the PCIe slot to attach more HDDs.

Sure, you can add 2 or even 4 SATA ports via mPCIe there (details and also performance numbers). Armada 3720 is AFAIK connected with 2.5GbE to the internal Topaz switch so if set up correctly accumulated throughput with this board when using 3 GbE clients in parallel will be above 260 MB/s (to be confirmed, unfortunately none of the EspressoBin users I know come back with test results, they all seem to use their boards already productive)

The older Cortex-A9 based Armada 38x are known to both saturate a 2.5GbE line (search Solid-Run forum) and 3 x SATA 3 in parallel (over 1500 MB/s with 3 fast SSD). Since Marvell re-used the respective engines on 3720 this shouldn't change that much (please keep in mind that those Marvell SoCs are designed for exactly this use case: NAS and routers unlike the tablet, TV box or smartphone SoCs you find on all the normal SBC)

Even more important: you get NAS grade and not toy grade hardware with Marvell SoCs and can avoid USB for storage entirely (no hassles with crappy cables/connectors as on some USB3 equipped SBC or crappy firmware in USB-to-SATA bridges) but should keep in mind that internal SATA connectors are rated/specified for 50 matings max (and that cheap SATA cables are always 'great' to introduce troubles, that's why you always immediately check SMART attribute 199 after attaching any SATA connector/cable while running an initial iozone/fio benchmark)

Edit: I already mentioned the 'ARM based NAS board overview' in this thread but it seems it's better to repeat that: https://forum.armbian.com/inde…net-for-10/#comment-31957 (Marvell Armada 38x based Helios4 might be an interesting alternative if you really need 4 SATA devices at once but in those parts of the world where you get HP Microservers cheap -- which is the case for central Europe for example -- I would prefer such a Microserver since if I start to think about such use cases I start to care about data integrity and then using modern FS like ZFS or btrfs implementing checksumming and ECC memory are mandatory for me)

Zitat von tmihai20

It had to be connected to ethernet to work, at least on first boot.

Yes, due to the new way these OMV images are created for ARM boards (fully automated in a chroot environment so no one has logged in ever here) a few final installation steps are done on first boot and this requires network access. And I didn't thought missing network could be an issue since a NAS without the N (network) is useless anyway

In case you run into XU4 issues please report them at the vendor forum.

Zitat von OpiPC2

Just out of curiosity: Is there any [pre]release (image-file) for the Orange Pi PC 2 yet?

Unfortunately not since situation with mainline kernel is still too much WiP and legacy kernel (Allwinner's 3.10.65) is such a mess that no one will touch it. Status: https://www.armbian.com/orange-pi-pc2/

Main issue currently is that the Ethernet driver Armbian uses on A64, H3 and H5 mainline images is unmaintained (sun8i-emac) and the new variant (dwmac-sun8i) is not part of our kernel sources yet (details). Once this is resolved (maybe with 4.12) and we got cpufreq working again maybe we will switch support level from dev to next and as soon as that happens I'll immediately roll out OMV images and ping @ryecoaaron to upload them on sourceforge.

Currently you would need to build an OMV image yourself (uncomment InstallOpenMediaVault function in userpatches/customize-image.sh and follow instructions). Which is a bit sad since I agree that Orange Pi PC 2, NanoPi NEO 2 and the other GbE equipped H5 boards are pretty awesome OMV targets given their performance, count of real USB ports and especially low price.

Zitat von odroidq

Why can't we report the XU4 OMV issues at this OMV forum?

OMV issues can and should be reported here, the various XU4 and Cloudshell 2 issues -- see https://forum.armbian.com/inde…findComment&comment=32340 -- on their forum. Maybe someone over there will care about, maybe not. I'm not involved any more since it's such a waste of time dealing with micro communities fighting against anything that's new to them (does not only apply to ODROID community but is a general syndrome of such micro communities and vendor forums)

@tmihai20: Armbian provides kernel upgrades from time to time (or if necessary, see 'Dirty Cow' for the last such example) via 'apt upgrade'. Maybe in two weeks we roll out a new major version and then you'll get the update.

Anyone here with access to Cloudshell 2 with 2 disks inside able to do a quick check of all 3 JMS561 modes (RAID-0, RAID-1 and JBOD) providing the output of the following script?

#!/bin/bash
check() {
	for disk in /dev/sd[a-z] ; do smartctl -d sat -q noserial -x -i -r ioctl,2 $disk ; done
	lsusb -v
	lsusb -t
}
check | curl -F 'sprunge=<-' http://sprunge.us

Output will look like http://sprunge.us/ZITZ (data gets pasted to sprunge.us automatically).

Unfortunately Debian policies prevent inclusion of /usr/sbin/update-smart-drivedb script so it's a good idea to manually update /var/lib/smartmontools/drivedb/drivedb.h before by

wget https://raw.githubusercontent.com/mirror/smartmontools/master/drivedb.h