tkaiser

Open a github issue and request sane (not verbose as hell) logging by default. But be prepared that this might take ages even for trivial changes (example) Moving the log file around is not an option if you run off SD card since the card will die hundred times faster. So ask them to decrease their log verbosity or at least to implement daily log rotation with compression applied.

Why not applying then for a job as full time working but unpaid member of the support staff dealing with something like this every other day: Using nmtui-connect would work instantly but since there are all those crappy tutorials out there telling people to fiddle around with /etc/network/interfaces and other text files so many users are wasting their time again and again.

The here mentioned chipsets are all known to be fully UAS compliant when using a recent enough kernel: JMS567, JMS578 and eg. ASM1153E (with original firmware! Seagate also uses this ASMedia chip but combines it with a broken firmware in their USB3 storage products) Then there's this issue (fixed in Armbian, most probably a problem with the majority of x86 Linux distros): And then there are fake products. I bought last summer two JMS578 USB SATA adapters that showed strange behavior with UAS. Understandable since they were fakes using Norelsys 1068 instead (needing UAS blacklisting). Upstream fix arrived just recently in kernel 14.$something thanks to @Icenowybut unfortunately only Norelsys 1608 affected not the similarly broken 1066

JMS567 should not be amongst them so in your situation most probably you should check the cable and USB3-A receptacle which is known to be utter crap (the low end storage world will be a better place once we have USB-C everywhere). Folks, if you see 'uas' in your logs then it's often just the uas driver reporting problems happening one layer below. Don't shoot the messenger even if it seems 'fun' to blame software and a protocol for hardware issues.

@lukasb please use spoiler tags to avoid such walls of text and answer the question whether your drives are powered by the board or by an own PSU. In case it's the board can a moderator please split off these two posts and create a thread in the appropriate sub forum called 'UAS or undervoltage?'. Thank you.

The large Orange Pi can only be powered through the 4/1.7mm barrel jack usually done with a good PSU or some random USB PlayStation powering cable. Rule of thumb: if there is an USB connector on either end of the cable expect problems. The worst cables I ever bought were 'USB to 5.5/2.1mm barrel' on Aliexpress. Voltage drop that severe that not even a single core Olimex A10 Lime was able too boot (crashed instantly and went into endless reboot loop)

Since those use Micro USB you're clearly using different cables between PSU and your Orange Pi. So simply throw this cable away and replace it with something that does not suck (tiny wires --> voltage drop) or buy the Xunlong 3A PSU with fixed cable. All your problems will be gone instantly.

The first stretch goal is reached (that was the 'try to cover not only horribly outdated SoCs from half a decade ago but also some of the just outdated ones'). Two stretch goals are yet open and they estimate the same amount of work/money needed (another 22 man days or 22,000€ in total)

No, there are a lot more but all of this doesn't really matter especially here in this forum. And the whole issue (people using this crappy tool called sysbench trying to benchmark hardware) is not even related to 32-bit vs. 64-bit but different compiler switches. Raspbian packages are built for the ARMv6 ISA so they can be executed on the horribly outdated single core RPis as well. Normal Debian/Ubuntu armhf packages are built for ARMv7 and you would need to switch to arm64 packages since only these packages are built with support for ARMv8 CPU cores (that's what's inside RPI 3 and 2 in the meantime). So comparing an OPi Win running an arm64 Ubuntu or Debian distro with an RPi 3 running any recent Arch, Gentoo, Fedora, OpenSuSE or even an arm64 Armbian (see my link -- I did this) you will see sysbench numbers that are pretty close. Numbers between the different distros will vary since the distro packages are built with different compiler versions and switches. And this is all the lousy sysbench tool in 'cpu test' mode is able to report since this whole test is just calculating prime numbers inside the CPU caches (and as soon as an ARMv8 CPU is allowed to run ARMv8 code this gets magnitudes faster). I don't know of a single real-world use case that would correlate with this pseudo benchmark (except of course if your job is calculating prime numbers, then you can rely on sysbench and if you're running on a RPi 3 should better stay away from Raspbian, DietPi and the other ARMv6 dinosaurs) But while sysbench is wrongly reporting an RPi 3 (or an OPi Win if you choose Xunlong's Raspbian images!) would be magnitudes slower than any of the recent ARMv8 boards with one specific workload the RPi 3 is really magnitudes slower (AES encryption -- think about VPN and disk encryption). Broadcom forgot to license ARMv8 crypto extensions so any other 64-bit (ARMv8) SBC is a better choice than RPi 3 if it's about AES (except ODROID-C2 and NanoPi K2 since their Amlogic S905 suffers from the same problem). See the numbers here: https://forum.armbian.com/topic/4583-rock64/?do=findComment&comment=37829 (OPi Win scores the same as Pinebook)

