tkaiser

Micro USB for SBC is crap. Rated for only 1.8A, high contact resistance but most importantly encouraging users to use wrong powering sources (crappy phone chargers) or wrong cables (crappy/average Micro USB cables -- USB2 is rated for 500mA max and that's why most of the power lines in these cables are too thin): http://linux-sunxi.org/Powering_the_boards_and_accessories#Micro_USB Again: why do you search for help with Banana Pi hardware issues in a software project's forum? No objections just want to learn the reasons...

See also https://forum.armbian.com/topic/5579-power-off-with-hdd-over-active-hub/?do=findComment&comment=42914 This is what happens if Armbian starts to officially support a device. We as volunteers explain in our spare time to Banana Pi customers why/how their hardware is flawed and how to workaround these hardware issues. And at the same time the responsible company repeats the same 'design decisions' just to trick their customers into believing RPi compatibility so that will continue over and over again. Only solution: raise awareness about hardware and company issues (the guy plagued by ignorance only recognizes as 'tkaiser attacking us'). And now let's stop. Working on these SBCs should be fun if one is not paid (as it applies to all of us devs here). And with SinoVoip it's NO FUN AT ALL.

As already said: Avoid products that feature a Micro USB port for DC-IN since you run into troubles with undervoltage especially in situations where this device then should power a connected disk. The voltage drops happening will lead to exactly your symptoms. We know this serious issue from Banana Pi, Banana Pi Pro, Banana Pi R1 and since this vendor is absolutely irresponsible they repeat this shit show even in 2017 again: You need either an 20AWG rated short Micro USB cable then it might work or you power your HDD directly from the PSU and not through the Banana board. 5V/2A are sufficient but still the problem is mostly called voltage drop / undervoltage. @Lion Wang the guy responsible for this flawed hardware design already explained what's important to fix his own boards: https://web.archive.org/web/20160409075811/http://www.bananapi.com:80/index.php/forum/news/348-solved-problems-with-ssds-or-hdds-using-onboard-sata-on-bpi-r1-onboard-power-is-not-sufficient?start=6#1494 (according to him you need to increase input voltage to 5.5V to compensate for the voltage drops happening -- and the same guy is responsible for BPi M2 Berry design, fascinating, isn't it?) BTW: You have a hardware problem. Why are you asking here for support in a forum that's about a community developed software project?

Because you're dealing with a Banana Pi, these are products for which the vendor NEVER provides correct information. Do a google search for 'fb3 ferrit site:lemaker.org' to get some real information (all hidden somewhere in a Chinese forum).