I put a link in my post and why should this matter especially here? If you open your webbrowser, open google, then enter '64 bit dist' it will be already autocompleted to '64 bit distro for raspberry pi 3'. My post was about sysbench being unreliable crap and boards that are powered via Micro USB easily behaving like unreliable crap with users in front having not the slightest idea about the problem at all (that's why we shouldn't support such design fails). Wrt 'sysbench': to get more details why this is such a lousy anti benchmark it's easy since this has been discussed in detail many times. This forum has two search functionalities. The internal (that as usual only produces misses and irrelevant hits) and 'Google site search' which works reasonably well even when queried just for 'sysbench'.

You have been fooled three times the RPi uses the most crappy way to be powered (Micro USB), your board is undervolted (input voltage dropped below 4.63V) and therefore frequency capping happened. While you think you run a board capable of 1200 MHz the RPi 'firmware' decreased the CPU clockspeeds and you run at 600 MHz. If you replace your PSU and/or cable between PSU and board your RPi 3 will need 110 seconds when you repeat the test the RPi 3 when used with an incapable distro (Raspbian or DietPi for example) can not show its full potential. The RPi 3 has an ARMv8 SoC but with those strange distros it has to run ARMv6 code. As soon as you switch to a better distro your RPi 3 will finish the same sysbench 'benchmark' in 7 seconds sysbench is not a general purpose benchmark but a bad joke. It can not be used for any architecture comparisons since it's only a compiler benchmark and it's impossible to benchmark the hardware with it. Depending on which distro you use the 'performance' can vary by 15 times as you already observed. Sysbench is only used by clueless people or marketing guys BTW: you're not alone. The majority of RPi 3 boards doing heavy stuff runs frequency capped (that's the nice thing with Raspberries. As soon as you would need the CPU power it clocks down to 600 MHz). Some more details: https://github.com/bamarni/pi64/issues/4

This https://www.armbian.com/odroid-hc2/ is so horrible that I really can't believe what's going on it's time to quit.