Maybe not for your use cases but for others. Not everyone has the same needs... I'm well aware of this and as already said IF SINOVOIP WOULD START TO PROVIDE CORRECT HARDWARE DESCRIPTIONS BPi M2 Zero would've been long added as .csc (community supported board variant) so it's at least ensured that hardware settings match so other projects relying on Armbian's build system or using same legacy kernel can easily add support for BPi M2 Zero to their projects (those others are for example H3Droid, RetrOrangePi, Lakka and @jernej's community OpenELEC distro). It would have already happened if the company in question would start to provide correct and not all the time missing or even wrong information. That was talking about most basic support, just describing the hardware so it's useable with legacy kernel (the 3.4 that is unsupported since more than half a year since EOL in April 2017) in a good way. Impossible with SinoVoip since they do not provide the needed information (voltage regulation, if this thing can't switch to 1.1V it will permanently overheat). As soon as this is fixed it's throwing in 2 files into the build system and perfectly working OS images can fall out of it, then @lvmc would already be happy since he doesn't need community, friendlyness and the other stuff but just working OS images for his commercial use cases. Fair enough but not related to 'Armbian support', he and we are missing vendor support. 'Full Armbian' support would mean we actively try to support this device. Armbian wants to move away from legacy kernel so all you have with mainline kernel is then a H2+ device lacking 3 USB ports with a problematic Wi-Fi implementation (AP6212A though referenced as AP6212 by the vendor -- do you start to understand why dealing with them sucks?), only one USB OTG port, no working camera and tinkerers encouraged to solder a MagJack wrongly then then flooding our forum about Ethernet problems. Adding to this: false/misleading advertising. Buyers believe M2 Zero would be compatible to RPi cameras (not true at all) and to RPi software (not true at all). And these people will later end up here in the forum (since they'll realize pretty fast that SinoVoip doesn't support SinoVoip hardware) and complain about incompatibilities. That's the other reason official Armbian support is highly questionable. And may I remind you that all the work done on Armbian is done by volunteers even if the liar who called me already an asshole constantly spreads I would be paid by Xunlong. Seriously: why dealing with this stuff?

Man, that's soooooooooo annoying. Do you know how much time it needs to support this M2 Zero IF SinoVoip would care about providing correct information? Less than an hour. It's just importing a CORRECT hardware description and then doing some MINOR adjustments. That's how it works Get correct hardware description from board vendor adopt/improve settings test, test, test provide general support if Armbian supports the board Step 1 is the problem. We NEVER got correct information, usually we get bogus information for whatever reasons (you call it business strategy while I would call it stupidity/ignorance) and it's the same with Zero AGAIN. If I have to ask someone who personally called me an asshole already, refuses to update publicly available information and also ensures that's there's only BS instead of technical documentation available then: why should a developer deal with this stuff? why should a community like Armbian think about step 4 above? If the vendor's business model is targeting only clueless consumers who do not even care about basic product descriptions being correct (even the PHYSICAL DIMENSIONS, still not fixed in their 'technical documentation') while at the same time being tricked into believing they would buy something compatible to Raspberry Pi Zero (SOFTWARE COMPATIBILITY) then why should a community like Armbian want to support these consumers and the vendor? Even if this M2 Zero isn't useful for any of my own use cases (anyone ever thought about WHY we Armbians spend our SPARE TIME on which devices?) I would've long added https://github.com/armbian/build/blob/master/config/boards/bananapim2zero.csc and https://github.com/armbian/build/blob/master/config/fex/bananapim2zero.fex to the build system since it's easy and fun. But impossible with SinoVoip since they refuse to provide step 1 above and even actively hinder community to support their products. Nothing will change until this company starts to realize that they need to replace their copy&paste monkey responsible for this gitbook mess with a technical writer and that they have to provide CORRECT hardware descriptions early and in an easily accessible way (push the stuff to github at one location, correct mistakes as soon as you're aware of it). And even then it's highly questionable why Armbian as community should start to officially support devices that are designed to trick consumers into believing full Raspberry Pi compatibility where there is none. BTW: I really don't know why I have to repeat this now again (especially since you call this boring). It's so OBVIOUS what's wrong with the company's behaviour and it's also obvious that they don't want to change this. It's still just a waste of time (the board I lost most of my time with in the past was the Zero's bigger sibling M2+, everything related to SinoVoip providing INCORRECT hardware information/description -- whether on purpose or caused by stupidity/ignorance doesn't really matter any more).

Me neither, so what are we talking here about? If providing wrong information is part of SinoVoip's business strategy while providing correct information is most basic requirement for 3rd parties supporting their hardware... well, do you get the mismatch? Anyway: enough time wasted on hardware that is not even supported by its own vendor... use BPi's OS images, they're great and all that you'll get anytime soon. Support forum also over there: http://forum.banana-pi.org/c/Banana-pi-BPI-M2 Feel free to open a 'board bring up' thread here https://forum.armbian.com/forum/22-board-bring-up/ outlining why anyone should waste his time trying to do the impossible (correctly support a hardware where the vendor prevents you getting the necessary information). Good luck, will now mute this thread and everything with 'BPi' in its name.

Hmm... I only checked one installation where I found it installed prior to posting: 2017-10-02 16:52:36 upgrade dnsmasq-base:armhf 2.75-1ubuntu0.16.04.2 2.75-1ubuntu0.16.04.3 Since root@lime2:~# dpkg -l | grep unattended-upgrades ii unattended-upgrades 0.90ubuntu0.8 all automatic installation of security upgrades my understanding is that it should've been updated automagically that day but I might be wrong here. Anyway: other than fixing a potential configuration error with unattended-upgrades we can't do much here anyway since for obvious reasons we rely on upstream distro security fixes. Only exceptions are kernel related vulnerabilities but here we managed to provide fixes on average within less than 24 hours the last 2 years now (for ALL those +20 kernels we currently maintain since we're crazy/stupid/whatever)

Easy: Correct this mistake here: https://bananapi.gitbooks.io/bpi-m2-/content/en/bpi-m2-zero-hardware/bpi-m2-zero-hardware-spec.html (what to expect from a vendor who is not even able to specify the physical dimensions of his own products? It's now year 3 that we deal with this insane amount of stupidity/ignorance, these guys simply don't give a shit about 'information' they provide being correct or of any meaning). As you can see in this thread as usual either schematics or their hardware description (provided fex file) are wrong, this simply sucks and prevents any development efforts. As you can also see above @Icenowy (member of linux-sunxi community) is the only person on this planet currently able to provide some real information (eg. voltage regulation different on her board compared to later board variants -- but you never know what they screw up with a new board revision). As soon as SinoVoip starts to support their own hardware (and do not just spread BS) things might greatly improve though I've not the slightest idea why Armbian would want to support this board (just with BPi M2 Berry the M2 Zero only tries to attract clueless RPi users and I'm sure we really don't want these people here in the forum constantly asking why raspivid, omxplayer and adjusting display resolutions in /boot/config.txt doesn't work. Supporting boards that are designed as scam isn't that smart)

Why/how? Armbian enables unattended-upgrades, all the vulnerabilities that were disclosed on 2nd Oct had been backported to Xenial's 2.75-1ubuntu0.16.04.3 package so please check when the fixed dnsmasq version has been installed on your Armbian installation automagically: zgrep '2.75-1ubuntu0.16.04.3' /var/log/dpkg.log*

...does not exist. You use Xenial, it's Ubuntu's dnsmasq package what you're using. Armbian only provides a few own packages (bootloader/kernel and 'board support package') http://changelogs.ubuntu.com/changelogs/pool/main/d/dnsmasq/dnsmasq_2.75-1ubuntu0.16.04.3/changelog

So you combine it with SinoVoip's OV5640 or another module?

Well, what's the use case? I've to admit that I really like H2+ since this SoC allowed for some really inexpensive SBC with dedicated Fast or even Gigabit Ethernet and 4 real USB2 ports that do not have to share bandwidth (Orange Pi Zero, NanoPi Duo). But this board is just crippled and everything I would need is not exposed BPi M2 Zero is proprietary camera + Wi-Fi/BT (so both BroadPwn and BlueBorne vulnerable). What else? Most probably from @Nora Lee (BPi product manager at Foxconn)

XU4 and HC1 are fully software compatible (check the readme) and heat dissipation on HC1 is WAY BETTER than with XU4. But you're limited to 2.5" disks here and should keep in mind that Hardkernel already announced a HC2 without that much details (so maybe using the same JMS561 as on Cloudshell 2 minus the interconnection problems -- better ask in their forum). Wrt new boards being interesting for NAS use cases: Pine folks want to provide something called 'Cloudmedia Transformer' (same idea as XU4 vs. HC1, the Transformer is a 100% software compatible ROCK64 + JMS578 on the PCB in an heat emitting metal enclosure that fits a 2.5" HDD, they also thought about a 3.5" variant) Similar to 'Le Potato' a so called 'Le Fly' also with RK3328 might appear (the bottom one here) A bunch of RK3399 devices will be available (all with PCIe 2.x x4 and USB3), I expect software support next year on par with RK3328 EspressoBin might have stable software support next year (you can use the native SATA port there and add mPCIe SATA cards with 2 or even 4 additional real SATA ports) Allwinner H6 boards with both PCIe (single lane, PCIe 2.x) and USB3 will appear (see here and keep in mind that Banana Pi people also have an H6 board in the works) Banana Pi R2 might be ready next year (MTK software support looks promising so maybe next year when mainline kernel support matured we'll support the board) The GnuBees are not listed by intention.

Well, for the +100 MB/s you need a good OS image taking care of settings (those images that don't care about settings/versions perform really low as NAS) and I really hope Hardkernel now ships with a better USB cable to interconnect both devices. If you can solve the USB3 connection hassles then XU4 is not the worst choice to be combined with 2 USB3/UAS capable disk enclosures (the internal USB3 hub doesn't matter when you connect HDDs, that's only a performance drop noticable with SSDs). Besides XU4 you've currently not that many options if it's about really fast storage and 2 HDDs at the same time. ROCK64 would need an external USB3 hub, those mPCIe equipped boards combined with an ASM 106x or Marvell 88SE9215 are an option or Helios4. Next year will get more interesting since a few more boards with good storage capabilities will be available.

Just for the record: tested latest Pinebook image and Profile-sync-daemon still isn't enabled automatically: tk@pinebook:~$ psd preview Profile-sync-daemon v6.31 on Ubuntu 16.04.3 LTS Systemd service is currently inactive. Systemd resync-timer is currently inactive. Overlayfs v22 is currently active. Psd will manage the following per /home/tk/.config/psd/psd.conf: tk@pinebook:~$ systemctl --user enable psd Created symlink from /home/tk/.config/systemd/user/default.target.wants/psd.service to /usr/lib/systemd/user/psd.service. tk@pinebook:~$ systemctl --user start psd tk@pinebook:~$ psd preview Profile-sync-daemon v6.31 on Ubuntu 16.04.3 LTS Systemd service is currently active. Systemd resync-timer is currently active. Overlayfs v22 is currently active. Psd will manage the following per /home/tk/.config/psd/.psd.conf: Anyone able to confirm?

That's how it looks like: root@odroidxu4:~# df -h Filesystem Size Used Avail Use% Mounted on udev 10M 0 10M 0% /dev tmpfs 399M 6.9M 392M 2% /run /dev/mmcblk0p3 15G 565M 14G 4% / tmpfs 997M 0 997M 0% /dev/shm tmpfs 5.0M 8.0K 5.0M 1% /run/lock tmpfs 997M 0 997M 0% /sys/fs/cgroup /dev/mmcblk0p1 56M 21M 31M 41% /boot tmpfs 997M 0 997M 0% /tmp folder2ram 997M 6.3M 991M 1% /var/log folder2ram 997M 0 997M 0% /var/tmp folder2ram 997M 0 997M 0% /var/lib/openmediavault/rrd folder2ram 997M 740K 997M 1% /var/spool folder2ram 997M 15M 983M 2% /var/lib/rrdcached folder2ram 997M 8.0K 997M 1% /var/lib/monit folder2ram 997M 0 997M 0% /var/lib/php5 folder2ram 997M 4.0K 997M 1% /var/lib/netatalk/CNID folder2ram 997M 468K 997M 1% /var/cache/samba tmpfs 200M 0 200M 0% /run/user/0 Everything with frequent write access is stored in RAM and saved only hourly to eMMC. With Armbian or the Armbian based OMV image normally you won't notice any performance difference whether the rootfs is on a slow SD card, the fast eMMC or a HDD. Only tasks that force continually 'sync to disk' (eg installing a ton of updates with 'apt upgrade') will perform very differently.

It seems it is browser related -- sorry for the noise. Tested on 3 different platforms with 3 different browsers each and only the one I use for 'average web surfing' (Safari on macOS) shows the behaviour.

Quick iozone benchmark with Hardkernel's red 16GB eMMC module on ODROID-XU4: random random kB reclen write rewrite read reread read write 102400 4 15188 17623 20108 19593 14499 17071 102400 16 32269 34309 47927 47609 40564 33184 102400 512 41923 41838 97742 99609 96272 40443 102400 1024 41208 41125 100828 101495 100518 40068 102400 16384 38858 37916 145011 144954 144665 39192 Though my benchmark is somewhat stupid since I'm running OMV on the eMMC transferred with nand-sata-install and using btrfs as filesystem which by default uses transparent file compression (which is another way to reduce wear on the media of course and speeds up writes to disk): /dev/mmcblk0p3 / btrfs rw,noatime,nodiratime,compress=lzo,ssd,space_cache,commit=600,subvolid=5,subvol=/ 0 0 But on the rootfs the most important performance metric is random IO with rather small blocksizes and HDDs totally suck here for obvious reasons (rotating platters, moving heads, waiting half a rotation on average for a random sector to appear below the drive's heads). This is a 2.5" HDD (7200 rpm) on my HC1 (ext4 formatted). Random IO performance with small block sizes is magnitudes lower than Hardkernel's eMMC: random random kB reclen write rewrite read reread read write 102400 4 11623 12880 16891 17099 668 1155 102400 16 41366 44853 46099 46464 2577 4961 102400 512 89816 87068 94534 97074 39159 43801 102400 1024 87287 84807 91958 98266 56494 55865 102400 16384 73295 76457 91464 94123 91582 79349 And you should always keep in mind how HDDs work: They're twice as fast when they're emtpy compared when they're full (detailed explanation) Especially when used for the rootfs fragmentation can become an issue after some time on a small partition and then performance further drops down

Good luck! In my humble opinion this is one of the worst combinations possible . Funny numbers. Obviously the result from sequential benchmarks. For the rootfs random IO performance is way more important and I would be really surprised if spinning rust can beat Hardkernel's pretty fast eMMC here. But with Armbian it shouldn't matter that much anyway since we use a couple of optimizations to reduce writes to the rootfs anyway (10 min commit interval, /var/log buffered to RAM, on desktop images profile-sync-daemon and browser cache in RAM, on the OMV image -- which is just a Debian next Armbian image with an optimized OMV install on top -- it's even a lot more stuff that will be buffered in RAM and only written to the rootfs every hour or on shutdown/reboot) BTW: https://github.com/armbian/documentation/commit/ba9ca62ced76b46076e7f0cff5f3a01957117105

Unfortunately not. I've posted outside of the forum tons of links to individual posts and they're all broken. First line in the old (and now broken) link format, 2nd line the currently used 'flavour': https://forum.armbian.com/index.php?/topic/3953-preview-generate-omv-images-for-sbc-with-armbian/#comment-32340 https://forum.armbian.com/topic/3953-preview-generate-omv-images-for-sbc-with-armbian/?do=findComment&comment=32340 When will this be fixed?

Voltage not current. Ohm's law (shitty cables/connectors --> high resistance --> voltage drop). Micro USB --> evil.

No, that's 100% hardware issue. Rule of thumb: almost every SBC that is equipped with Micro USB for DC-IN is a pile of crap since undervoltage will happen. You suffer from undervoltage and the most easy fix with a connected HDD is to power both HDD and Banana Pi Pro from the same external 5V PSU with good cables. Avoiding Micro USB is key to success (use the SATA power port to power the Banana from the same source you power your HDD from). You could do a web search for 'sata power enclosure site:lemaker.org' or directly jump to http://forum.lemaker.org/thread-14822-1-1.html

Adding '--force-all' most probably will 'fix' this

Now it gets interesting! But still the only real difference I can imagine is u-boot version. Can you give it a try with an older u-boot version on 'my' image? Eg. http://apt.armbian.com/pool/main/l/linux-u-boot-orangepizero-default/linux-u-boot-orangepizero_5.30_armhf.deb that's »U-Boot SPL 2017.05-armbian (Jun 13 2017 - 15:38:19)«. Just download it, install it via 'dpkg -i', reboot and report back. There's a little chance that this bricks the image though so I hope that's ok on a test installation?