Wrong. Armbian already runs on tens of thousands of those Raspberries but fortunately users don't know. The whole thing (Armbian in general today) is not about technical details but user expectations and developers' motivations (and some commercial background gaining that might start to destroy the project). Feel free to open up a new thread babbling about what Armbian should do or not (count of devices supported and quality of support -- @botfap outlined this project's problems recently perfectly). I already gave up.

See 8 posts above or https://tech.scargill.net/banana-pi-m2/#comment-27947 Edit: When asking @jernej back then whether he's fine with his code being used in other projects IIRC he had no objections.

Exactly. The average RPi user often has really no clue at all why he bought an SBC (and you should please stop spreading this 'charity/education' BS since 'Pi for education' reality looks different). Users choosing any of the alternatives did at least some research and thought about what they want to achieve and how. And this (the user base) is the real reason why Armbian should never start to support Raspberries since once these people start to arrive here in the forum Armbian is finally dead (but maybe the current approach to semi-support as much SBC as possible will already kill the project).

Everything that's written in blogs and tutorials becomes outdated sooner or later. The most important information regarding obihoernchen is: So if you follow any of these outdated 'tuning' articles you simply destroy performance. And I won't discuss this in a REVIEW thread since it destroys readability. So please open up a new thread if you run into performance problems with an OMV image that has not been modified at all (if you try to tweak things you make it worse for sure!). And everything that has been done to tweak performance on Armbian and OMV is already documented.

I really hope ArmbianIO spreads widely. And relying alternatively on /proc/device-tree/* might help with user adoption. For example once DietPi users start to use ArmbianIO it could be surprising that ArmbianIO only works on approx half of the boards DietPi 'supports' (since DietPi relies on Debian OS images found somewhere or uses Armbian's build system to create crippled Armbian images with the DietPi menu stuff on top sold then as 'DietPi' to their users -- so if their OS images started as Armbian there will be /var/run/machine.id... otherwise not). BTW: In Armbian for all the Allwinner boards that run legacy kernel we tried to use exactly the same string as /proc/device-tree/model to let this method work regardless of legacy or mainline kernel. Since other projects out there (H3Droid, RetrOrangePi, Lakka) also use our fex files they should become compatible to this 'other fallback' too (at least that was my intention behind these adjustments made a while ago). Some details: https://tech.scargill.net/banana-pi-m2/#comment-27947

Relying on /var/run/machine.id while working with Armbian might not be a good idea since we considered this feature already 18 months ago somewhat deprecated (when we turned armhwinfo into tuneperformance and stopped all auto detection at boot -- currently it only transfers info from /etc/armbian-release to /var/run/machine.id). So the better idea is to rely alternatively on /proc/device-tree/model or compatible (this will be fed with mainline kernel from the string defined in DT, on Raspberries the mythical firmware does some additional 'magic' and also allows you to differentiate between different board revisions based on autodetection or let's better say reading out the preprogrammed 'Hardware Revision Code')

As already suggested to @Larry Bank for his ArmbianIO project a while ago: eg. checking for existence of /proc/device-tree/model and reading the string from there. The DT node exists for a reason.

There's nothing special. Simply stay away from all proprietary crypto modules and choose an ARMv8 SoC with support for ARM's crypto extensions. Reasons why: https://forum.armbian.com/topic/4583-rock64/?do=findComment&comment=37829

Can you please provide output from ls -la /etc/armbianmonitor/datasources/soctemp

You might better try to educate yourself about what really happened. Bananas and Oranges are Cubieboard descendants which itself is in a line with Mele A1000 (or more in general: Allwinner A10/A20 based Android devices that were popular in China and were exported later by Tom Cubie which kickstarted more or less linux-sunxi community, Cubietech and sites like CNX). These origins on A10/A20 happened in 2012 when RPi software support was still very limited. Below one rackmounted Mele A2000 cluster (real Ethernet and real SATA combined with SSDs made the difference to toys): Even the power plug used on Bananas and Oranges is inherited from those first Mele TV boxes! At the time RPi was in early development Beagleboard was already there, ODROIDs were already there and in China they had something similar to RPi already years before (QQ2440 and Mini2440 are FriendlyARM products, yes the company now selling NanoPis since Westerners are that stupid that they only can accept a good SBC design if it has Pi in its name) When speaking about RPi it's more or less about Western perception and of course marketing (that's where the RPi Foundation really excels)

I was answering not to you but to one of those stupid 'network manager bashing' posts. But thanks for reminding me to stay away from H3 forum (or this forum at all).

HC2 is now officially available: http://www.hardkernel.com/main/products/prdt_info.php?g_code=G151505170472 (see especially mechanical incompatibility note for few 3.5" HDD at the bottom)

Sounds like you were running into the bug (or settings mismatch) referenced at the end of https://askubuntu.com/questions/842773/ubuntu-server-and-networkmanager (where it's also described how to let NM take care of wired interfaces in Ubuntu Server). Great resource for people struggling with NM concepts is https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/ch-introduction_to_rhel_networking And for experts who prefer anachronistic Debian configuration attempts (fiddling around with text files instead of profiles) the obvious solution is an 'apt purge network-manager && apt autoremove'.